No subject

"if mask includes DEPTH_BUFFER_BIT or STENCIL_BUFFER_BIT, and filter is
not NEAREST, no copy is performed and an INVALID_OPERATION error is
generated.


>>
>>> Some hw will potentially be unable to do this (I don't know how
>>> deferred renderers would do that, for example).
>>> Also, allowing regions might also be very difficult to do for some
>>> hardware, and yes glBlitFramebuffer allows this but I'm not sure
>>> it's really worth having this in the interface - I doubt anyone
>>> ever will use this anyway, so it would be nice if we could keep
>>> that out of drivers. Just doing another copy for the odd testcase
>>> trying this seems ok to me.
>> There will always be at least 1 application that does something you
>> didn't expect, and it will be needlessly slow with our drivers.
> That's always possible, apps do crazy things sometimes.
> 
>>
>>> For the same reason I don't like the y-flip very much. I see though
>>> how that could be very useful. I guess drivers not able to do this
>>> natively could just do the copy themselves (ok they could do that
>>> with the regions too).
>>> Frankly glBlitFrameBuffer can do a lot of things and I'm not sure
>>> it makes a lot of sense to cram all that functionality into
>>> resource_resolve. Though if other driver writers agree I could be
>>> convinced.
>>>
>> nv50+ can happily do all of the above in one go.
>>
>> Every fallback you can do in a state tracker can be done equally well
>> from within drivers through shared utility code, compare u_blit and
>> u_blitter.
>> The difference is, if a driver does *not* have to use the slow path,
>> it
>> is, for a change, *not* *forced* to do so anyway by a state tracker.
> Yes, but there's some value in keeping the driver interface clean.
> 
> Roland