[Mesa-dev] [PATCH V2 4/4] i965: Enable ext_framebuffer_multisample_blit_scaled on intel h/w

[Anuj Phogat]

On Fri, May 24, 2013 at 2:41 PM, Eric Anholt <eric at anholt.net> wrote:
> Paul Berry <stereotype441 at gmail.com> writes:
>
>> On 16 May 2013 11:44, Anuj Phogat <anuj.phogat at gmail.com> wrote:
>>
>>> This patch enables ext_framebuffer_multisample_blit_scaled extension
>>> on intel h/w >= gen6.
>>>
>>> Note: Patches for piglit tests to verify this functionality are out
>>> for review on piglit mailing list. Tests pass for all of the scaling
>>> factors from 0.1 to 2.4.
>>>
>>> Comment from Paul Berry:
>>> I have some concerns about the image quality of the method you've
>>> implemented.  As I understand it, the primary use case of this extension
>>> is to allow the client to do multisampled rendering at slightly less
>>> than screen resolution (e.g. 720p instead of 1080p), and then blit the
>>> result to the screen in one step while keeping most of the quality
>>> benefits of multisampling.  Since your implementation is effectively
>>> equivalent to downsampling and then blitting using GL_NEAREST filtering,
>>> my fear is that it will lead to blocky artifacts that are severe enough
>>> to negate the benefit of multisampling in the first place.
>>>
>>> Before we turn this extension on in the Intel driver, I'd like to look
>>> at a comparison of:
>>>
>>> (1) your technique
>>> (2) downsampling followed by scaling with GL_LINEAR filtering
>>> (3) The nVidia implementation, in GL_SCALED_RESOLVE_FASTEST_EXT mode
>>> (4) The nVidia implementation, in GL_SCALED_RESOLVE_NICEST_EXT mode
>>> (5) Just rendering the image directly to the single-sampled destination
>>> buffer
>>>
>>> Observation: Image quality is better in cases 2, 3, 4 and 5 as
>>> compared to case 1. Although extension's implementation meets the
>>> specification's requirements, using it leads to  blocky artifacts
>>> due to nearest filtering.
>>>
>>> I'll work on implementing a better filtering technique in blorp.
>>>
>>
>> Thanks for quoting my comment here.  It's good to have context so that we
>> can continue the discussion.
>>
>> My preference would be to go ahead and land patches 1-3 now, but hold patch
>> 4 back until we've figured out how to get comparable image quality to the
>> nVidia implementation.  It seems like it would be nice to go out of the
>> gate with our best looking implementation.
>>
>> Does that seem reasonable to other folks?
>
> Yeah, I don't think should ship a nearest-filtered-only implementation.

Sounds reasonable to me. I'll hold this patch till we achieve desirable
quality.