Roland Scheidegger wrote:
Richard F Weber wrote:
Roland Scheidegger wrote:
Ok, I found the notes that indicate this. But then my next question,
You are correct, the radeon 7x00 (and also the 8500/9100/9000/9200)
have a maximum opengl context size of 2048x2048. This was mentioned briefly in some windows reviews I've seen. You can get this information from ATI's linux binary driver (though it doesn't list the old radeons explicitly for obvious reasons, but I'm pretty
sure it has the same limits). "NOTES (about monitor configurations): ... (4) The maximum resolution for OpenGL operation are: - R200 family (Radeon 8500-9000 Pro, Fire GL 8700/8800/E1): 2048x2048 - R300 family (Radeon 9500-9700 Pro, Fire GL X1/Z1): 2560x2560"
is how come Win2K allows me to do this? I ran a simple Qt Gears example under Win 2k, dual head, 2560x1024, and it was quite happy. Under Linux, once it hits the 2048 boundary, the same demo goes blooey.
You mean it does run not only on the second head, but full screen on
both heads? Interesting.
Yup.
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.
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.
(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
------------------------------------------------------- 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
