[Mesa-dev] [PATCH 03/12] st/mesa: make st_init_extensions context-independent

Ilia Mirkin imirkin at alum.mit.edu
Sun Aug 3 18:00:35 PDT 2014


On Sun, Aug 3, 2014 at 1:07 PM, Marek Olšák <maraeo at gmail.com> wrote:
> On Sun, Aug 3, 2014 at 6:35 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> On Sun, Aug 3, 2014 at 12:28 PM, Marek Olšák <maraeo at gmail.com> wrote:
>>> On Sun, Aug 3, 2014 at 6:06 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>>>> On Sun, Aug 3, 2014 at 11:18 AM, Marek Olšák <maraeo at 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

OK, well, the series looks good to me. Feel free to add a Reviewed-by:
Ilia Mirkin <imirkin at alum.mit.edu> . However you may want to let it
sit for a little while for others to review.

  -ilia


More information about the mesa-dev mailing list