Ian Romanick wrote:Roland Scheidegger wrote:
Ah, missed that in the spec. Seems to be unnecessarily restrictive to not have a weighting factor for GL_MIN/MAX, apparently common hardware could do it just fine (or maybe it doesn't make enough sense to allow it?).
Modern hardware can, but that extension is almost 10 years old. I don't think hardware was quite as orthogonal back then. :)
Here's a patch. That << 8 is a bit ugly, though. Should I add the
unshifted blend func values to r200_reg.h, together with some proper defined shifts? I like the blend func value selection better than before (where there was a huge function where the second half is (almost) identical to the first). Fixes blendminmax indeed...
The shift is a bit ugly, but other than that, the patch looks like what I would have written. :) My suggestion would be to add SRC_BLEND_FACT() and DST_BLEND_FACT() macros like i830 has. Also, if the assertion that the RGB and alpha blend equations are the same is left in, we should probably add assertions that the RGB and alpha blend functions are the same as well.
This would also be a good time to discuss adding support for EXT_blend_func_separarte and EXT_blend_equation_separate. If separate blend equations or functions are used on R200, the R200_RB3D_ABLENDCNTL and R200_RB3D_CBLENDCNTL are used instead of R200_RB3D_BLENDCNTL.
There are two issues. How is the extra blend information communicated to the DRM? How do we handle the fact that R200_RB3D_BLENDCNTL lives in a state atom with a lot of other stuff and may, accidentally, overwrite the separate state?
For the first issue, I see two possible solutions. Both require changes to the Radeon DRM. One way is to add a new "blend" state atom. This atom would include both R200_RB3D_ABLENDCNTL and R200_RB3D_CBLENDCNTL. It would only be emitted if R200_RB3D_ABLENDCNTL != R200_RB3D_CBLENDCNTL. The problem is that every time the ctx atom is emitted, the blend atom also must be emitted. This could also cause problems with context switching. I supposed this could be as easy as just modifying r200EmitState to always emit blend after anytime ctx is emitted. That seems a bit ugly, though.
The other way is to just extend the ctx atom with the R200_RB3D_ABLENDCNTL register. If R200_RB3D_ABLENDCNTL != R200_RB3D_CBLENDCNTL the DRM would write to those registers, otherwise it would use the R200_RB3D_BLENDCNTL. This should be easy. The cmd_size would change depending on the DRM version, so dealing with binary compatibility in that direction is easy. I'm not so sure about the other direction. In looking at how the cmdpacket mechanism works, I'm not sure this exact scheme would work, but some variation of it should.
Thoughts?
This does not explain though why the results are wrong if blending isn't enabled in the first place, since neither blend function nor blend equation should change anything if blending is disabled, I think.
Yeah, that's probably a different problem. :( The r200 may not have a way to actually disable blending. It might be that the hardware has to be set to an equation of GL_ADD and functions of GL_ONE and GL_ZERO. Dunno.
I've looked into it a bit further, it's strange. That R200_ENABLE_ALPHA_BLEND surely DOES something, but not quite what I'd expect. It doesn't affect the "logic op blending" (which is not unexpected probably), and not enabling it indeed seems to prevent actual blending calculations. But, if GL_MIN and GL_FUNC_REVERSE_SUBTRACT blending functions are used, the result seems to be always 0 (black) in that case. Odd.
Someone (maybe with documentation) has any ideas?
If not I'll try Ian's suggestion and basically just set it back to the default blend func/equation whenever blending gets disabled (needs of course other minor code modifications).
It could be that it is supposed to work the way would expect it, but there are hardware bugs. Who knows. The only bad part of leaving the blend enabled (but set to a no-op mode) is that the read-modify-write access to the framebuffer may be slower. It would be interesting to test. In fact a test like that would be useful for other cards too. If there is a performance difference, it may be worth it to detect the no-op blend modes and disable blending. Hmm...
------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
