[Bug 30002] [regression r300g] Menu problem in Tiny and Big

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Mon Sep 6 21:56:41 PDT 2010


https://bugs.freedesktop.org/show_bug.cgi?id=30002

--- Comment #9 from Ian Romanick <idr at freedesktop.org> 2010-09-06 21:56:40 PDT ---
(In reply to comment #7)
> (In reply to comment #1)
> > The handling of textures with a 0 width, height, or depth is an odd corner case
> > in the spec, so it's not too surprising that it's not handled correctly.
> > 
> >      "where ws, hs, and ds are the specified image width, depth, and depth,
> >      and wt, ht, and dt are the dimensions of the texture image internal to
> >      the border. If wt, ht, or dt are less than zero, then the error INVALID
> >      VALUE is generated.
> > 
> >      An image with zero width, height, or depth indicates the null texture.
> >      If the null texture is specified for the level-of-detail specified by
> >      texture parameter TEXTURE BASE LEVEL (see section 3.8.4), it is as if
> >      texturing were disabled."
> > 
> > The last bit is the tricky part.  You have to create the texture but disable
> > texturing on any unit where it is bound.  We could use a piglit test for this
> > corner case.
> 
> Interesting. Should this be part of Gallium's API as well, or should we handle
> it one level up and make these textures illegal in Gallium? Does anybody know
> what Dx does?

This is a quirk of the OpenGL API.  I think it's pretty clear that this is
something that should be completely handled by core Mesa.  The driver should
never see the request for the 0x0 texture.  When the texture is bound to a
texture unit, Mesa should disable that unit.

-- 
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 dri-devel mailing list