Gen4 hardware appears to GPU hang frequently when using Chromium, and
also when running 'glmark2 -b ideas'. Most of the error states contain
3DPRIMITIVE commands in quick succession, with very few state packets
between them - usually VERTEX_BUFFERS/ELEMENTS and CONSTANT_BUFFER.
I trimmed an apitr
thats make sense.
regards.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sunday, January 18, 2015 01:04:03 AM Francisco Jerez wrote:
> And remove the mocs argument of the emit_buffer_surface_state vtbl hook. Its
> semantics vary greatly from one generation to another, so it kind of
> encourages the caller to pass 0 which is the only valid setting across
> generation
Asking the DC for less than one cacheline (4 owords) of data for uniform pull
constants is suboptimal because the DC itself cannot request less than that
from L3, resulting in wasted bandwidth, unnecessary message dispatch overhead
and exacerbating the L3 serialization bug on IVB. Improves perform
This reverts to using the oword block read messages for uniform pull constant
loads, as used to be the case until 4c1fdae0a01b3f92ec03b61aac1d3df5. There
are two important differences though: Now the L3 cacheability bits are set up
correctly, and we target the constant cache instead of the data ca
Not used anymore. It was just a scalar MOV.
---
src/mesa/drivers/dri/i965/brw_defines.h| 1 -
src/mesa/drivers/dri/i965/brw_fs.h | 3 ---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 26 --
src/mesa/drivers/dri/i965/brw_shader.cpp | 2 --
4
This is the first part of a series meant to improve our usage of the L3 cache.
Currently it's far from ideal since the following objects aren't taking any
advantage of it:
- Pull constants (i.e. UBOs and demoted uniforms)
- Buffer textures
- Shader scratch space (i.e. register spills and fills)
And remove the mocs argument of the emit_buffer_surface_state vtbl hook. Its
semantics vary greatly from one generation to another, so it kind of
encourages the caller to pass 0 which is the only valid setting across
generations. After this commit the hardware-specific code decides what the
best
It's a wrapper around emit_buffer_surface_state with format=RAW, pitch=1,
rw=true and the remaining arguments ordered differently. There's no point in
having a separate vtbl pointer for that.
---
src/mesa/drivers/dri/i965/brw_binding_tables.c| 8 +---
src/mesa/drivers/dri/i965/brw_contex
It's perfectly fine to read the second half of a register written with
force_writemask_all from a first half MOV instruction or vice versa, and
lower_load_payload shouldn't mark the whole MOV as belonging to the second
half in that case. Replicate the same metadata to both halves of the
destinatio
brw_set_dp_read_message already had a target_cache argument, but its
interpretation was rather contrived: On Gen7+ it was ignored and the data
cache was always used, on Gen6 the render cache was used if the caller asked
for it, otherwise it was ignored using the sampler cache instead.
brw_set_dp_w
On Saturday, January 17, 2015 01:09:45 PM Connor Abbott wrote:
> On Sat, Jan 17, 2015 at 11:42 AM, ahmad wrote:
> > hi.
> >
> > "#! /usr/bin/env python" corresponds python 3.x series for some major
> > distro (arch,fedora ...) and python 2.x for some others.
> >
> > python 2.x and python 3.x are
On Sat, Jan 17, 2015 at 8:31 AM, Thomas Helland
wrote:
> 2015-01-03 22:48 GMT+01:00 Matt Turner :
>> On Sat, Jan 3, 2015 at 11:18 AM, Thomas Helland
>> wrote:
>>> This allows opt_algebraic to resolve open-coded
>>> saturates into ir_unop_saturate before we potentially
>>> mess it up by removing t
On Sat, Jan 17, 2015 at 11:42 AM, ahmad wrote:
> hi.
>
> "#! /usr/bin/env python" corresponds python 3.x series for some major distro
> (arch,fedora ...) and python 2.x for some others.
>
> python 2.x and python 3.x are not source compatible each other.
>
> python 3.x not contains "xrange" funci
hi.
"#! /usr/bin/env python" corresponds python 3.x series for some major distro
(arch,fedora ...) and python 2.x for some others.
python 2.x and python 3.x are not source compatible each other.
python 3.x not contains "xrange" funcion anymore.
range vs xrange only meaningfull for python 2.x
2015-01-03 22:48 GMT+01:00 Matt Turner :
> On Sat, Jan 3, 2015 at 11:18 AM, Thomas Helland
> wrote:
>> This allows opt_algebraic to resolve open-coded
>> saturates into ir_unop_saturate before we potentially
>> mess it up by removing the min or max in min/max-pruning.
>>
>> Since we are now emitti
I see why you are worried, and I agree 100%.
This just reinforces my impression that expanding this pass does
not give adequate return on investment.
If we had even better coverage we just might get some advantage,
but even then I have a bad feeling about this.
Do you have any suggestions for oper
https://bugs.freedesktop.org/show_bug.cgi?id=64449
Alberto Salvia Novella changed:
What|Removed |Added
Priority|medium |highest
URL|
https://bugs.freedesktop.org/show_bug.cgi?id=88534
Bug ID: 88534
Summary: include/c11/threads_posix.h PTHREAD_MUTEX_RECURSIVE_NP
not defined
Product: Mesa
Version: git
Hardware: Other
OS: Linux (All)
Resolving a multisampled depth texture into
a single sampled texture is supported on >= SM4.1
hw. It is possible some previous hw support it.
The ability was tested on radeonsi and nvc0.
Apparently is is also supported for radeon >= r700.
This patch adds the MULTISAMPLE_Z_RESOLVE cap and
add it t
On Tuesday, January 13, 2015 03:40:32 PM Matt Turner wrote:
> On Tue, Jan 13, 2015 at 3:35 PM, Matt Turner wrote:
> > Otherwise, we would have necessarily read the results or eliminated the
> > dead SEND. In either case, no work around is necessary.
> >
> > Noticed when debugging the problem the p
https://bugs.freedesktop.org/show_bug.cgi?id=88523
José Fonseca changed:
What|Removed |Added
CC||jfons...@vmware.com
--- Comment #4 from J
On Friday, January 16, 2015 11:55:33 PM Matt Turner wrote:
> On Fri, Jan 16, 2015 at 11:45 PM, Kenneth Graunke
> wrote:
> > On Tuesday, January 13, 2015 03:35:57 PM Matt Turner wrote:
> >> This is a fix for a regression introduced in commit a9f8296d ("i965/fs:
> >> Preserve the CFG in a few more
23 matches
Mail list logo
