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