[Mesa-dev] [PATCH 1/3] r600: Change default behaviour for undefined COLOR0

Axel Davy axel.davy at ens.fr
Mon Apr 4 15:27:48 UTC 2016


Le 04/04/2016 15:27, Roland Scheidegger a écrit :
> Am 04.04.2016 um 14:04 schrieb Axel Davy:
>> On 03/04/2016 20:41, Roland Scheidegger wrote :
>>> Am 03.04.2016 um 10:11 schrieb Axel Davy:
>>>> d3d 9 needs COLOR0 to be 1.0 on all channels when
>>>> undefined. 0.0 for the others is fine.
>>>> GL behaviour is undefined.
>>>>
>>> Not that I care what drivers use by default for undefined values, but it
>>> probably would be better to fix that properly in the state tracker since
>>> certainly gallium doesn't impose that default...
>>>
>>> Roland
>>>
>> Implementing it properly in the state tracker is a bit annoying,
>> because of possible combinations of usage ff pipeline vs non ff pipeline.
>> It would be made easier if (0,0,0,0) was defined as the default in gallium,
>> so only COLOR0 would have to be checked, else all outputs/inputs have to
>> be checked.
>>
>> As it seems rather easy to fix in the driver, I chose that way.
> Well all zeros might look sane as a default. I have no idea however
> which drivers would conform to it - seems a bit unfair to "break" them
> by a doc update...
> (Though requiring a different default just on color0 input is indeed
> insanity on d3d9's part.)
>
>> There seems to be very few games relying on the behaviour.
> Yes, hopefully...
>
> Roland
>
So is that ok to you for now to update the radeon behaviour ?

Also another thing to consider is that we plan to propose a context 
creation flag
to indicate the state tracker is gallium nine. That would enable the hw 
to -optionally-
change some gallium undefined things depending on whether you're gl or nine.

For example radeon hw have a hw bit for rasterization rounding gl vs d3d.
This makes some differences when looking closely at the output results 
for some draw calls.
This is 'optional' feature in the sense that it's not too bad if you 
don't use that hw bit,
but it is better if you do. Also some rasterizer behaviours can be 
adapted, like NaN handling, etc.

The (1, 1, 1, 1) for color0 and (0,0,0,0) or (0,0,0,1) for the others is 
less 'optional' in the sense games rely
on it, but as there are very very few games that do, I guess it could be 
sort of okay to put it optional.

Axel


More information about the mesa-dev mailing list