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