[Mesa-dev] [PATCH] nv50: implement multisample textures

Bryan Cain bryancain3 at gmail.com
Sat Oct 26 00:22:55 CEST 2013


On 10/25/2013 05:05 PM, Christoph Bumiller wrote:
> On 25.10.2013 23:51, Bryan Cain wrote:
>> On 10/25/2013 04:11 PM, Christoph Bumiller wrote:
>>> On 25.10.2013 20:35, Emil Velikov wrote:
>>>> On 21/10/13 23:23, Bryan Cain wrote:
>>>>> This is a port of 4da54c91d24da ("nvc0: implement multisample textures") to
>>>>> nv50.
>>>>>
>>>>> When coupled with the patch to only report 16 texture samplers (to fix
>>>>> crashes), all of the Piglit tests in spec/arb_texture_multisample pass.
>>>>>
>>>> Hello Bryan,
>>>>
>>>> Big thanks for your work. As promised here is a quick piglit summary on
>>>> my nv96
>>>>
>>>> pass/fail/crash
>>>> 69/32/27
>>>>
>>>> * dmesg does not spit anything nouveau related during the tests
>>>> * any geometry shader related tests were skipped
>>>> (piglit: info: Failed to create GL 3.2 core context)
>>>> * all the crashes are due to the following assert
>>>> codegen/nv50_ir_emit_nv50.cpp:1393:emitTEX: Assertion `argc <= 4' failed.
>>> I'm not sure how you'd get > 4 arguments there (x y layer sample ?).
>>> There's no mip maps for multisample textures.
>>>
>>> But either way you're probably going to have to do things by hand:
>>> E.g. MS8 textures contain contiguous 4x2 rectangles of samples for each
>>> pixel, so you multiply x by 4 and y by 2 to arrive at the sub-rectangle
>>> and then add the correct offsets for the sample id as seen in
>>> get_sample_position (store the info in a constant buffer, that has to be
>>> updated when texture changes).
>>>
>>> You might want to use a lookup table like in nve4 compute (look for "MS
>>> sample coordinate offsets") to map sample id to coordinate offset, that
>>> one works for any sample count as long as you don't use the ALT modes
>>> (nve4 doesn't need to for textures, but for images/surfaces/UAVs/RATs
>>> where the whole VM address calculation is done by hand).
>> You're probably right.  I don't know why MSAA appears to work for me,
>> but there's probably something wrong with the output that I haven't
>> noticed.  I'll work on implementing it properly this weekend.
> MSAA itself (rendering and resolving) has been working before, the only
> thing that ARB_texture_multisample adds is texelFetch from MS resources.

I really should read an extension's spec carefully before trying to
implement it so that I don't waste other people's time.  Sorry.

Bryan


More information about the mesa-dev mailing list