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

[Axel Davy]

On 04/04/2016 18:48, Roland Scheidegger wrote:
> Am 04.04.2016 um 17:27 schrieb Axel Davy:
>
>
>> 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?).
I'm not sure other hw could set this rasterization setting as easily,
perhaps it needs to set a register that affects other things.
I don't know much about nouveau, but I have been told there
are d3d flags to switch the behaviour of parts of the pipeline.

>
> 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
>