BRW_PREDICATE_ALIGN1_ANY16H was incorrectly being disassembled as
"all16h", and ALL16H would probably print as "(null)".
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_disasm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_dis
We clearly don't want to start at the head and walk backwards; we want
to start at the last real element before the tail sentinel. If the list
is empty, tail_pred will be the head sentinel, and we'll stop.
Nothing uses this function, so I guess nobody noticed it was broken.
Signed-off-by: Kennet
These were looking in the wrong field.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_eu_emit.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c
b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index cd5bc9f..3f00e4d 100644
- Don't try to disassemble send's src1 as a descriptor if it's not an
immediate.
- In the same case, show src1 as an operand (makes it easier to see
bogus register regions, etc -- the hardware is very fussy)
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_disasm.c | 336 ++
We'd otherwise go looking into virtual_grf_sizes for things that aren't
in there at all.
Signed-off-by: Chris Forbes
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i9
From: Christian König
We want hex values here, not decimals.
Signed-off-by: Christian König
---
src/gallium/drivers/radeon/r600_buffer_common.c | 2 +-
src/gallium/drivers/radeon/r600_texture.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/rad
Reviewed-by: Marek Olšák
Marek
On Sun, Jul 6, 2014 at 12:31 PM, Christian König
wrote:
> From: Christian König
>
> We want hex values here, not decimals.
>
> Signed-off-by: Christian König
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 2 +-
> src/gallium/drivers/radeon/r600_textu
You forgot to fix radeon which uses this structure.
Marek
On Sat, Jul 5, 2014 at 8:49 PM, Samuel Pitoiset
wrote:
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/include/pipe/p_defines.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/include/pipe/p_defines.h
> b/src/
The same as patch 3 - this will break radeon.
Marek
On Sat, Jul 5, 2014 at 8:49 PM, Samuel Pitoiset
wrote:
> This will be used by GL_AMD_performance_monitor.
>
> Signed-off-by: Samuel Pitoiset
> ---
> src/gallium/auxiliary/hud/hud_driver_query.c | 2 +-
> src/gallium/drivers/nouveau/nvc0/nvc
https://bugs.freedesktop.org/show_bug.cgi?id=79688
--- Comment #11 from Tobias Jakobi ---
Just wanted to add that this bugreport really helped me to setup DRI3+PRIME
with my Intel/Radeon combo.
In fact I was missing rendernodes, which per pointed out in the original patch
description
(http://lis
Reviewed-by: Marek Olšák
Marek
On Sun, Jul 6, 2014 at 7:02 AM, Ilia Mirkin wrote:
> Signed-off-by: Ilia Mirkin
> ---
>
> There's an accompanying patch based on ChrisF's unpublished series to add
> interpolateAt* to mesa core that makes use of them, and a further couple of
> patches which inmpl
Whoops.
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Sat, 2014-07-05 at 10:53 +0300, Pekka Paalanen wrote:
> On Fri, 04 Jul 2014 08:45:00 +0100
> Steven Newbury wrote:
>
> > On Fri, 2014-07-04 at 03:40 -0400, Ilia Mirkin wrote:
> > > On Fri, Jul 4, 2014 at 3:37 AM, Steven Newbury
> > > wrote:
> > > > On Thu, 2014-07-03 at 10:47 +0200, And
On Sat, 2014-07-05 at 10:53 +0300, Pekka Paalanen wrote:
> On Fri, 04 Jul 2014 08:45:00 +0100
> Steven Newbury wrote:
>
> > On Fri, 2014-07-04 at 03:40 -0400, Ilia Mirkin wrote:
> > > On Fri, Jul 4, 2014 at 3:37 AM, Steven Newbury
> > > wrote:
> > > > On Thu, 2014-07-03 at 10:47 +0200, And
The only thing I'm wondering is about hw support for offset version
taking a generic float. In particular, it looks like intel graphics
actually uses 4bit immediates for the offset version (just like dictated
by the d3d11 specification).
At a quick glance I couldn't quite see how it's done with sou
On Saturday, July 05, 2014 11:24:53 PM Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
> inde
On Sun, Jul 6, 2014 at 6:23 PM, Roland Scheidegger wrote:
> The only thing I'm wondering is about hw support for offset version
> taking a generic float. In particular, it looks like intel graphics
> actually uses 4bit immediates for the offset version (just like dictated
> by the d3d11 specificat
On Saturday, July 05, 2014 01:04:02 PM Emil Velikov wrote:
> On 5 July 2014 08:53, Pekka Paalanen wrote:
> > On Fri, 04 Jul 2014 08:45:00 +0100
> > Steven Newbury wrote:
> >
> >> On Fri, 2014-07-04 at 03:40 -0400, Ilia Mirkin wrote:
> >> > On Fri, Jul 4, 2014 at 3:37 AM, Steven Newbury
> >> > wr
On 7 July 2014 00:22, Kenneth Graunke wrote:
> On Saturday, July 05, 2014 01:04:02 PM Emil Velikov wrote:
>> On 5 July 2014 08:53, Pekka Paalanen wrote:
>> > On Fri, 04 Jul 2014 08:45:00 +0100
>> > Steven Newbury wrote:
>> >
>> >> On Fri, 2014-07-04 at 03:40 -0400, Ilia Mirkin wrote:
>> >> > On
20 matches
Mail list logo
