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

[Roland Scheidegger]

Am 04.04.2016 um 17:27 schrieb Axel Davy:
> 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 ?
As I said, you can do what you want there as far as I'm concerned. Just
saying it's going to be a constant battle to fix other drivers...

> 
> 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.
I don't think a bit that it's a nine context makes sense. There's other
bits already doing similar things, like half_pixel_center, clip_halfz -
which when introduced first strictly were for d3d9-like state trackers
(even if nine wasn't around then). So, so far we've broken down the "do
d3d9 behavior" to individual bits, and I don't think it makes sense to
change that. So, if you need another such rasterization bit, that should
be added separately (though I'm not quite sure what the difference
really is?).

Shader behavior is another matter. d3d9 generally really dislikes NaNs
(as does old GL btw albeit theoretically old or new it's still mostly
optional with glsl, argh). Some instructions are also of course
different between d3d9 and gl.
This comes up from time to time, but we didn't do anything yet. Could be
handled with shader property (so, per-shader) or even with additional
instruction flags (or additional instructions). Personally I'd be in
favor of shader property if it really helps.

> 
> 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.
Err wait so it has to be (1,1,1,1) for color0 but (0,0,0,0) or (0,0,0,1)
are both ok for other inputs? Weird.
I think though (for this particular difference) it would make sense if
you'd just bite the bullet, check if the currently bound shaders are
affected by this and if so make a new variant translating that mess
away. gallium should make it easy to handle api differences relatively
well, but not to the point of handling every last bit of crazy stuff
apis might have.

Roland