<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 11, 2016 at 11:26 AM, Nanley Chery <span dir="ltr"><<a href="mailto:nanleychery@gmail.com" target="_blank">nanleychery@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Jul 26, 2016 at 10:04:22PM -0700, Jason Ekstrand wrote:<br>
> We have implicitly been not advertising these formats since we had them<br>
> turned off in the format capabilities table.  We are about to update that<br>
> table and this prevents a change in behavior.  The only change in behavior<br>
> created by this patch is that we no longer advertise support for<br>
> R16G16B16_FLOAT which means that it's now renderable which seems like a<br>
> bonus.  Maybe someday we'll want to change things to start supporting<br>
<br>
</span>I don't understand this sentence. Assuming "renderable" means that we can<br>
render to a texture with such a format, why does preventing the user from<br>
creating an R16G16B16_FLOAT texture mean that it's now renderable?<br></blockquote><div><br></div><div>Because mesa will fall back to R16G16B16A16_FLOAT and fake RGB.  That format is renderable.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Nanley<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> 16-bit RGB formats natively but, at the moment, there's no need.<br>
> ---<br>
>  src/mesa/drivers/dri/i965/brw_<wbr>surface_formats.c | 10 ++++++++++<br>
>  1 file changed, 10 insertions(+)<br>
><br>
> diff --git a/src/mesa/drivers/dri/i965/<wbr>brw_surface_formats.c b/src/mesa/drivers/dri/i965/<wbr>brw_surface_formats.c<br>
> index 2543f4b..69d3bd4 100644<br>
> --- a/src/mesa/drivers/dri/i965/<wbr>brw_surface_formats.c<br>
> +++ b/src/mesa/drivers/dri/i965/<wbr>brw_surface_formats.c<br>
> @@ -311,6 +311,16 @@ brw_init_surface_formats(<wbr>struct brw_context *brw)<br>
>        if (texture == 0 && format != MESA_FORMAT_RGBA_FLOAT32)<br>
>        continue;<br>
><br>
> +      /* Don't advertisel 8 and 16-bit RGB formats to core mesa.  This ensures<br>
> +       * that they are renderable from an API perspective since core mesa will<br>
> +       * fall back to RGBA or RGBX (we can't render to non-power-of-two<br>
> +       * formats).  For 8-bit, formats, this also keeps us from hitting some<br>
> +       * nasty corners in intel_miptree_map_blit if you ever try to map one.<br>
> +       */<br>
> +      int format_size = _mesa_get_format_bytes(format)<wbr>;<br>
> +      if (format_size == 3 || format_size == 6)<br>
> +         continue;<br>
> +<br>
>        if (isl_format_supports_sampling(<wbr>devinfo, texture) &&<br>
>            (isl_format_supports_<wbr>filtering(devinfo, texture) || is_integer))<br>
>        ctx->TextureFormatSupported[<wbr>format] = true;<br>
> --<br>
> 2.5.0.400.gff86faf<br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> ______________________________<wbr>_________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div>