[Mesa-dev] [PATCH 0/7] RadeonSI 32-bit pointers v2 & Gallium changes

[Marek Olšák]

On Sat, Feb 3, 2018 at 12:01 AM, Roland Scheidegger <sroland at vmware.com> wrote:
> Am 02.02.2018 um 23:39 schrieb Marek Olšák:
>> On Fri, Feb 2, 2018 at 10:26 PM, Roland Scheidegger <sroland at vmware.com> wrote:
>>> Am 02.02.2018 um 21:48 schrieb Marek Olšák:
>>>> Hi,
>>>>
>>>> This is the second and hopefully final version of 32-bit pointer
>>>> support for radeonsi.
>>>>
>>>> Constant buffer 0 now has restrictions on which buffers can be set
>>>> in that slot.
>>>>
>>>> I plan to push this when my LLVM patch lands in 6.0 (hopefully it
>>>> will be accepted there).
>>>>
>>>> There will also be a dependency on new libdrm (not included in this
>>>> series).
>>>>
>>>> Please review.
>>>>
>>>
>>> From a api cleanliness point of view, I don't like this much.
>>> First, you're making the hack case the default and even require it. IMHO
>>> a driver should be able to bind ordinary UBOs to all buffer slots. This
>>> is really not a nice burden to put on state trackers to do something
>>> special for just slot 0. The gallium API should stay reasonable imho,
>>> that's a bit too much custom tailoring for GL for my liking.
>>>
>>> Maybe I'm missing something but I can't quite see why you can't handle
>>> this transparently inside the driver. Can't you just create a different
>>> shader depending on what kind of buffer is bound or what's the problem?
>>> (You wouldn't expect it to change therefore you should not have to
>>> recompile.)
>>
>> We don't recompile shaders in the vast majority of cases. When shader
>> compilation stalls rendering, the gaming experience is destroyed.
>>
>> There is no alternative. Our shader ABI will be set up such that it
>> only has 32-bit pointers in shader registers. There are
>> performance-related reasons for that.
>
> That seems to be quite limited, why can't you have a shader ABI which
> can do either 32 or 64 bit pointers?

Good questions. GCN shaders have only 16 dwords of constant memory
(GFX9 has 32). There are no shader resource slots and the pixel shader
is the only one to have real inputs. All other stages don't have any
shader inputs except for system values.

The 16 dwords contain pointers and states to load inputs and load
descriptions of resource slots from memory. One of the pointers
sometimes points to constant buffer 0. If it's a VS, there are only 13
dwords, because 3 are reserved for baseinstance, basevertex, and
drawID. We can also put some other data into that constant memory to
skip load instructions. There is a huge incentive to free those
precious dwords and use them for something else, like skipping some
load instructions. I've been also considering 16-bit pointers (e.g.
32-bit pointers aligned to 64KB).

Marek