[Mesa-dev] [PATCH 1/2] st: fix st_choose_matching_format to ignore intensity

[Chris Forbes]

This should provide reasonable behavior for those paths too -- the
combination of these two patches preserves the current behavior for
st_choose_matching_format. It's not quite ideal (I believe actual use
of intensity formats in some situations will miss the fast path), but
it's no worse.

I'm not really comfortable making much more intrusive changes to
gallium -- this is only to correct a regression caused by fixes for
ARB_clear_buffer_object on i965 & swrast.

On Sun, Mar 30, 2014 at 1:46 PM, Marek Olšák <maraeo at gmail.com> wrote:
> However st_choose_matching_format is also used by other clients such
> as TexImage, GetTexImage, and ReadPixels, so this should really be
> fixed in the problematic caller of st_choose_matching_format, that is
> DrawPixels.
>
> Marek
>
> On Sat, Mar 29, 2014 at 7:48 PM, Chris Forbes <chrisf at ijw.co.nz> wrote:
>> On Sun, Mar 30, 2014 at 12:50 AM, Marek Olšák <maraeo at gmail.com> wrote:
>>
>>> Why is this needed?
>>
>> The second patch fixes format/type to mesa_format matching for
>> intensity formats, so that texture uploads / buffer object clears /
>> etc can get the memcpy paths. (Previously, we were testing on pixel
>> format = GL_INTENSITY, which is nonsense and disallowed by earlier
>> checks.)
>>
>> Unfortunately, the intensity mesa_formats are listed before their red
>> equivalants in the formats, so we'd end up picking an intensity format
>> for DrawPixels( GL_RED, ...
>>
>> If that happens, then the actual draw later in DrawPixels would write
>> <I, I, I, I> to the destination, rather than <R, 0, 0, 1>.
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=76601
>> https://bugs.freedesktop.org/show_bug.cgi?id=76602