Am 23.08.2013 um 11:34 schrieb Henri Verbeet hverbeet@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.