On Sun, Aug 3, 2014 at 1:07 PM, Marek Olšák <mar...@gmail.com> wrote:
> 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
OK, well, the series looks good to me. Feel free to add a Reviewed-by:
Ilia Mirkin <imir...@alum.mit.edu> . However you may want to let it
sit for a little while for others to review.
-ilia
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
