I think your really confused on how things fit together. I'd be really hard pushed to see how a multithreaded application is causing the 2D driver to fail. It's more likely that the 2D driver has problems anyway and the multithreaded app is triggering this.
The DRI won't help you at all for this. Alan. On Thu, Nov 07, 2002 at 04:15:15PM +0000, khellman wrote: > Hello all: > > I'm working on incorporating a Geode accelerated driver into a LC > build. During the process, I've weaseled our X11 (4.2.1) build down a > fair bit - in part by removing GL support. > > My final defect is that a multithreaded application displaying 4 > distinct changing images in a quad screen seems to be incurring race > conditions in the graphics pipeline. Somehow I need to implement > locking in the Geode DDX driver. When I started looking around, it > seems that DRI/DRM is the established way to do this - here are my > questions or concerns: > > - We don't need GL support, and I would rather keep it out of our X > server for space reasons. Is it possible to use DRI/DRM locking > without GL support compiled in? I did not see an X build flag in > config/cf for this feature. > - The documentation states that each hardware component supported > requires a kernel module, gl/mesa module, and an XAA module. I have > none of these (the DDX driver doesn't even have a geode_dri.c file). > Is it feasible to implement a simple (locking only) kernel module, a > lobotomized GL module, and incorporate a geode_dri.c in a short period > of time? If the architecture would support this, how many LOC would > you estimate? I realize that if my first question is negative, this > point is moot. > > My alternative to implementing limited DRI support is to simply hardcode > the locking into the Geode DDX driver (thank goodness for open source). > My first thought was to have a kernel module lock held during > accelerated routines; the design of the DDX seems to lend itself to > this; each OP has a SetupOP() and a DoOP() routine. The km lock would > be held accross these two calls, other requests would stall in a wait > queue. > > Reading through the documentation and reviewing some debugging results > makes me second guess this solution. Would this type of locking stall > the Xserver when it went into the wait queue? > > I'm still diggin' round in the source & documentation; but I felt I had > enough info to post these questions. > > TIA & please cross followup to [EMAIL PROTECTED] > > -- > Keith Hellman > Software Engineer > [EMAIL PROTECTED] > Voice: 303.477.7757 > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Dri-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/dri-devel ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
