WineD3D BltOverride overhaul

[Roderick Colenbrander]

On Wed, Mar 24, 2010 at 1:19 PM, Henri Verbeet <hverbeet at gmail.com> wrote:
> On 24 March 2010 12:53, Roderick Colenbrander <thunderbird2k at 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.
>

I have experimented a bit with the design (intially only color fill
since that's quite independent). Note this is just a proof of concept
(some of the helper functions would become separate patches). This
patch is the current code in the new form. In a later stage an FBO
blit_shader can be added which can call the FBO based color fill but
that's quite easy to extend later on. At this point no context setup
is needed since the helpers already do that but after this is all
over, they could be moved over to this framework to make it a bit
nicer.

Roderick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: colorfill.diff
Type: text/x-diff
Size: 17849 bytes
Desc: not available
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20100324/324404b8/attachment-0001.diff>