Re: tests/blendminmax fails on r200
Ian Romanick wrote: 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. :) The patch cannot deny its copy-merge heritage ;-) My suggestion would be to add SRC_BLEND_FACT() and DST_BLEND_FACT() macros like i830 has. ok, I'll rip out the old blend blend values in the r200_reg.h file, add unshifted ones and use BLEND_FACT macros instead (though, I HATE macros). 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. Yes saw that too, but since I wanted to add support for the separate functions I didn't bother to change it (and also, I think mesa guarantees it anyway, so the assertion could go away). 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. Yes, I wanted to do that. In fact, I have written the code for it some months ago, the only reason it's not finished is because the odd blend behaviour, I didn't want to add additional blend stuff unless the old (simpler to debug) code wasn't fixed (and I also couldn't test it). 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. Not only these two, but also R200_RB3D_BLENDCOLOR (not yet in r200_reg.h, but Keith has revealed the location of it - it's directly before these two registers, and I have tested that it works). I'm not sure though if it's a good idea to only emit it if the blend registers are identical, it could simply always be emitted (I think there's no performance difference for the blend operation if it's separate or not). 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. Yes, especially since ctx is emitted really a lot. Nonetheless, this is what I've used initially. 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? Ah, that's an interesting idea. I've first thought this is not possible due to the macro-ish nature of the state atoms, but it actually seems easy to do (just don't use the fixed CTX_STATE_SIZE, doh!). Backward compatiblity in this direction might not be absolutely required though, but the other direction (new kernel module, old dri) is a must, otherwise Linus will not be happy... I'll look into it. 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... I've written a patch which just sets back the blend equation to func_add (and also set back the blend function, just to be sure) whenever blending is disabled in addition to disable blending, and also checks when the blend_func/equation is changed if blending is currently enabled (otherwise do nothing). Blend equation/function thus is only set if blending gets enabled, or if the equation/function is changed while it's enabled. Seems to work, if there are no objections I'll commit it (after some cleanups) tomorrow. Then I can finally work on the
tests/blendminmax fails on r200
this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-develm=107854279829216w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). Roland --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tests/blendminmax fails on r200
Roland Scheidegger wrote: this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-develm=107854279829216w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). You beat me to the punch. :) When I wrote that test I was 99% sure it would fail on R200 the same way it failed on i830. The problem is that the GL_MIN and GL_MAX modes do *NOT* use the values set by glBlendFunc (or glBlendFuncSeparate). If the blend equation is set to GL_MIN or GL_MAX, it is supposed to operate as if 'glBlendFunc(GL_ONE,GL_ONE)' was set. This would be an ideal bug for a DRI newbie to fix. :) Take a look at the functions i830BlendFuncSeparate, i830BlendEquationSeparate, and i830_set_blend_state (all in i830_state.c) for some guidance. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tests/blendminmax fails on r200
Ian Romanick wrote: Roland Scheidegger wrote: this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-develm=107854279829216w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). You beat me to the punch. :) When I wrote that test I was 99% sure it would fail on R200 the same way it failed on i830. The problem is that the GL_MIN and GL_MAX modes do *NOT* use the values set by glBlendFunc (or glBlendFuncSeparate). If the blend equation is set to GL_MIN or GL_MAX, it is supposed to operate as if 'glBlendFunc(GL_ONE,GL_ONE)' was set. 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?). 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. Roland --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tests/blendminmax fails on r200
Roland Scheidegger wrote: Ian Romanick wrote: Roland Scheidegger wrote: this new demo fails pretty horribly on r200. It seems to be caused by the same bug as I reported here, http://marc.theaimsgroup.com/?l=dri-develm=107854279829216w=2, something fundamental just doesn't work right with regard to blending. Even if you never enable blending (or disable it explicitly) in this blendminmax demo, the results are vastly different to software rendering (blend equation seems to make a difference even if blending is disabled for some reason). You beat me to the punch. :) When I wrote that test I was 99% sure it would fail on R200 the same way it failed on i830. The problem is that the GL_MIN and GL_MAX modes do *NOT* use the values set by glBlendFunc (or glBlendFuncSeparate). If the blend equation is set to GL_MIN or GL_MAX, it is supposed to operate as if 'glBlendFunc(GL_ONE,GL_ONE)' was set. 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. :) 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. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: tests/blendminmax fails on r200
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...
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).
Roland
Index: r200_state.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_state.c,v
retrieving revision 1.18
diff -u -r1.18 r200_state.c
--- r200_state.c21 Mar 2004 17:05:03 - 1.18
+++ r200_state.c13 May 2004 00:19:29 -
@@ -104,156 +104,146 @@
rmesa-hw.ctx.cmd[CTX_PP_MISC] = pp_misc;
}
-static void r200BlendEquationSeparate( GLcontext *ctx,
- GLenum modeRGB, GLenum modeA )
-{
- r200ContextPtr rmesa = R200_CONTEXT(ctx);
- GLuint b = rmesa-hw.ctx.cmd[CTX_RB3D_BLENDCNTL] ~R200_COMB_FCN_MASK;
-
- assert( modeRGB == modeA );
-
- switch ( modeRGB ) {
- case GL_FUNC_ADD:
- case GL_LOGIC_OP:
- b |= R200_COMB_FCN_ADD_CLAMP;
- break;
-
- case GL_FUNC_SUBTRACT:
- b |= R200_COMB_FCN_SUB_CLAMP;
- break;
-
- case GL_FUNC_REVERSE_SUBTRACT:
- b |= R200_COMB_FCN_RSUB_CLAMP;
- break;
-
- case GL_MIN:
- b |= R200_COMB_FCN_MIN;
- break;
-
- case GL_MAX:
- b |= R200_COMB_FCN_MAX;
- break;
-
- default:
- break;
- }
-
- R200_STATECHANGE( rmesa, ctx );
- rmesa-hw.ctx.cmd[CTX_RB3D_BLENDCNTL] = b;
- if ( ctx-Color._LogicOpEnabled ) {
- rmesa-hw.ctx.cmd[CTX_RB3D_CNTL] |= R200_ROP_ENABLE;
- } else {
- rmesa-hw.ctx.cmd[CTX_RB3D_CNTL] = ~R200_ROP_ENABLE;
- }
-}
-
-static void r200BlendFuncSeparate( GLcontext *ctx,
-GLenum sfactorRGB, GLenum dfactorRGB,
-GLenum sfactorA, GLenum dfactorA )
+/**
+ * Calculate the hardware blend factor setting. This same function is used
+ * for source and destination of both alpha and RGB.
+ *
+ * \returns
+ * The hardware register value for the specified blend factor. This value
+ * is already shifted for source factor, but needs to be reshifted for
+ * destination factor.
+ *
+ * \todo
+ * Since the two cases where source and destination are handled differently
+ * are essentially error cases, they should never happen. Determine if these
+ * cases can be removed.
+ */
+static int blend_factor( GLenum factor, GLboolean is_src )
{
- r200ContextPtr rmesa = R200_CONTEXT(ctx);
- GLuint b = rmesa-hw.ctx.cmd[CTX_RB3D_BLENDCNTL]
- ~(R200_SRC_BLEND_MASK | R200_DST_BLEND_MASK);
+ int func;
- switch ( ctx-Color.BlendSrcRGB ) {
+ switch ( factor ) {
case GL_ZERO:
- b |= R200_SRC_BLEND_GL_ZERO;
+ func = R200_SRC_BLEND_GL_ZERO;
break;
case GL_ONE:
- b |= R200_SRC_BLEND_GL_ONE;
+ func = R200_SRC_BLEND_GL_ONE;
break;
case GL_DST_COLOR:
- b |= R200_SRC_BLEND_GL_DST_COLOR;
+ func = R200_SRC_BLEND_GL_DST_COLOR;
break;
case GL_ONE_MINUS_DST_COLOR:
- b |= R200_SRC_BLEND_GL_ONE_MINUS_DST_COLOR;
+ func = R200_SRC_BLEND_GL_ONE_MINUS_DST_COLOR;
break;
case GL_SRC_COLOR:
- b |= R200_SRC_BLEND_GL_SRC_COLOR;
+ func = R200_SRC_BLEND_GL_SRC_COLOR;
break;
case GL_ONE_MINUS_SRC_COLOR:
- b |= R200_SRC_BLEND_GL_ONE_MINUS_SRC_COLOR;
+ func = R200_SRC_BLEND_GL_ONE_MINUS_SRC_COLOR;
break;
case
