MOL voodoo1/2 support

[Benjamin Herrenschmidt]

>On Sun, Sep 01, 2002 at 05:32:24PM +0200, cjw wrote:
>> On Tue, 27 Aug 2002 samuel@ibrium.se wrote:
>> 
>> > iii) Write a generic mac side MOL driver for video acceleration.
>> > It is a bit difficult to obtain information from Apple how to
>> > write an accelerated video driver though (and I believe there
>> > is a NDA involved too).
>> 
>> For 2D accelleration I'd think you just override the low-level QuickDraw
>> functions. MacOS has API calls for that. When MOL is running in X we can
>> then just pass the info to X and the linux accellerated video driver
>> should pick it up. 
>
>OK. The 2D MacOS part seems to be workable. In a first step, it
>would probably be sufficient to just intercept copybits calls.

There are several things here. You can:

 - Hack to put your own "bottleneck" routines into the various
GrafPorts used by MacOS, though I doubt that would work properly

 - Patch the standard ones '_StdBits' etc..., though I don't know
how easy this is with recent versions of MacOS, I suspect some
TVEC patching might be a better solution than trap patching (there
is a nice library for that called MoreCFMPatches as part of the
MoreIsBetter package from Apple).

Both above solutions will require you to deal with all sort of cases
that those functions have to deal with, it will be a real pain to
implement them.

 - Use the video driver acceleration API of NQD, which is not
documented publically, only available under NDA, but provides must
useable hooks for implementing 2D accel in MacOS < X. Maybe, now
that MacOS < X is dying, Apple would be willing to soften access
to those APIs ? I used to have them (and may still have an old
copy) though I can't do anything opensource with that currently.

>The X part might be slightly problematic; X does not allow mapping
>of video RAM directly. The framebuffer is kept in shared RAM through
>the MIT shared mem extension. Consider for instance the example
>of moving a solid window. Since the RAM based framebuffer
>has to be kept up to date, it would be necessary to perform the
>operation on it (as is done now, by MacOS). Instead of blitting
>the (updated) framebuffer to VRAM, one could instruct X to do
>a VRAM -> VRAM copy though (which ought to be virtually 
>without cost).
>
>THe performance gain would be due to the reuced traffic
>on the PCI/AGP bus. I'm not sure how large the performance
>gain would be; at least on remote X connections it would be
>quite significant.
>
>Another solution is writing a XFree86 module which could allow
>us to map a piece of unused VRAM directly. The module would
>then take care of any VRAM -> VRAM blitting.
>
>One should also investigate the possibility to use RGB overlays.
>Last I checked, only the YUV color modes were implemented (these
>are used to for TV and DVD).

We could also implement real YUV overlay in MacOS for quicktime
video playback ;) It's done via a special kind of codec in QT.

>> With MOL running directly on a VC it would be a bit
>> harder because as far as I could see the X accellerated video drivers do
>> about the same as the MacOS ones so you can't easily call them from MOL.
>
>The VC modes are hard, yes. However, one could use the X11
>DGA extensions for fullscreen video instead of the VC implementation.
>I've thought about adding this functionality anyway.
>
>So... is there anyone on this list who feels like giving this a shot?

Honestly, I don't want to dive into this, from what I know of MacOS,
it sounds terribly complex and definitely out of the time I can spare
to Linux and MOL, but If anybody is brave enough, then I'll be helping
as much as I can.

Ben.