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

[Bas Nieuwenhuizen]

On Tue, Oct 11, 2016 at 11:14 PM, Bas Nieuwenhuizen
<bas at basnieuwenhuizen.nl> wrote:
> On Tue, Oct 11, 2016 at 2:42 AM, 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'd prefer having a load in there for radv too. For the VS we
> currently use 14 SGPR's, and we need both spilling and a table for the
> tessellator/GS rings. So unless we want to use relocations (and I
> really don't like them, as updating the shaders is going to be a pain
> on radv due to threading) for one of them, it would be nice to make
> the spill address be the first entry of that table (a single-entry
> table for non-gfx queues). As that table shouldn't change during
> execution of a command buffer we still need to patch at one point.

nvm, we can easily reduce user SGPR's (especially when taking into
account pipeline layouts) and relocating the rings isn't actually that
bad, as we shouldn't have to resize them. If you really feel directly
passing it in is better, then go for it.

>
> Besides, patching in general isn't possible for compute queues, as a
> single command buffer can be scheduled on multiple compute queues at
> the same time.
>
> - Bas
>
>
>
>> Dave.
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev