On 24 March 2010 12:53, Roderick Colenbrander thunderbird2k@gmail.com wrote:
Now back to the blitter design. Henri's proposal is to have several blitters for this discussion reduce it to shader_blit and cpu_blit. The cpu_blit would be the software fall back for a blit, colorfill or whatever operation.
It's not necessarily a fallback, it's certainly possible that if e.g. both surfaces are in sysmem doing the blit on the CPU is going to be faster than doing a upload/blit/download sequence. (Which is only allowed because we're sloppy about resource pools in the first place.) A sysmem->GPU blit is essentially just an upload with an appropriate buffer, format flags, etc. There's also the possibility for e.g. an SSE based implementation, behind proper capability checking.
A potential (but perhaps ugly) design of a cpu fallback, could be to just call IWineD3DBaseSurface. A more drastic approach would basically be to kill the IWineD3DBaseSurface fallbacks and have ONE Blt and BltFast in surface.c which would just fall back to software when OpenGL isn't around. What do you think?
Calling IWineD3DBaseSurface is probably good enough for a start. I'd probably start with identifying the different blit functions inside BltOverride() and the logic for selecting them. Then you can separate those into functions, after which you can create separate blitter implementations. Once we have those we can work on cleaning up individual implementations, selection logic, etc.