On Tue, Jan 29, 2013 at 12:52 PM, Ian Romanick wrote:
> On 01/28/2013 05:06 PM, Frank Henigman wrote:
>>
>> Set fs_visitor::params_remap to NULL in the constructor.
>> This variable was potentially tested in
>> fs_visitor::remove_dead_constants()
>> before being set.
>>
>> Signed-off-by: Frank Hen
From: Dave Airlie
This is my attempt at fixing this as the CVE is making RH security team
care enough to make me look at this. (please upstream, security fixes are
more important than whatever else you are doing, if for no other reason than
it saves me having to fix stuff I've no real clue
On Thu, May 30, 2013 at 4:35 PM, Kenneth Graunke wrote:
> On 05/29/2013 05:44 PM, Dave Airlie wrote:
>>
>> From: Dave Airlie
>>
>> This is my attempt at fixing this as the CVE is making RH security team
>> care enough to make me look at this. (please ups
Okay I now understand why Frank would want to run away, this is
my attempt at fixing the CVE out of bounds access to constants
outside the range. This attempt converts any illegal constants
to constant 0 as per the GL spec, and is undefined behaviour.
A future patch should add some debug for users
On Thu, Jun 13, 2013 at 3:33 AM, Eric Anholt wrote:
> Frank Henigman writes:
>
>> On Tue, Jun 11, 2013 at 1:10 PM, Eric Anholt wrote:
>>
>>> Frank Henigman writes:
>>>
>>> > Replace the one texture lock with a lock per texture. This allows
>>> > uploading textures from one thread concurrently
I noticed this code didn't work as advertised while doing some passing around
of TGSI shaders and trying to reparse them, and things failing.
This seems to fix it here for at least the small test case I hacked into a
graw test.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary
On Fri, Jun 21, 2013 at 2:28 AM, Jonathan Gray wrote:
> The symlinks for compatibility with old scripts assumes
> sysv shared library versioning and breaks other systems.
>
> For example OpenBSD uses sunos 4 style .so.major.minor
> versioning so the targets with ln will fail.
>
> Fixes bug 63269.
On Fri, Jun 21, 2013 at 12:47 AM, Michael Thayer
wrote:
> Hello,
>
> I am looking at the possibility of writing a driver for VirtualBox (ahem,
> yes) which could partly live inside of the Mesa tree. My initial idea was
> to have the driver in two parts, a driver/client part in the Mesa tree and a
On Mon, Jun 24, 2013 at 6:12 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> ---
>> src/gallium/auxiliary/util/u_format.c | 14 ++
>> src/gallium/auxiliary/util/u_format.h | 3 +++
>> src/mesa/state_tracker/st_cb_drawpixels.c | 6 ++
>> 3 files changed, 23
>
>
> Thank you, that looks very interesting. I will need a bit of time to get
> into the code, but for a start the shader conversion code looks very
> understandably written. If I turn it into a driver like I described, is it
> something you would be interested in interfacing to? By the way, is
e sent a patch to
> reverse the expected behavior (so this patch would fix the updated test):
> http://lists.freedesktop.org/archives/piglit/2013-June/006123.html
No idea how I missed these.
Reviewed-by: Dave Airlie
>
> NOTE: This is a candidate for stable branches.
>
> Cc: Paul
On Wed, Jul 3, 2013 at 7:37 AM, Matt Turner wrote:
> On Tue, Jul 2, 2013 at 1:02 PM, Ian Romanick wrote:
>> 2. Instead of just posting md5sum for the release tarballs, I think we
>> should start GPG signing them. I'm not sure what sort of process we want to
>> establish for this. Should they ju
On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
wrote:
> On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke
> wrote:
>> On 07/09/2013 04:33 PM, Stéphane Marchesin wrote:
>>>
>>> On Fri, May 10, 2013 at 11:37 PM, Eric Anholt wrote:
We keep having to pass the attachments around with
On Thu, Jul 11, 2013 at 11:31 AM, Stéphane Marchesin
wrote:
> On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie wrote:
>> On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
>> wrote:
>>> On Wed, Jul 10, 2013 at 6:02 PM, Kenneth Graunke
>>> wrote:
>>>&g
On Thu, Jul 11, 2013 at 8:44 PM, Dave Airlie wrote:
> On Thu, Jul 11, 2013 at 11:31 AM, Stéphane Marchesin
> wrote:
>> On Wed, Jul 10, 2013 at 6:27 PM, Dave Airlie wrote:
>>> On Thu, Jul 11, 2013 at 11:05 AM, Stéphane Marchesin
>>> wrote:
>>>> On Wed
I've lightly tested this, not piglit strength yet,
and it does require the kernel patch to work.
its also available in a branch in my repo r600-geom-shaders.
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/ma
From: Dave Airlie
cayman has a different end of program bit, so do that properly.
fixes hangs with geom shader tests on cayman.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium
These 30 patches comprise geometry shader support for r600->cayman GPUs,
Since I last posted, I've fixed all the regressions caused by the initial
introduction of geometry shaders patch, this passes a large amount of the
geometry tests, and I'd like to merge this soon, I think any remaining proble
From: Dave Airlie
Vadim's code derived it from the info.mode, but it needs
to be takes from the geometry shader output primitive.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 27 ++-
src/gallium/drivers/r600/r600_state_common.c
From: Dave Airlie
only enable prim id if gs uses it
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 6 +-
src/gallium/drivers/r600/evergreend.h | 4
src/gallium/drivers/r600/r600_shader.c | 9 +
src/gallium/drivers/r600/r600_shader.h
From: Dave Airlie
SB needs fixes for three GS instructions it seems to raise
them outside loops etc despite my best efforts.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b
From: Dave Airlie
This can happen in normal operation, so don't report an error on it,
just continue.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
From: Dave Airlie
Although we don't use SB on geom shaders, the VS copy shader will use it
so we might as well implement MEM_RING support in sb.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_bc_dump.cpp | 3 +++
src/gallium/drivers/r600/sb/sb_bc_finalize.cpp | 2 +-
From: Dave Airlie
As we do for vertex and pixel shaders.
`
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 6896617
From: Dave Airlie
this fixes a bunch of the geom shader built-in tests
---
src/gallium/drivers/r600/r600_shader.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index f4a3194..07b343b
From: Dave Airlie
It looks like we need these for geom shaders in the future.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/eg_asm.c | 6 --
src/gallium/drivers/r600/r600_asm.c | 9 +++--
src/gallium/drivers/r600/r600_asm.h | 1 +
3 files changed, 12 insertions(+), 4
From: Vadim Girlin
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreend.h | 80 ---
src/gallium/drivers/r600/r600d.h | 1 +
2 files changed, 75 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreend.h
b/src/gallium
From: Dave Airlie
If the shader has no CF clauses at all emit an nop
If the last instruction is an ENDLOOP add a NOP for the LOOP to go to
if the last instruction is CALL_FS add a NOP
These fix a bunch of hangs in the geometry shader tests.
Signed-off-by: Dave Airlie
---
src/gallium/drivers
From: Dave Airlie
This just adds support for emitting the proper value in the VS out misc.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 3 +-
src/gallium/drivers/r600/r600_pipe.c | 2 +-
src/gallium/drivers/r600/r600_shader.c | 58
From: Dave Airlie
The instance cnt register was missing for a few kernels,
with a new enough kernel we can output it.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers
From: Dave Airlie
We need to be able to write to the ring using a base register
for when we emit vertices in a loop, in theory the SB compiler
could collapse these indirect writes to direct writes if the
register value is constant and known, but that is outside my
pay grade.
Signed-off-by: Dave
From: Dave Airlie
Trivial fix to Vadim's code.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 5d3f7c8..f4a3194 100644
---
From: Vadim Girlin
[airlied: fix dropped streamout line - fix for master]
Signed-off-by: Vadim Girlin
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 1 -
src/gallium/drivers/r600/r600_state.c| 2 -
src/gallium/drivers/r600/r600_state_common.c | 123
From: Dave Airlie
This follows what fglrx does, it unpacks the input we are
going to indirect into a bunch of registers and indirects
inside them.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 48 +++---
1 file changed, 44 insertions(+), 4
From: Dave Airlie
This just enables the workarounds we have for vertex/pixel shaders
for geom shaders as well.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_state_common.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b
From: Dave Airlie
attempt to calculate a better value for array size to avoid breaking apps.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers
From: Dave Airlie
This enables streamout with GS in the mix, from the
VS dma shader.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 6 --
src/gallium/drivers/r600/r600_state_common.c | 4
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a
From: Vadim Girlin
v2: fix regression on r600 NOP instructions.
Signed-off-by: Vadim Girlin
Signed-off-by: Dave Airlie
Fix regression since eop moving
---
src/gallium/drivers/r600/eg_asm.c | 10 ++
src/gallium/drivers/r600/r600_asm.c| 24 +---
src
From: Dave Airlie
---
src/gallium/drivers/r600/sb/sb_shader.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/sb/sb_shader.cpp
b/src/gallium/drivers/r600/sb/sb_shader.cpp
index 9f49ac8..f996c07 100644
--- a/src/gallium/drivers/r600/sb
From: Dave Airlie
This selects the cut value depending on the shader selected.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium
From: Dave Airlie
This just makes r600 and evergreen do what the radeonsi codepaths do
for layered rendering. This makes the 2d amd_vertex_shader_layer test
pass on evergreen.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/evergreen_state.c | 18 +-
src/gallium
From: Dave Airlie
This just bumps the number to the 3.2 minimum to represent geometry
shader samplers.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium
From: Dave Airlie
cayman has a different end of program bit, so do that properly.
fixes hangs with geom shader tests on cayman.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/gallium
From: Dave Airlie
This is my first attempt at enabling r600/r700 geometry shaders,
the basic tests pass on both my rv770 and my rv635,
It requires this kernel patch:
http://www.spinics.net/lists/dri-devel/msg52745.html
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_asm.c
From: Dave Airlie
This throws the switch to enable GL 3.3 and GLSL 330.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_pipe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/r600_pipe.c
b/src/gallium/drivers/r600/r600_pipe.c
index
From: Dave Airlie
set the correct values so the misc out register is setup correctly
for the copy shader.
This also updates the state for the gs copy shader so the hw
gets programmed correctly.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 10 +-
src
From: Dave Airlie
For geometry shaders we need to call this code from a second place.
Just move it out for now to keep future patches cleaner.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_shader.c | 213 +
1 file changed, 110 insertions(+), 103
Hi Zack,
you forgot to post the initial patch to add the d3d10 state tracker :-P
Dave.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Feb 5, 2014 at 12:19 AM, Grigori Goronzy wrote:
> On 04.02.2014 00:53, Dave Airlie wrote:
>>
>> From: Dave Airlie
>>
>> attempt to calculate a better value for array size to avoid breaking apps.
>>
>> Signed-off-by: Dave Airlie
>> ---
&g
On Wed, Feb 5, 2014 at 9:07 AM, Jordan Justen wrote:
> v2:
> * Make gl_InstanceID a system value
typo ^^ I assume you mean gl_InvocationID.
Dave.
>
> Signed-off-by: Jordan Justen
> Reviewed-by: Paul Berry
> ---
> src/glsl/builtin_variables.cpp | 2 ++
> src/mesa/main/mtypes.h | 1 +
>
Since r600g in master now has GL 3.3 support and it would be really
good if we could provide a consistent 3.3 support level (not looking
at you sandybridge).
So I'd like to request that I can backport the r600g specific patches
to enable geom shaders and hence 3.3. I'll use a single squashed patch
From: Dave Airlie
This respects the CAP and adds glsl->tgsi support for the TG4 opcode.
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_extensions.c | 4
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 11 ---
2 files changed, 12 insertions(+), 3 deletions(-)
d
From: Dave Airlie
This just adds the TG4 opcode, and a CAP for the
max texture gather components.
v2: add component selection src and a cap to say
hw can do it. (st can use to help control
GL_ARB_gpu_shader5/GLSL 4.00). Add docs.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi
From: Dave Airlie
This respects the CAP and adds glsl->tgsi support for the TG4 opcode.
v2: propogate the component selection to gallium
Signed-off-by: Dave Airlie
---
src/mesa/state_tracker/st_extensions.c | 4
src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 19 ++-
On Fri, Feb 7, 2014 at 12:36 PM, Roland Scheidegger wrote:
> Am 07.02.2014 02:56, schrieb Ilia Mirkin:
>> On Thu, Feb 6, 2014 at 8:52 PM, Dave Airlie wrote:
>>> From: Dave Airlie
>>>
>>> This just adds the TG4 opcode, and a CAP for the
>>> max textu
From: Dave Airlie
I'll merge this with the previous patches.
---
src/gallium/docs/source/screen.rst | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/docs/source/screen.rst
b/src/gallium/docs/source/screen.rst
index 90e8278..0677e93 100644
--- a/src/gallium/docs/s
This just adds the gallium opcode/cap + the st/mesa pieces
to enable it, I have r600g code but I want to go over it again
before sending it. I also have a couple of other extensions that
have trivial gallium bits I'd like to line up.
(GL_ARB_texture_query_lod, and GL_ARB_texture_query_levels).
Dav
From: Dave Airlie
This just adds the TG4 opcode, and a CAP for the
max texture gather components.
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_info.c | 1 +
src/gallium/include/pipe/p_defines.h | 3 ++-
src/gallium/include/pipe/p_shader_tokens.h | 4 +++-
3 files
>>>
>> Doh, yes because GL has ARB_texture_gather then has stuff hidden away
>> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we should
>> do.
>>
>> So I've reposted with the component selection in src1 now.
>
> Hmm seems a bit excessive to use an extra reg for that (gather4 bu
On Sat, Feb 8, 2014 at 10:22 PM, Christoph Bumiller
wrote:
> On 07.02.2014 23:25, Dave Airlie wrote:
>>>> Doh, yes because GL has ARB_texture_gather then has stuff hidden away
>>>> in ARB_gpu_shader5 I forgot to add the extra bits which I suppose we
>>>>
From: Dave Airlie
This adds support for GL_ARB_texture_gather, and one step of
support for GL_ARB_gpu_shader5.
This adds support for passing the TG4 instruction, along
with non-constant texture offsets, and tracking them for the
optimisation passes.
This doesn't support n
From: Dave Airlie
This adds support to gallium for a TG4 instruction,
and two CAPs. The first CAP is required for GL_ARB_texture_gather.
The second CAP is required to expose GL_ARB_gpu_shader5.
However so far we haven't found any hardware that natively
exposes the textureGatherOffsets fe
This adds support to gallium, and also to the state tracker
for ARB_texture_gather and also the gather features of ARB_gpu_shader5.
It adds a single CAP for the ARB_texture_gather max components query,
then another CAP to denote the GPU is capable of SM5 gather.
This doesn't add native support fo
From: Dave Airlie
This lowering pass will be useful for gallium drivers as well, in order to
support
the GL TG4 oddity that is textureGatherOffsets.
Signed-off-by: Dave Airlie
---
src/glsl/Makefile.sources | 1 +
src/glsl/ir_optimization.h
>> const GLuint *inputMapping;
>> @@ -4379,22 +4428,34 @@ translate_src(struct st_translate *t, const
>> st_src_reg *src_reg)
>>
>> static struct tgsi_texture_offset
>> translate_tex_offset(struct st_translate *t,
>> - const struct tgsi_texture_offset *in_offset)
>> +
>>dst.z = texture_depth(unit, lod)
>>
>> +.. opcode:: TG4 - Texture Gather (as per ARB_texture_gather)
>> + Gathers the four texels to be used in a bi-linear
>> + filtering operation and packs them into a single register.
>> + Only works with 2D, 2D arr
Hey,
so currently glxinfo with our libGL vs indirect nvidia GL fails to work,
The main reason is we get fbconfigs, our libGL picks the best fbconfig
as a 32-bit per channel RGBA, but then glXGetVisualFromFBConfig fails
on that since I assume it wants 8-bit per channel ones.
Now I can fix this to
s good to me, I can also confirm this fixes glxinfo from mesa
libGL to nvidia libGL.
Reviewed-by: Dave Airlie
Dave.
>
> Cc: "9.2 10.0 10.1"
> ---
> src/glx/glxcmds.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/src/glx/glxcmds.
On Wed, Feb 12, 2014 at 9:10 AM, Roland Scheidegger wrote:
> Am 11.02.2014 22:58, schrieb Dave Airlie:
>>>>dst.z = texture_depth(unit, lod)
>>>>
>>>> +.. opcode:: TG4 - Texture Gather (as per ARB_texture_gather)
>>>> +
I've taken a quick look at ARB_texture_query_levels,
and the HW generally seems to implement this by returning it in the W
channel of RESINFO, which would map to the TXQ instruction,
So my initial implementation added a LEVQ TGSI instruction but I do
think this isn't representative of the hw and
There is a comment and two checks in the i965 dma-buf importer,
* Images originating via EGL_EXT_image_dma_buf_import can be used only
* with GL_OES_EGL_image_external only.
however I can't find any reference to this in the spec txt, and
removing the checks make my test app run fine using TEXTURE
From: Dave Airlie
At the moment to get an EGL image to a dma-buf file descriptor,
you have to use EGL_MESA_drm_image, and then use libdrm to
convert this to a file descriptor.
This extension just provides an API modelled on EGL_MESA_drm_image,
to return a dma-buf file descriptor.
Signed-off-by
On Mon, Mar 3, 2014 at 7:30 PM, Michel Dänzer wrote:
> On Son, 2014-03-02 at 17:21 -0800, Dave Airlie wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 15b4ff3f4e9460320dd629026743e17fa7109156
>> URL:
>> http://cgit.fre
On Sat, Mar 8, 2014 at 12:13 AM, Pohjolainen, Topi
wrote:
> On Mon, Mar 03, 2014 at 01:19:48PM +1000, Dave Airlie wrote:
>> There is a comment and two checks in the i965 dma-buf importer,
>>
>> * Images originating via EGL_EXT_image_dma_buf_import can b
On 3 December 2014 at 07:32, Ian Romanick wrote:
> On 12/02/2014 12:51 PM, Eric Anholt wrote:
>> Ian Romanick writes:
>>
>>> On 11/26/2014 06:09 PM, Dave Airlie wrote:
>>>> Glamor is 4x faster on my ILK using glsl 130 at core text using
>>>> x11p
On 3 December 2014 at 08:46, Dave Airlie wrote:
> On 3 December 2014 at 07:32, Ian Romanick wrote:
>> On 12/02/2014 12:51 PM, Eric Anholt wrote:
>>> Ian Romanick writes:
>>>
>>>> On 11/26/2014 06:09 PM, Dave Airlie wrote:
>>>>> Glamor is
rong with the
register alloc above.
I suspect I'll keep digging into this, but its getting to the edges of
the brain space/time I can find!
Dave.
From 170184b712d9596f761acdee2c7cff2a2792d937 Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date: Wed, 3 Dec 2014 13:05:18 +1000
Subject: [PATCH] r600g/
On 8 December 2014 at 20:41, Vadim Girlin wrote:
> On 12/06/2014 07:13 AM, Vadim Girlin wrote:
>>
>> On 12/04/2014 01:43 AM, Dave Airlie wrote:
>>>
>>> Hi Vadim,
>>>
>>> I've been looking with Glenn's help into a bug in sb for a couple
From: Dave Airlie
Since d8da6deceadf5e48201d848b7061dad17a5b7cac where the
state tracker started using UCMP on cayman a number of tests
regressed.
this seems to be r600g is doing CNDGE_INT for UCMP which is >= 0,
we should be doing CNDE_INT with reverse arguments.
Signed-off-by: Dave Air
On 9 December 2014 at 10:25, Dave Airlie wrote:
> On 8 December 2014 at 20:41, Vadim Girlin wrote:
>> On 12/06/2014 07:13 AM, Vadim Girlin wrote:
>>>
>>> On 12/04/2014 01:43 AM, Dave Airlie wrote:
>>>>
>>>> Hi Vadim,
>>>>
>>&g
On 8 December 2014 at 20:41, Vadim Girlin wrote:
> On 12/06/2014 07:13 AM, Vadim Girlin wrote:
>>
>> On 12/04/2014 01:43 AM, Dave Airlie wrote:
>>>
>>> Hi Vadim,
>>>
>>> I've been looking with Glenn's help into a bug in sb for a couple
From: Dave Airlie
r600, rv610 and rv630 all have a bug in their GPR indexing
and how the hw inserts access to PV.
If the base index for the src is the same as the dst gpr
in a previous group, then it will use PV instead of using
the indexed gpr correctly.
The workaround is to insert a NOP when
On 9 December 2014 at 16:56, Dave Airlie wrote:
> From: Dave Airlie
>
> r600, rv610 and rv630 all have a bug in their GPR indexing
> and how the hw inserts access to PV.
Also,
This fixes 120 piglit regressions on rv635 since SB was intro
From: Dave Airlie
r600, rv610 and rv630 all have a bug in their GPR indexing
and how the hw inserts access to PV.
If the base index for the src is the same as the dst gpr
in a previous group, then it will use PV instead of using
the indexed gpr correctly.
The workaround is to insert a NOP when
From: Dave Airlie
r600, rv610 and rv630 all have a bug in their GPR indexing
and how the hw inserts access to PV.
If the base index for the src is the same as the dst gpr
in a previous group, then it will use PV instead of using
the indexed gpr correctly.
The workaround is to insert a NOP when
From: Dave Airlie
According to NDA docs:
FMASK surfaces are addressed identically a surface with num_samples bits per
element, and
log2(num_samples) samples. For example, an FMASK for an 8-sample surface would
be addressed
identically to a color surface with 8 bits per element and 3 samples
From: Dave Airlie
On evergreen there are 4 regs, on r600/700 there is only one.
Don't initialise regs and trash someone elses state.
Not sure this fixes anything, but hey one less stupid.
Signed-off-by: Dave Airlie
---
src/gallium/drivers/r600/r600_state.c | 7 ++-
1 file chang
On 11 December 2014 at 06:45, Marek Olšák wrote:
> It uses the libdrm surface allocator and FMASK is 2D tiled. Maybe the
> rounding of bpp affects the pitch in a bad way.
>
I found this sentence hidden in tcore fmask allocator.
// Note that pitch_tile_max is shared with the color surface and mus
>>>
>>>
>>> New patch is attached, the only difference is in the sb_sched.cpp (it
>>> disables copy coalescing for some "unsafe" cases, so it may leave more
>>> MOVs
>>> than previously, but I don't think there will be any noticeable effect on
>>> performance).
>>>
>>> So far I don't see any proble
From: Dave Airlie
libdrm patch: but mesa seems more suited to discussion.
According to a tcore statement, the fmask needs to share
pitch with the color surface, and since we pass that color
surface pitch in already, we should use it if the one we
calculate is less.
Now I've no idea if
On 16 December 2014 at 08:59, Vadim Girlin wrote:
> On 12/16/2014 01:30 AM, Dave Airlie wrote:
>>>>>
>>>>>
>>>>>
>>>>> New patch is attached, the only difference is in the sb_sched.cpp (it
>>>>> disables copy
ode by Michael Krol
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_exec.c | 743 -
src/gallium/auxiliary/tgsi/tgsi_info.c | 24 +-
src/gallium/docs/source/tgsi.rst | 76 ++-
src/gallium/include/pipe/p_shader_tokens.h | 26 +-
4
May as well get the gallium side of the fp64 work discussed
while the mesa side is stuck in unreviewed limbo.
So any suggestions for opcode changes or new opcodes I've missed
I pretty much took a union of SM5 and radeon hw as a first pass,
I have noticed that radeon allows modifiers to work on do
From: Dave Airlie
These act like flt32 except they take up two slots, and you
can only add 2 x flt64 constants in one slot.
The main reason they are different is we don't want to match half a flt64
constants against a flt32 constant in the matching code, we need to make
sure we treat both
>> + // fprintf(stderr, "%f %f\n", src[0].d[0], src[1].d[0]);
>
>
> leftover debug print
dropped,
>> enum tgsi_exec_datatype {
>> TGSI_EXEC_DATA_FLOAT,
>> TGSI_EXEC_DATA_INT,
>> - TGSI_EXEC_DATA_UINT
>> + TGSI_EXEC_DATA_UINT,
>> + TGSI_EXEC_DATA_DOUBLE,
>
>
> One comma too many
f
Reviewed-by: Dave Airlie
On 31 December 2014 at 10:13, Eric Anholt wrote:
> ---
> src/gallium/auxiliary/indices/u_primconvert.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/gallium/auxiliary/indices/u_primconvert.c
> b/src/gallium/auxiliary/indices/u_pri
e git repository at:
git://people.freedesktop.org/~airlied/mesa 10.4
for you to fetch changes up to 6c1f7a9a4fda16a91c20e65d8a5cfe8f08be92ba:
r600g/sb: implement r600 gpr index workaround. (v3.1) (2015-01-05
18:24:17 +1000)
Dave Airl
Okay I've been doing some further FMASK studies empirically, dumping
the fmask after rendering to an MSAA surface,
it appears on r600 at 8xMSAA, every 8x8 tile requires 128 bytes of
storage, that is used depending on the value in the CMASK.
So it appears at 8xMSAA for every 4-bit entry in the CMA
On 8 January 2015 at 11:25, Alex Deucher wrote:
> On Wed, Jan 7, 2015 at 8:19 PM, Dave Airlie wrote:
>> Okay I've been doing some further FMASK studies empirically, dumping
>> the fmask after rendering to an MSAA surface,
>>
>> it appears on r600 at 8xMSAA, ever
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 makes sense that each entry in the FMASK corresponds to
an entry in the CMASKm and the CMA
901 - 1000 of 4069 matches
Mail list logo
