[Mesa-dev] [PATCH 0/5] Gallium: Passing drirc options to create_screen() and fixing Rocket League

Nicolai Hähnle nhaehnle at gmail.com
Thu Jun 22 07:34:33 UTC 2017


On 22.06.2017 03:38, Rob Clark wrote:
> On Wed, Jun 21, 2017 at 8:15 PM, Marek Olšák <maraeo at gmail.com> wrote:
>> On Wed, Jun 21, 2017 at 10:37 PM, Rob Clark <robdclark at gmail.com> wrote:
>>> On Tue, Jun 20, 2017 at 6:54 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> This series updates pipe loaders so that flags such as drirc options
>>>> can be passed to create_screen(). I have compile-tested everything
>>>> except clover.
>>>>
>>>> The first pipe_screen flag is a drirc option to fix incorrect grass
>>>> rendering in Rocket League for radeonsi. Rocket League expects DirectX
>>>> behavior for partial derivative computations after discard/kill, but
>>>> radeonsi implements the more efficient but stricter OpenGL behavior
>>>> and that will remain our default behavior. The new screen flag forces
>>>> radeonsi to use the DX behavior for that game.
>>>>
>>>
>>> do we really want this to be a *global* option for the screen?
>>
>> Yes. Shaders are pipe_screen (global) objects in radeonsi, so a
>> compiler option also has to be global. We can't look at the context
>> during the TGSI->LLVM translation.
> 
> well, I didn't really mean per-screen vs per-context, as much as
> per-screen vs per-shader (or maybe more per-screen vs
> per-instruction?)

I honestly don't think it's worth the trouble. Applications that are 
properly coded against GLSL can benefit from the relaxed semantics, and 
applications that get it wrong in one shader are rather likely to get it 
wrong everywhere.

Since GLSL simply says derivatives are undefined after non-uniform 
discard, and this option makes it defined instead, setting this flag can 
never break the behavior of a correctly written shader.

Cheers,
Nicolai


>>> I'm just thinking, some drivers use lowering passes that internally
>>> generate kill's.  I *guess* it would only matter if they also had
>>> ddx/ddy instructions, but not sure.
>>>
>>> not really sure if this would actually be a problem or not..
>>
>> Whether or not this affects you depends on how your hardware
>> implements kill/discard. Not just ddx/ddy, texture instructions
>> computing derivatives internally are affected by kill/discard too.
>>
> 
> I guess most of the lowering passes that introduce kill's are more
> like legacy gl things (clip-planes, glBitmap(), maybe some others but
> pretty sure it is all legacy type stuff), so maybe it isn't likely to
> matter.  I'm not totally sure about the expected interactions between
> kill and other instructions, so not totally sure about whether I
> should care.. but figured I should point it out.. and if it doesn't
> matter, it doesn't matter.
> 
> BR,
> -R
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.


More information about the mesa-dev mailing list