<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 3:06 PM, Marek Olšák <span dir="ltr"><<a href="mailto:maraeo@gmail.com" target="_blank">maraeo@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Fri, Nov 22, 2013 at 10:45 PM, Mark Mueller <<a href="mailto:markkmueller@gmail.com">markkmueller@gmail.com</a>> wrote:<br> ><br> ><br> ><br> > On Fri, Nov 22, 2013 at 12:36 PM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br> >><br> >> On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller <<a href="mailto:markkmueller@gmail.com">markkmueller@gmail.com</a>><br> >> wrote:<br> >> ><br> >> ><br> >> ><br> >> > On Fri, Nov 15, 2013 at 9:52 AM, Marek Olšák <<a href="mailto:maraeo@gmail.com">maraeo@gmail.com</a>> wrote:<br> >> >><br> >> >> I don't understand this and I don't think this is the right way to<br> >> >> implement hw-accelerated TexImage. Some of the formats are unsupported<br> >> >> by all hardware I know, others just don't make any sense (e.g.<br> >> >> RGBA5999_REV).<br> >> ><br> >> ><br> >> > Please check out st_choose_matching_format. This is what the function<br> >> > comment says:<br> >> > /**<br> >> > * Given an OpenGL user-requested format and type, and swapBytes state,<br> >> > * return the format which exactly matches those parameters, so that<br> >> > * a memcpy-based transfer can be done.<br> >> > *<br> >> > * If no format is supported, return PIPE_FORMAT_NONE.<br> >> > */<br> >> ><br> >> > My patch allows for similar functionality without using Gallium<br> >> > PIPE_FORMATs, which aren't supported in the i965 driver. RGPA5999_REV is<br> >> > there because it is used by a the glean test case pixelFormats. Having<br> >> > hardware support for the added formats is not relevant.<br> >><br> >> Why is it not relevant? If there is no hardware support, adding those<br> >> formats is a waste of time. Will the formats be unpacked by shaders or<br> >> what? The MESA_* formats have only one purpose: to be used as OpenGL<br> >> textures and renderbuffers.<br> >><br> > Yes, that's the nature of GPU based texture uploading. The driver generates<br> > a shader and the GPU does the necessary unpacking from a cached memcpy of<br> > the application texture and stuffs it into the final mip tree in its target<br> > tiled format. In order to do that, the driver must know the original format<br> > of the texture, which can't be done from the current choices of gl_formats,<br> <br> </div></div>This is not true. Drivers have access to the parameters of TexImage<br> and are allowed to do with them whatever they want, so they do know<br> the exact format of user data. I don't see why you want new texture<br> formats while all you need is a shader that can read raw bytes and do<br> the unpacking. If you used a blit instead of a shader and your<br> hardware had fixed-function circuitry to read the new formats, that<br> would be an entirely different story.<br> <br> If I implemented shader-based unpacking, I would probably use a<br> texture buffer object and common formats like R8UI, R16UI, R32UI, same<br> for RG, RGB, and RGBA and also the signed variants, but not much else.<br></blockquote><div><br></div><div>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:</div> <div><br></div><div><div> MESA_FORMAT_BGR_INT8,</div><div> MESA_FORMAT_BGR_UINT8,</div><div> MESA_FORMAT_BGR_INT16,</div><div> MESA_FORMAT_BGR_UINT16,</div><div> MESA_FORMAT_BGR_FLOAT16,</div><div> MESA_FORMAT_BGR_INT32,</div> <div> MESA_FORMAT_BGR_UINT32,</div><div> MESA_FORMAT_BGR_FLOAT32</div><div><br></div><div>There are also RGB, RGBA, and BGRA formats missing. Completeness seems like justification enough for their inclusion:</div><div> <br></div><div><div> /* Red Green Blue */</div><div> MESA_FORMAT_RGB233_REV,</div><div> MESA_FORMAT_RGB101111_REV,</div><div><br></div></div><div> /* Red Green Blue Alpha */</div><div> MESA_FORMAT_RGBA1010102,</div> <div> MESA_FORMAT_RGBA2101010_REV,</div><div> MESA_FORMAT_RGBA5999_REV,</div><div> MESA_FORMAT_RGBA4444,</div><div> MESA_FORMAT_RGBA4444_REV,</div><div> MESA_FORMAT_RGBA1555_REV,</div><div><br></div><div> /* Blue Green Red Alpha */</div> <div> MESA_FORMAT_BGRA_INT8,</div><div> MESA_FORMAT_BGRA_INT8_REV,</div><div> MESA_FORMAT_BGRA_UINT8,</div><div> MESA_FORMAT_BGRA_INT16,</div><div> MESA_FORMAT_BGRA_UINT16,</div><div> MESA_FORMAT_BGRA_FLOAT16,</div> <div> MESA_FORMAT_BGRA_INT32,</div><div> MESA_FORMAT_BGRA_UINT32,</div><div> MESA_FORMAT_BGRA_FLOAT32,</div><div> MESA_FORMAT_BGRA4444,</div><div> MESA_FORMAT_BGRA4444_REV,</div><div> MESA_FORMAT_BGRA5551,</div> <div> MESA_FORMAT_BGRA1555_REV,</div><div> MESA_FORMAT_BGRA1010102,</div><div> MESA_FORMAT_BGRA2101010_REV,</div><div> MESA_FORMAT_BGRA5999_REV,</div><div> </div><div>Mark</div><div><br></div></div><div><br></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> <div class="im"></div></blockquote><br></div></div></div>