On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller <markkmuel...@gmail.com> wrote: > > > > On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák <mar...@gmail.com> wrote: >> >> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller <markkmuel...@gmail.com> >> wrote: >> > >> > >> > >> > On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák <mar...@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. > 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. I understand this very well. I did the same thing for Gallium. Also, avoiding CPU-GPU stalls has nothing to do with packing and unpacking the pixels. It's a completely independent issue. Marek _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
