[Mesa-dev] [PATCH 2/2] [RFC] radv: add scratch support for spilling.

Dave Airlie airlied at gmail.com
Tue Oct 11 02:13:49 UTC 2016


On 11 October 2016 at 11:42, Dave Airlie <airlied at gmail.com> wrote:
> On 11 October 2016 at 05:50, Dave Airlie <airlied at gmail.com> wrote:
>> On 10 October 2016 at 21:45, Arsenault, Matthew
>> <Matthew.Arsenault at amd.com> wrote:
>>> I don't like adding explicit IR arguments for ABI arguments, especially this
>>> one. Adding a special case for the first index feels dirty. The rest of llvm
>>> also won't be aware of the specialness of the argument. It would be
>>> problematic because bugpoint would eliminate the unused argument and then
>>> codegen would have to fail in some way when the argument is missing
>>>
>>
>> We should just hardcode the behaviour and switch both radv/radeonsi
>> over in one go?
>>
>> I'll try and code up, using the first 64-bits of the first buffer
>> pointed to by userdata 0/1,
>> to store things.
>
> I've looked at doing a dword fetch from the first two words of the 0/1 userdata,
>
> It's not optimal for vulkan unfortunately, since the idea I had was per command
> buffer I just allocate one scratch buffer of the size required at the end, and
> patch it in at the start of the command buffer. However in the first
> slot I was going
> to use the push constants/dynamic buffer to store the value, however it looks
> like I need to keep a list of everyone of these buffers I emit, and
> backpatch them
> all. It might not be too insane, just a slight bump in the keeping it simple.

I'm probably losing te plot here, but I'm considering a double indirection,

we load the 64-bit address from the first two dwords, then load the
64-bits dword
from that address to get the value.

This saves me allocating scratch bo's for secondary command buffers,
and also having to allocating ever increasing scratch bo's as shaders that
need more scratch get bound to the pipeline.

I'm not sure how much of an effect this should have for GL though.

Dave.


More information about the mesa-dev mailing list