Hi Aaron,
On Monday, December 29, 2014 08:01:53 Aaron Plattner wrote:
> Really? Do you have a link to a report of this, or some description of
> how this happened? I could see it happen if you're running a composite
> manager, but that's only because the application can render to its
> redir
Hi,
On Sunday, January 04, 2015 20:53:59 Emil Velikov wrote:
> Adding Mathias and Frank Binns to the Cc list.
>
> So taking into account the discussion so far, including Mathias's input
> that the official nvidia driver does the same/similar form of cheating:
> - Should we revert on master unti
This is an important optimization for avoiding read-after-write (RAW)
stalls in the HiZ buffer. Certain workloads would run very slowly with
HiZ enabled, but run much faster with the "hiz=false" driconf option.
With this patch, they run at full speed even with HiZ.
Improves performance in OglVSIn
On 10/01/2015 19:33, Ilia Mirkin wrote :
Is there a "continue" in d3d9? I couldn't find one, but if there is,
then this change won't work.
no, but you can break early.
That's why the counter decrease is put at the end of the loop,
since it allows better performance if the loop is stopped early.
On 07/01/2015 17:36, Axel Davy wrote :
Nine code was clamping color outputs for vs < 3,
but msdn docs says it is done in the ps.
Wine seems to clamp them at the vs level.
It makes more sense to clamp at vs level for performance,
but according to doc, ps 2.x shouldn't see clamping.
We have fou
texcoord for ps < 1_4 should clamp between 0 and 1 the values.
texcrd (texcoord ps 1_4) does not clamp and can be used with
two modifiers _dw and _dz that means the channels are divided
by w or z.
Implement those in shared code, since the same modifiers can be used
for texld ps 1_4.
v2: replace D
Found by reading the HIZ_CHICKEN documentation.
Improves performance in a HiZ microbenchmark by around 50%.
Improves performance in OglZBuffer by around 18%.
Thanks to Chris Wilson for helping me figure out where to put this.
Signed-off-by: Kenneth Graunke
---
drivers/gpu/drm/i915/i915_reg.h
This is an important optimization for avoiding read-after-write (RAW)
stalls in the HiZ buffer. Certain workloads would run very slowly with
HiZ enabled, but run much faster with the "hiz=false" driconf option.
With this patch, they run at full speed even with HiZ.
Improves performance in OglVSIn
BTW, colors should indeed be clamped for SM 2.0 in the VS. The reason
is that old ps2.0 hardware used the R8G8B8A8_UNORM format for color
varyings, meaning that all colors were always clamped when they left
the vertex shader and this behavior couldn't be disabled. r300-r400
behave this way, so they
Well, max(x, 0) has no effect on NaNs. According to the GLSL
specification, max() should return x if either argument is NaN. So the
correct way to convert NaN to 0 is:
max(0, y)
That implies that min and max aren't commutative if NaNs are supported.
Marek
On Fri, Jan 9, 2015 at 4:15 AM, Connor
Also, you seem to be assuming that IEEE and D3D10 versions of the
min() and max() are the same, which is not true. Both GLSL and D3D10
versions should work according to IEEE754, yet they are different. The
GLSL versions use conditional assignments, which is the same as C. The
D3D10 versions are def
Reviewed-by: Marek Olšák
Marek
On Fri, Jan 9, 2015 at 4:34 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> After much searching and empricial testing, and reading of
> things I've no justifcation for this fix, other than it really
> appears this is what the hw is doing or close enough.
>
> It m
On Sun, Jan 11, 2015 at 6:57 AM, Marek Olšák wrote:
> Well, max(x, 0) has no effect on NaNs. According to the GLSL
> specification, max() should return x if either argument is NaN. So the
> correct way to convert NaN to 0 is:
>
> max(0, y)
>
> That implies that min and max aren't commutative if Na
Nice!
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, Jan 10, 2015 at 06:44:49PM -0800, Kenneth Graunke wrote:
> This is an important optimization for avoiding read-after-write (RAW)
> stalls in the HiZ buffer. Certain workloads would run very slowly with
> HiZ enabled, but run much faster with the "hiz=false" driconf option.
> With this patc
https://bugs.freedesktop.org/show_bug.cgi?id=87516
Ian Romanick changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Sunday, January 11, 2015 01:49:41 PM Ben Widawsky wrote:
> On Sat, Jan 10, 2015 at 06:44:49PM -0800, Kenneth Graunke wrote:
> > This is an important optimization for avoiding read-after-write (RAW)
> > stalls in the HiZ buffer. Certain workloads would run very slowly with
> > HiZ enabled, but r
On 11.01.2015 06:05, Ilia Mirkin wrote:
Can you elaborate a bit as to why that's the right thing to do?
On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann
wrote:
If we capture transform feedback from n stream in (n-1) buffers we face a
NULL buffer, use the buffer (n-1) to capture the output of
On Sun, Jan 11, 2015 at 7:43 PM, Tobias Klausmann
wrote:
>
>
> On 11.01.2015 06:05, Ilia Mirkin wrote:
>>
>> Can you elaborate a bit as to why that's the right thing to do?
>>
>> On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann
>> wrote:
>>>
>>> If we capture transform feedback from n stream in (
On 12.01.2015 01:57, Ilia Mirkin wrote:
On Sun, Jan 11, 2015 at 7:43 PM, Tobias Klausmann
wrote:
On 11.01.2015 06:05, Ilia Mirkin wrote:
Can you elaborate a bit as to why that's the right thing to do?
On Wed, Jan 7, 2015 at 1:52 PM, Tobias Klausmann
wrote:
If we capture transform feedbac
On Sun, Jan 11, 2015 at 8:11 PM, Tobias Klausmann
wrote:
>
>
> On 12.01.2015 01:57, Ilia Mirkin wrote:
>>
>> On Sun, Jan 11, 2015 at 7:43 PM, Tobias Klausmann
>> wrote:
>>>
>>>
>>> On 11.01.2015 06:05, Ilia Mirkin wrote:
Can you elaborate a bit as to why that's the right thing to do?
>>
On Sun, Jan 11, 2015 at 04:05:25PM -0800, Kenneth Graunke wrote:
> On Sunday, January 11, 2015 01:49:41 PM Ben Widawsky wrote:
> > On Sat, Jan 10, 2015 at 06:44:49PM -0800, Kenneth Graunke wrote:
> > > This is an important optimization for avoiding read-after-write (RAW)
> > > stalls in the HiZ buf
On Tue, Dec 16, 2014 at 1:11 AM, Jason Ekstrand wrote:
> ---
> src/glsl/Makefile.sources | 1 +
> src/glsl/nir/nir.h | 2 +
> src/glsl/nir/nir_split_var_copies.c | 225
>
> 3 files changed, 228 insertions(+)
> create mode 10064
On Sunday, January 11, 2015 05:46:09 PM Ben Widawsky wrote:
> On Sun, Jan 11, 2015 at 04:05:25PM -0800, Kenneth Graunke wrote:
> > On Sunday, January 11, 2015 01:49:41 PM Ben Widawsky wrote:
> > > On Sat, Jan 10, 2015 at 06:44:49PM -0800, Kenneth Graunke wrote:
> > > > This is an important optimiza
On Sunday, January 11, 2015 05:46:09 PM Ben Widawsky wrote:
> On Sun, Jan 11, 2015 at 04:05:25PM -0800, Kenneth Graunke wrote:
> > On Sunday, January 11, 2015 01:49:41 PM Ben Widawsky wrote:
> > > On Sat, Jan 10, 2015 at 06:44:49PM -0800, Kenneth Graunke wrote:
> > > > This is an important optimiza
On Tue, Jan 6, 2015 at 5:21 PM, Jason Ekstrand wrote:
>
>
> On Mon, Jan 5, 2015 at 10:00 PM, Jason Ekstrand
> wrote:
>>
>>
>>
>> On Mon, Jan 5, 2015 at 9:12 PM, Connor Abbott wrote:
>>>
>>> Hi,
>>>
>>> Was it your intention to not support non-per-component things like dot
>>> product at all? I'v
On Sun, Jan 11, 2015 at 06:53:32PM -0800, Kenneth Graunke wrote:
[snip]
>
> Jesse had suggested setting it in broadwell_init_clock_gating on January 5th,
> and Valtteri tried it on January 7th. He found "no noticeable difference".
> I tried it again, and confirmed his result: there was zero per
On Sun, Jan 11, 2015 at 07:05:21PM -0800, Kenneth Graunke wrote:
> On Sunday, January 11, 2015 05:46:09 PM Ben Widawsky wrote:
> > On Sun, Jan 11, 2015 at 04:05:25PM -0800, Kenneth Graunke wrote:
> > > On Sunday, January 11, 2015 01:49:41 PM Ben Widawsky wrote:
> > > > On Sat, Jan 10, 2015 at 06:44
Reviewed-by: Connor Abbott
On Tue, Jan 6, 2015 at 7:34 PM, Jason Ekstrand wrote:
> ---
> src/glsl/nir/nir_lower_variables.c | 111
> +
> 1 file changed, 50 insertions(+), 61 deletions(-)
>
> diff --git a/src/glsl/nir/nir_lower_variables.c
> b/src/glsl/nir/n
Patches without my Reviewed-by on them on your branch are:
"i965/fs_nir: Add support for sample_pos and sample_id"
This one gets rewritten later on so I think it's ok to not review it.
"i965/fs: Allow reinterpretation in constant propagation"
We need Matt or Ken to review this.
"i965/fs: Don't
30 matches
Mail list logo
