[Mesa-dev] [PATCH 1/2] mesa: Add gl_formats to cover all GLUser provided format/type combinations

[Mark Mueller]

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>
> wrote:
> >
> >
> >
> > 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>
> wrote:
> >> >>
> >> >> 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
> unsupported
> >> >> 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
> state,
> >> >  * 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
> is
> >> > 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
> generates
> > 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
> target
> > tiled format. In order to do that, the driver must know the original
> format
> > of the texture, which can't be done from the current choices of
> gl_formats,
>
> 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
missing:

   MESA_FORMAT_BGR_INT8,
   MESA_FORMAT_BGR_UINT8,
   MESA_FORMAT_BGR_INT16,
   MESA_FORMAT_BGR_UINT16,
   MESA_FORMAT_BGR_FLOAT16,
   MESA_FORMAT_BGR_INT32,
   MESA_FORMAT_BGR_UINT32,
   MESA_FORMAT_BGR_FLOAT32

There are also RGB, RGBA, and BGRA formats missing. Completeness seems like
justification enough for their inclusion:

   /* Red Green Blue */
   MESA_FORMAT_RGB233_REV,
   MESA_FORMAT_RGB101111_REV,

   /* Red Green Blue Alpha */
   MESA_FORMAT_RGBA1010102,
   MESA_FORMAT_RGBA2101010_REV,
   MESA_FORMAT_RGBA5999_REV,
   MESA_FORMAT_RGBA4444,
   MESA_FORMAT_RGBA4444_REV,
   MESA_FORMAT_RGBA1555_REV,

   /* Blue Green Red Alpha */
   MESA_FORMAT_BGRA_INT8,
   MESA_FORMAT_BGRA_INT8_REV,
   MESA_FORMAT_BGRA_UINT8,
   MESA_FORMAT_BGRA_INT16,
   MESA_FORMAT_BGRA_UINT16,
   MESA_FORMAT_BGRA_FLOAT16,
   MESA_FORMAT_BGRA_INT32,
   MESA_FORMAT_BGRA_UINT32,
   MESA_FORMAT_BGRA_FLOAT32,
   MESA_FORMAT_BGRA4444,
   MESA_FORMAT_BGRA4444_REV,
   MESA_FORMAT_BGRA5551,
   MESA_FORMAT_BGRA1555_REV,
   MESA_FORMAT_BGRA1010102,
   MESA_FORMAT_BGRA2101010_REV,
   MESA_FORMAT_BGRA5999_REV,

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131122/79b55c2b/attachment.html>