[directfb-dev] Re: [PATCH] Preliminary AGPONLY support

["Henric Andersson" <ha@thedudes.nu>]

Maybe a stupid question (but I don't know alot about gfxcards n'stuff), what
is the advantage of doing this? How is it done today and why isn't it good
enough?

/Henric - A curious little bastard ;)

----- Original Message -----
From: Ville Syrjälä
To: directfb-dev@directfb.org
Sent: Wednesday, December 11, 2002 1:28 AM
Subject: [directfb-dev] [PATCH] Preliminary AGPONLY support


Ok here's what I've got done with DSCAPS_AGPONLY surface support. Not
exactly cvs ready (TM) yet.

Currently allocates one large chunk of AGP memory. Size is the minimum of
aperture size, actually available AGP memory or value supplied with
'agpmem-limit' option.

I had to add dfb_gfxcard_get_alignment_limits() (horrible name, I know)
function to get the hw limits for the surface manager.

The matrox driver gained some more ugliness and two new fields to the
device struct. CheckState{G100,Old} reject AGP surfaces as they can't use
them.

Some TODOs that come to mind:
- Some way to gracefully fail if AGP init fails. I don't think it's a
good idea to abort the whole process if AGP has trouble.
- User should be able to disable AGP. agpmem-limit=0? Could use the
same stuff as the previous item.
- Better policies than CSP_AGPONLY.
- Test single-app core (didn't do that yet) and test if multi-app
actually works with more than one app.
- Non Matrox cards??

--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/



-- 
Info:  To unsubscribe send a mail to listar@directfb.org with 
"unsubscribe directfb-dev" as subject.