--- Michel D�nzer <[EMAIL PROTECTED]> wrote: > On Thu, 2003-08-28 at 16:31, Alex Deucher wrote: > > > > On a related note, I've been thinking about alternative ways to > > implement mergedfb on radeon hardware. what if instead of creating > a > > single framebuffer with two viewports, we stuck with the old style > > pScrn based multi-head code, but made each head a client of the > DRI? > > What do you mean by 'client of the DRI'? And how would this be > 'merged'? > :) >
ummm... yeah... it wouldn't be merged. it would just act similarly. ;) by client I mean that each head would share access to the 3D engine, like 3D applications do now. > > the 3D engine would be shared by each head. This seems to be the > way > > the 2D engine works in pScrn based multi-head now. > > The difference is that the 2D engine is only used by the X server, > whereas the 3D engine is used by every 3D client, and the 3D driver > still assumes that the locations of the front, back and depth buffers > never change for a context. And that's just one of many problems with > Xinerama. good point. I tend to think client/server by default since I'm used to the 2D. If we got HW accelerated indirect rendering working, then this should work since everything would go through the X server right? What about having independant front, back and depth buffers per head? > > > would doing this potentially get around the issues with the scissor > > > registers limiting us to 2048x2048 for 3D? > > Sure, the limit is per screen. > > __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
