-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2013-11-27 18:56, schrieb Henri Verbeet:
Doing conversions in the blitter allows them to be done on either the GPU or the CPU, depending on what's appropriate.
I don't think it is worth the trouble. Since we introduced the SNORM and RG conversion code it has never been a performance problem. I haven't seen any application that streams SNORM or RG data. The return of investment would be nonexistent from a user point of view.
While optionally doing the conversion on the GPU sounds nice on paper, it means adding another codepath where one of them won't get proper testing, no matter how well it is integrated.
I also think it's just the right place conceptually. It's correct that this would require some work on the blitter to be able to correctly express some of the conversions.
I disagree, for a number of reasons:
The GL format conversion has to work on volumes as well. Do we want to draw them into the blitter?
The similarities between the GL format conversion and the surface->surface blitter are limited. Both convert formats, but the former doesn't have to care about sizes, stretching etc. The amount of conversion logic that can be shared is limited. Maybe the RG->RGB expansion code can be shared, if d3d9::StretchRect allows a RG_FLOAT->RGBA_FLOAT blit. But the algorithm that does that is really simple.
surface_blt is a god call already by Microsoft's design. I don't think we should add more to it.
On the other hand, the patch we are discussing isolates the GL format conversion in surface_upload_data and volume_upload_data. The conv-update.diff patch frees the location management from conversion constraints. I believe those changes are reasonable improvements.