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

[Roland Scheidegger]

Am 03.02.2018 um 00:31 schrieb 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).
> 

Ok, so for other buffers you can't really do anything special? You just
go through a pointer to array-of-pointer lookup?
I thought "proper" apps would just use UBOs for everything these days
(hence nothing really much need for tuning slot 0). But maybe that's not
actually true... I can see that you'd want to optimize usage of this
precious space. I suppose GL doesn't give you much help there with its
iffy buffer handling.

Roland