[Mesa-dev] [PATCH] radeonsi: Enable VGPR spilling for all shader types v3

Tom Stellard tom at stellard.net
Fri Jan 23 18:56:23 PST 2015


On Thu, Jan 22, 2015 at 11:27:32AM +0900, Michel Dänzer wrote:
> On 21.01.2015 21:12, Marek Olšák wrote:
> > We also had a case when the CPU accidentally corrupted shaders,
> > because the shaders were mapped after textures and a CPU texture
> > upload overflowed and overwrote shaders. I suppose we should have
> > unmapped the shaders.
> 
> Sounds like a good idea.
> 
> 
> Tom, for now I suggest this solution, summarized from Marek's previous
> descriptions:
> 
> (At least) for shaders which have relocations, keep a copy of the
> machine code in malloced memory. When the relocated values change,
> update them in the malloced memory, allocate a new BO, map it, copy the
> machine code from the malloced memory to the BO, replace any existing
> shader BO with the new one and invalidate the shader state.
> 

Hi,

Attached is a WIP patch attempting to implement it this way.
Unfortunately, I was unable to get it working, so I wanted to
submit it for review in case someone can spot what I'm doing wrong.

You can find the broken code wrapped in #if 0 in the
si_update_scratch_buffer() function in si_state_shaders.c

Based on the dmesg output and other tests I've done, it appears
that the GPU is still executing the shader code from the old bo
which does not contain the relocations.

The code in the #else branch works fine, but it updates the existing
bo in place rather than creating a new one.

Any idea what I've done wrong?

Thanks,
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-radeonsi-Enable-VGPR-spilling-for-all-shader-types-v.patch
Type: text/x-diff
Size: 20144 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150123/fdfd2da1/attachment-0001.patch>


More information about the mesa-dev mailing list