[Mesa-dev] [PATCH 2/2] [RFC] radv: add scratch support for spilling.
Bas Nieuwenhuizen
bas at basnieuwenhuizen.nl
Tue Oct 11 22:14:35 UTC 2016
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.
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
More information about the mesa-dev
mailing list