[Mesa-dev] RFC: buffer support in TGSI for SSBO/atomic

[Roland Scheidegger]

Am 02.11.2015 um 22:39 schrieb Dave Airlie:
> On 3 November 2015 at 07:31, Roland Scheidegger <sroland at vmware.com> wrote:
>> Am 02.11.2015 um 20:55 schrieb Ilia Mirkin:
>>> FTR these are the various operators on nvidia hw:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.nvidia.com_cuda_parallel-2Dthread-2Dexecution_-23cache-2Doperators&d=BQIFaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=Vjtt0vs_iqoI31UfJxBl7yv9I2FeiaeAYgMTLKRBc_I&m=AffBQlVu5ht00Ignz67m4YHn6ePeNQFrDUYljvo28Vc&s=m5WnnOkcD2MS1JiJjK4XTWgUXjyEbZWhWSjq_V_O6oA&e=
>>>
>>> Most of these map directly to instruction things (ca/cg/cs/cv sound
>>> familiar, dunno about lu, could just be an assembler helper).
>> Ah I see, that's how it works. Makes sense I guess, though I guess there
>> could be some slight inefficiences if data is packed "strangely"
>> (because global coherent write will evict l1 cache lines, thus for
>> instance some non-coherent access to a different variable but same cache
>> line would have to re-fetch that from l2), but probably that's not too
>> bad...
>>
>>
>>>
>>> How backwards-compatible is TGSI supposed to be? Can we change the
>>> encoding willy-nilly, or are there separate systems that talk to each
>>> other using TGSI that would need coordination?
>> I think it's not really different than the rest of gallium, so not
>> actually considered stable. Obviously it was written to be quite
>> extensible, but I don't think there's really anything preventing us from
>> changing it in binary-incompatible ways, IFF there's a really good
>> reason for it. If some driver relies on binary compatibility for tgsi
>> shaders (let's say for recognizing specific shaders to be able to do
>> shader replacements) it will need to be adapted to such changes (and I
>> know of some code which does that...). So reducing field width just
>> because you could do with less is not really a good idea, but doing it
>> because you actually need the now free bits should be ok.
> 
> For virgl I'd like the txt encoding's not to radically be redone, but the
> binary I'm fine with.
> 
> Even if the txt does for virgl I can rewrite things anyways.
> 

If you'd need binary compatibility after such a change it would be
possible to add version tokens. I don't think anyone really wants to
deal with things like multiple slightly changed structs in general, but
conversion code could keep all the old struct versions and be able to
convert from old to new (or vice versa). I guess something similar could
be done for text representation, if necessary. (Stable gallium abi which
would of course include tgsi was something which was talked about in the
past but never materialized. I can certainly see why you might be
interested in stable tgsi representation for virgl, albeit you'd
probably have to maintain that code yourself...)

Roland