[Mesa-dev] [Bug 47375] Blender crash on startup after upgrade to mesa 8.0.1

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Thu Jul 26 17:24:19 PDT 2012


--- Comment #40 from Roland Scheidegger <sroland at vmware.com> 2012-07-27 00:24:19 UTC ---
I was actually wondering, do we really need the fallback when there's
PixelTransfer state? Clearly this applies to DrawPixels, but doesn't this also
apply to TexImage() calls hence mesa would just do that when we create the
texture out of the pixel data to draw a quad?
(Of course the fastest way to handle scale/bias transfer state would probably
be to just use MODULATE/ADD/MODULATE_ADD tex combiner so mesa wouldn't have to
do that in software - one of scale/bias could use tex env color whereas if we
have both could just set up a source color too).
FWIW the _ImageTransferState fallback decision looks quite bogus in any case -
this state includes for instance rgb_scale but not depth_scale, hence when
drawing to a depth texture the fallback decision is probably not quite right
(though I guess just skipping fallback would break drawing to stencil buffer,
since this is set up as a alpha texture mesa would probably incorrectly apply
rgb transfer ops there - but that's certainly solvable without having to resort
to fallback).
Also fog fallback shouldn't apply to depth/stencil buffer drawing neither (but
OTOH enabled texturing should cause a fallback for color buffer drawing, even
though I'd guess if some app really does a drawpixels with enabled fog or
texturing it is probably by mistake not intentionally...).

--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -2280,8 +2280,7 @@ _mesa_meta_DrawPixels(struct gl_context *ctx,
     * Determine if we can do the glDrawPixels with texture mapping.
    fallback = GL_FALSE;
-   if (ctx->_ImageTransferState ||
-       ctx->Fog.Enabled) {
+   if (ctx->Fog.Enabled) {
       fallback = GL_TRUE;

Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

More information about the mesa-dev mailing list