[PATCH 5/6] wined3d: Use PBOs for dynamic volumes

[Stefan Dösinger]

Am 23.08.2013 um 11:34 schrieb Henri Verbeet <hverbeet at gmail.com>:
> Why does loading into a PBO require CPU access?
The only reason why we want to store a volume in a PBO is to map it, which requires CPU access. If the volume doesn't allow CPU access I don't see a reason to load it into a PBO.

Well, there's RGB<->sRGB loading in case GL_EXT_texture_sRGB_decode isn't supported. I am handing that with a temporary heap allocation and don't go through the tracked locations to keep the matter simple. The correct fix for this problem, if it happens, is to implement sRGB_decode in the driver.

>> +        case WINED3D_LOCATION_BUFFER:
>> +            if (!volume->pbo || !(volume->flags & WINED3D_VFLAG_PBO))
>> +            {
>> +                ERR("Trying to load WINED3D_LOCATION_BUFFER without setting it up first.\n");
>> +                return;
>> +            }
> I think there should never be a PBO without WINED3D_VFLAG_PBO being
> set.
Yup, but it's an ERR path, so neither condition is supposed to ever be true. The thinking behind checking both is as a safeguard for future code changes. I'm checking resource.allocatedMemory and resource.heap_memory in the sysmem case for the same reason.

> There's also something to be said for leaving out the return,
> since that would at least in theory allow the compiler to drop the
> extra checks when compiled without debug messages.
Good point.