<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 22, 2013 at 12:36 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="im">On Fri, Nov 15, 2013 at 9:58 PM, Mark Mueller <<a href="mailto:markkmueller@gmail.com">markkmueller@gmail.com</a>> 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>
</div>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>
<span class=""><font color="#888888"><br></font></span></blockquote><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Mark</div></div><br></div></div>