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
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to