On Sun, Aug 3, 2014 at 6:35 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Sun, Aug 3, 2014 at 12:28 PM, Marek Olšák <mar...@gmail.com> wrote:
>> On Sun, Aug 3, 2014 at 6:06 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote:
>>> On Sun, Aug 3, 2014 at 11:18 AM, Marek Olšák <mar...@gmail.com> wrote:
>>>> + enum pipe_format int_formats[] = {
>>>> + PIPE_FORMAT_R32G32B32A32_UINT,
>>>> + PIPE_FORMAT_R32G32B32A32_SINT,
>>>
>>> Uhm... should this be R8G8B8A8 instead? At least that's what's in the
>>> format_map in st_format.c for GL_RGBA_INTEGER_EXT. (And it doesn't
>>> include the UINT variant...)
>>
>> It doesn't matter which formats are tested as long as at least one
>> format in the list is supported for MSAA texturing. I assume all
>> drivers that support MSAA integer texturing support it with all
>> integer formats. R32G32B32A32 seemed like a safe choice.
>
> For nv50 it'll still work out since you'll check lower MS levels, but
> e.g. we have:
>
> if (sample_count == 8 && util_format_get_blocksizebits(format) >= 128)
> return FALSE;
>
> I wouldn't be surprised if the 128-bit wide thing were a restriction
> elsewhere too. Especially since the old format check was for RGBA8,
> that seems like the more prudent thing to do, IMO.
>
> -ilia
Okay, consider it changed to R8G8B8A8_SINT.
Marek
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
