[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 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, thus I'm adding more. Recently I've made some local
improvements so the i965 driver that can produce more information from
fewer gl_formats, thus I'll be posting an updated patch soon.

If there's any question of the merits, here's an example - let's say the
application uploads a GL_RGB format and asks for a GL_UNSIGNED_SHORT_5_6_5
internal format. Tests on Ivy Bridge show that when i965 uses the CPU to
upload a 256 x 256 texture it does so at ~28 - 77 MB/sec, whereas when i965
uses the GPU, the same texture uploads at ~2400 MB/sec - including memcpy
and all. Even the most basic cases with no repacking still show a 2x - 3x
improvement because the GPU inherently handles tiling much faster. In
general the overhead of the memcpy is easily absorbed by the fact that the
graphics pipe doesn't have to stall while the CPU does the unpacking,
tiling, and repacking in the single driver thread.

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