[Mesa-dev] [PATCH 1/2] mesa: Add gl_formats to cover all GLUser provided format/type combinations
markkmueller at gmail.com
Fri Nov 22 18:59:10 PST 2013
On Fri, Nov 22, 2013 at 3:06 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller <markkmueller at gmail.com>
> > On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák <maraeo at gmail.com> wrote:
> >> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller <markkmueller at gmail.com>
> >> wrote:
> >> >
> >> >
> >> >
> >> > On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák <maraeo at gmail.com>
> >> >>
> >> >> I don't understand this and I don't think this is the right way to
> >> >> implement hw-accelerated TexImage. Some of the formats are
> >> >> by all hardware I know, others just don't make any sense (e.g.
> >> >> RGBA5999_REV).
> >> >
> >> >
> >> > Please check out st_choose_matching_format. This is what the function
> >> > comment says:
> >> > /**
> >> > * Given an OpenGL user-requested format and type, and swapBytes
> >> > * return the format which exactly matches those parameters, so that
> >> > * a memcpy-based transfer can be done.
> >> > *
> >> > * If no format is supported, return PIPE_FORMAT_NONE.
> >> > */
> >> >
> >> > My patch allows for similar functionality without using Gallium
> >> > PIPE_FORMATs, which aren't supported in the i965 driver. RGPA5999_REV
> >> > there because it is used by a the glean test case pixelFormats. Having
> >> > hardware support for the added formats is not relevant.
> >> Why is it not relevant? If there is no hardware support, adding those
> >> formats is a waste of time. Will the formats be unpacked by shaders or
> >> what? The MESA_* formats have only one purpose: to be used as OpenGL
> >> textures and renderbuffers.
> > Yes, that's the nature of GPU based texture uploading. The driver
> > a shader and the GPU does the necessary unpacking from a cached memcpy of
> > the application texture and stuffs it into the final mip tree in its
> > tiled format. In order to do that, the driver must know the original
> > of the texture, which can't be done from the current choices of
> This is not true. Drivers have access to the parameters of TexImage
> and are allowed to do with them whatever they want, so they do know
> the exact format of user data. I don't see why you want new texture
> formats while all you need is a shader that can read raw bytes and do
> the unpacking. If you used a blit instead of a shader and your
> hardware had fixed-function circuitry to read the new formats, that
> would be an entirely different story.
> If I implemented shader-based unpacking, I would probably use a
> texture buffer object and common formats like R8UI, R16UI, R32UI, same
> for RG, RGB, and RGBA and also the signed variants, but not much else.
How about let's forget the whole concept of GPU loading for a moment as
that is only clouding the issue. As you said: "the mesa_* formats have one
purpose: to be used as OpenGL textures...." When I read the OGL spec for
glTexImage2D it lists GL_BGR as a format. Yet looking at mesa_* formats
there is only one BGR format represented: MESA_FORMAT_BGR888. There are 8
other valid OGL BGR textures that don't have MESA_FORMATs while all of the
RGBs ones _are_ all there? ie. these are the OGL BGR formats that are
There are also RGB, RGBA, and BGRA formats missing. Completeness seems like
justification enough for their inclusion:
/* Red Green Blue */
/* Red Green Blue Alpha */
/* Blue Green Red Alpha */
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev