[virglrenderer-devel] [PATCH 0/3] TGSI_FILE_HW_ATOMIC support

[Dave Airlie]

On 20 July 2018 at 15:47, Tomeu Vizoso <tomeu.vizoso at collabora.com> wrote:
>
>
> On 07/19/2018 09:09 PM, Dave Airlie wrote:
>>
>> On 19 July 2018 at 23:41, Tomeu Vizoso <tomeu.vizoso at collabora.com> wrote:
>>>
>>> Hi,
>>>
>>> just thought of sending this patches even if it's not the best moment to
>>> merge them, just in case anyone is curious. I plan to rebase and resend
>>> once SSBO and image support is merged in master.
>>>
>>> The need for this arises from Gallium otherwise implementing atomic
>>> counters with SSBOs and reserving half of the shader blocks for that.
>>> This is problematic because some dEQP tests assume that more than 6
>>> blocks are available when drivers such as i915 provide 12 in the host.
>>
>>
>> I was wondering if we need to this far or could we just detect
>> BUFFER[0], ATOMIC decls
>> and convert those to atomic counters somehow?
>>
>> The TGSI_FILE_HW_ATOMIC stuff is quite attunded to r600 hw atomics, and
>> I'm
>> not sure how well it maps to virgl, like it all the tests tpass with
>> it, then maybe it
>> should be fine.
>
>
> Yeah, all *atomic_counter* tests in deqp 3.1 pass. I found that the hw
> atomics in TGSI matched quite well the GLSL specs, which is after all
> virgl's hw.
>
> I also liked how similar it is to other decls, but was left a tiny bit
> uneasy by how many similar codepaths there are, to ssbos, images, ubos, etc.
> But I think that adding an abstraction of some sort to save code would just
> make things harder to read.

Okay maybe we should use this path, the only worry I have are in the guest
around where we expose hw atomics to mesa, the limits and stuff were mostly
designed around r600 level hw.

We might want to consider exposing GL_MAX_COMBINED_SHADER_OUTPUT_RESOURCES
as a limit prior to using this.

Dave.