http://bugs.freedesktop.org/show_bug.cgi?id=15567
--- Comment #8 from Matthias Hopf <[EMAIL PROTECTED]> 2008-07-08 03:28:26 PST
---
(In reply to comment #7)
> I've seen a similar backtrace with Mesa 6.5.2 (without dri). In that case it
> was caused by a fragment shader trying to fetch texels from a texture unit
> that
> didn't have any texture assigned to it.
Thanks for analyzing. Two points:
- If setting up a texture fails, the fragment shader path shouldn't be taken.
This *could* be xine's OpenGL plugin fault, but my guess is that texture upload
in Mesa runs into a subtle issue and leaves the texture undefined.
- Mesa shouldn't crash, if an undefined texture unit is accessed.
> I kluged around it with:
>
> + if (swrast->TextureSample[unit] == NULL)
> + {
> + _mesa_printf("%s: texture unit %d is NULL, ignoreing\n", __FUNCTION__,
> + unit);
> + color[0] = 1.0;
> + color[1] = 0.0;
> + color[2] = 0.0;
> + color[3] = 1.0;
> + return;
> + }
Doesn't sound too bad from my view. You can't do much more.
> I don't know if xine's doing the same thing, can you get the actual fragment
> program out of it?
The fragment program is the following:
!!ARBfp1.0
ATTRIB tex = fragment.texcoord[0];
PARAM off = program.env[0];
TEMP u, v;
TEMP res, tmp;
ADD u, tex, off.xwww;
TEX res, u, texture[0], 2D;
MUL v, tex, .5;
ADD u, v, off.xyww;
ADD v, v, off.zyww;
TEX tmp.x, u, texture[0], 2D;
MAD res, res, 1.164, -0.073; /* -1.164*16/255 */
TEX tmp.y, v, texture[0], 2D;
SUB tmp, tmp, { .5, .5 };
MAD res, { 0, -.391, 2.018 }, tmp.xxxw, res;
MAD result.color, { 1.596, -.813, 0 }, tmp.yyyw, res;
END
The images are loaded with
glTexSubImage2D (GL_TEXTURE_2D, 0, 1, 0, frame->width, frame->height,
GL_LUMINANCE, GL_UNSIGNED_BYTE, frame->vo_frame.base[0]);
glTexSubImage2D (GL_TEXTURE_2D, 0, 1, frame->height+2, w2, h2,
GL_LUMINANCE, GL_UNSIGNED_BYTE, frame->vo_frame.base[1]);
glTexSubImage2D (GL_TEXTURE_2D, 0, w2+2, frame->height+2, w2, h2,
GL_LUMINANCE, GL_UNSIGNED_BYTE, frame->vo_frame.base[2]);
into a single preallocated texture with the following layout:
/* YUV texture layout .llllll.
* .llllll.
* lum size 6x4 -> .llllll.
* .llllll.
* empty w/ 0 (box filter y) .......
* empty w/ 0.5 (box filter u+v) /////////
* /uuu/vvv/
* u, v size 3x2 each -> /uuu/vvv/
* ///////// */
Texture allocation is done by:
this->glBindTextureEXT (GL_TEXTURE_2D, 0);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri (GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexImage2D (GL_TEXTURE_2D, 0, glformat, tex_w, tex_h,
0, texformat, GL_UNSIGNED_BYTE, tmp);
and glGetError() is checked. tex_w and tex_h are powers of two. Of course, the
texture could be too large to handle, the glGetError() should be able to find
that.
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
