--- Richard F Weber <[EMAIL PROTECTED]> wrote: > > > >> So I guess my next questions are: 1) is the 2048x2048 a HW > >> limitation, or a SW/implementation limitation > > > > AFAIK the maximum size of the GL context is a hardware issue. > However, > > it shouldn't matter where it is displayed, that is it should work > on the > > second head as well (hardware-wise), as long as the height or width > of > > the GL window doesn't exceed 2048. If it doesn't work in that > manner, > > that's probably because how the driver handles the GL contexts. > > I think I mentioned it below, but I found some docs indicating that > the > 2048x2048 is a limitation on the viewport to the framebuffer. But if > > that's the case, then I'd expect the mergedfb stuff to have a > problem.
I haven't been able to test mergedfb with a 3D context of 2048x2048 or larger since my m6 only has 8 mb of ram. > > > > >> 2) Since my card is a dual-head, could it/should it be 2048x2048 > per > >> head, rather than for the whole card? > > > > No, that limit is per GL-context afaik. > > Well, my next question is how do you indicate that a context should > be > offset (ie: Start running at 1280x0 instead of 0x0). I'd like to > test > that first to see if I can get an OpenGL app running full screen on > my > second head. According to Michel Danzer, you may be able to support up to 4096x4096 using two cliprects, see this quote from another email: > I think there may be a limitation of a max 3D context of 2048x1536, so > that may be the max virtual desktop available, someone with better > knowledge of the 3D stuff wouldbe better able to answer that. AFAICT, the fact that the RE_WIDTH_HEIGHT register only takes 11 bits for width and height each basically limits us to a virtual resolution of 2048x2048 for 3D rendering. However, RE_TOP_LEFT also takes 11 bits each, so we might be able to push it to 4096x4096 by using several cliprects if necessary. There might be other limitations I'm overlooking though. > > > > >> (I don't think so, but just trying to hit every possibility) > > > > > >> 3) How the heck does Windows allow an OpenGL app to be run across > >> both displays? > > > > I know I've seen tests where wider than 2048 pixel GL contexts > didn't > > work in windows (but of course they did run on the second head). If > that > > really does work now I'm surprised and ATI must have used some > magic in > > the driver (maybe something like splitting a GL context into two?). > > > I wonder if something similar could be done in Linux. I imagine the > work would have to be done at the DRI level to break up a requested > context into two sub-contexts. I'm not familiar with the layering of > > APIs, but I could conceivably see that this could go in the DRI > general, > DRI for Radeon, or Mesa. I'd think the DRI general would be the best > > solution (since it'd allow other problematic cards to be fixed), but > the > easiest solution would be the Radeon DRI solution. > > Of course Easy is a relative term... :) > > > > >> 4) Since the release note is for the driver from ATI, it only > really > >> supports the cards listed. So in that case, could it just be that > >> ATI only implemented 2048x2048? > > > > I believe the max size is REALLY a hardware limit, but the hardware > > doesn't limit you where it's displayed - that's the driver (note I > > can't test how ATI's driver really behaves on dual heads). > > Let me know any specific tests you have. I've got a dual-boot system > in > Win2K & RH 9.0. > > > > >> I'm not an XFree86 guru (or even really a graphics HW guru), but > are > >> the specs available to double-check the max context resolution? > > > > Some people reading this should have hardware documentation, but I > > don't... Though it's possible the people having hardware > documentation > > are only reading dri-devel ;-) > > I think you might be right above. ATI might be splitting the context > in > two somehow. But the other weird thing is the refresh rate. Under > Linux, I'm running at 85Hz on both monitors. Under W2k, 60Hz. So I > wonder if under Win2k they are running the card in a different mode > other than a framebuffer mode. > > > --Rich > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ------------------------------------------------------- This SF.Net email sponsored by: Parasoft Error proof Web apps, automate testing & more. Download & eval WebKing and get a free book. www.parasoft.com/bulletproofapps _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
