> Date: Mon, 19 May 2008 13:54:01 -0400
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h
> CC: mesa3d-dev@lists.sourceforge.net
>
> On Tue, May 13, 2008 at 9:38 PM, Kristian Høgsberg <[EMAIL PROTECTED]> wrote:
> > On Tue, May 13, 2008 at 5:04 AM, George - <[EMAIL PROTECTED]> wrote:
> >>
> >> > Date: Mon, 12 May 2008 12:25:26 -0400
> >> > From: [EMAIL PROTECTED]
> >> > To: [EMAIL PROTECTED]
> >> > Subject: Re: [Mesa3d-dev] drixorg: software renderer with dri_interface.h
> >> > CC: mesa3d-dev@lists.sourceforge.net
> >>
> >> >
> >> > Wow, that's awesome work. My initial plan was to just wrap a dri
> >> > interface around the XMesa driver, but this is much better. You drop
> >> > the XMesa middle man and use the mesa internal API directly, which
> >> > avoids hooking into the X server internals from XMesa. This also
> >> > makes it much easier to load the sw dri driver from libGL. A few
> >> > comments on the patches:
> >> >
> >> > 1. Can we call it swdri instead of drixorg? There's nothing xorg
> >> > specific about it and the hw dri drivers also work with xorg. In
> >> > fact, this makes it easy to load the sw driver from a non-X loader
> >> > (say, EGL).
> >> >
> >>
> >> that is:
> >> drivers/dri/xorg -> drivers/dri/sw
> >> xorg_dri.so -> sw_dri.so
> >> glxdrixorg.c -> glxdrisw.c
> >>
> >> right ?
> >
> > I think what Keith suggested makes sense, so let's say
> >
> > drivers/dri/xorg -> drivers/dri/swrast
> > xorg_dri.so -> swrast_dri.so
> > glxdrixorg.c -> glxdriswrast.c
> >
> >> otherwise, we'll either have dri twice in the name (swdri_dri.so) or sw dri
> >> will not follow the hw dri naming conventions (swdri.so).
> >>
> >> I'll repost the patches and use the suggested names right from the
> >> beginning.
> >>
> >>
> >> > 2. Create the __DRIconfigs in the drixorg driver and share the
> >> > __DRIconfig conversion code in glxdri2.c in the xserver (and libGL).
> >> > That's what the hw drivers do, because they know exactly what
> >> > fbconfigs they can support. That's also true for the sw dri driver.
> >> >
> >> > 3. Just add a __DRISWExtension, along the lines of
> >> > __DRIlegacyExtension instead of reusing the
> >> > createScreen/createDrawable and createContext entry points from
> >> > __DRIcoreExtension. This lets you pass in exactly the parameters
> >> > required, and only those (instead of ignoring the unused fd and sarea
> >> > handle).
> >> >
> >> > 4. Add a resizeDrawable entry point to the __DRISWExtension interface
> >> > to be called when __glXDRIdrawableResize is called from the glx
> >> > module. Not sure how to handle this when you load the sw dri driver
> >> > on the client side, but you probably don't want to do that anyway...
> >> >
> >>
> >> ok! will do after reposting the patches, unless someone wants to help :-)
> >
> > I'm taking the next couple of days off, so I'll leave it to you :) If
> > the changes above work out alright, feel free to commit the patches.
>
> Ok, I'm back and working on implementing these suggestions so we can
> get it upstream.
>
hmm, i've done 3, 4 and started on 2 ... i'll post them next weekend, any idea
on how to resolve this ?
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
