On Fri, Nov 22, 2013 at 3:06 PM, Marek Olšák <mar...@gmail.com> wrote:
> 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. > 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
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
