Michael Lorenz wrote:

>Hello,
>
>  
>
>>I can't find the paper, but it looks like this is the PXG graphics
>>architecture, and there is stuff for this in sys/arch/pmax/dev/px.c. 
>>Apparently this graphics hardware is not directly mapable to the CPU,
>>so they have to use a command packet type of interface.
>>    
>>
>
>well, some drivers don't access framebuffer memory directly ;)
>
>  
>
>>I'm not proposing quite this level of removal.  I still want to
>>provide for directly mapped framebuffers, but I also want allow for
>>hardware acceleration of some 2D operations.
>>    
>>
>
>The only reason I suggested something packet-oriented is the ability to
>pass more than one command, queue them and run them asynchronously, at
>least on hardware that provides command completion or pipeline low water
>interrupts. Obviously we'd also need something to signal when it's safe
>to access framebuffer memory. ( I just don't like the thought of the CPU
>actively waiting for the blitter to do its work when it could do
>something useful instead. On a Radeon that's probably not too
>relevant but on older hardware it may be different. )
>
>Something else - if at all possible please allow your driver to work as
>a semi-dumb wsdisplay that could be used by XFree and its radeon driver,
>for instance on sparc64 and macppc where we can't (or don't want to) use
>vga. For both we have dumb OpenFirmware framebuffer drivers but being
>able to use acceleration for the console would be nice. 'Semi-dumb' as
>in no VRAM tricks, use whatever video mode the firmware set up but use
>the blitter for scrolling, rectangle filling, probably character
>drawing.
>  
>
This might be hard for me to do.  I am not going to rely on "the
firmware", because on our processor we might not have firmware
initialization of the card.  So I have to do a lot of that stuff myself
(making this driver an "interesting" bit of code.)

Additionally, I want to be able to manage CRTCs, etc. from the kernel. 
The X11 radeon driver wants to take over the whole chip, and the two
things are quite likely to get in each others way.

However, after I've written the code, if someone else wants to go back
in and try to figure out how to modify the code so that it can do that,
without destroying the ability to act more intelligently for
applications like mine, they will be welcome to do so.

(The vga driver is horribly pc-centric.  Someone should really update it
to be a little more friendly to other platforms.  I tried to make it
work on a MIPS cpu and gave up after much struggling with it.)

    -- Garrett

>have fun
>Michael
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134