[Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering

Rogovin, Kevin kevin.rogovin at intel.com
Tue Aug 28 16:20:59 UTC 2018


Sorry for the doubly reply, but I wanted to add one more important bit in my thinking in addition to doing minimal code changes and following existing convention. The ARB/NV extensions defined a critical section where as the INTEL extension is just a barrier function. I suspect (but I do not know) that the NVIDIA hardware that supports the extension is implemented by some weird interfacing logic with the pixel backend and that implementation requires that there is just one critical section under no control flow whereas the INTEL is just a memory barrier. In that light, I think they should be 3 different intrinsics with the thinking that if the Nouveau driver adds support for the ARB/NV extension it will do the IR analysis to do what is needed for the critical-section style extension.


From: Rogovin, Kevin
Sent: Tuesday, August 28, 2018 7:05 PM
To: mesa-dev at lists.freedesktop.org
Cc: Jerez Plata, Francisco <francisco.jerez.plata at intel.com>
Subject: Re: [Mesa-dev] [PATCH 0/2] Implement INTEL_fragment_shader_ordering


I followed the convention that was already present. The code from ARB/NV_fragment_shader_interlock had an intrinsic for begin critical section and an intrinsic for end critical section. I figured that since this extension has a completely different thinking (i.e. a memory barrier instead of a section) it warranted a new intrinsic. That and doing this way incurred the least amount of changes which I figured is always a good thing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180828/d5918fac/attachment.html>

More information about the mesa-dev mailing list