| Summary: | RFE: Increase Mesa MAX_WIDTH and MAX_HEIGHT to 8192 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Roland Mainz <roland.mainz> |
| Component: | Mesa core | Assignee: | Roland Mainz <roland.mainz> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | high | CC: | ajax, alanh, eich, mesa-dev |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | Patch for 2004-04-26-trunk | ||
|
Description
Roland Mainz
2004-04-30 11:19:15 UTC
Created attachment 252 [details] [review] Patch for 2004-04-26-trunk I've tested the patch half the day... so far glxgears, chromium, Quake2 and TuxRacer did not show any problems... Alan: Is the patch OK for you ? No, Mesa currently doesn't work with Xinerama. Let me qualify that a little more... Mesa which is provided by libGLcore.a in the X server doesn't support Xinerama. Alan Hourihane wrote:
> Let me qualify that a little more...
> Mesa which is provided by libGLcore.a in the X server doesn't support Xinerama
What will happen if someone tries to run a GLX application on a Xinerama display
?
> > Roland Mainz wrote:
> > Alan:
> > Is the patch OK for you ?
> Alan Hourihane wrote:
> No, Mesa currently doesn't work with Xinerama.
OK... what about Xprint then... what is all affected with increasing the
MAX_WIDTH/MAX_HEIGHT values ? A quick "grep" over the sources shows that these
#defines are only used to limit the maximum dimensions of the rasterizer and do
not affect the rasterizing process itself... or am I wrong with that ?
The window will be blank on the second, third, fourth etc screens. Only the first will have the correct image. would the Mesa from DMX work? Comment on attachment 252 [details] [review] Patch for 2004-04-26-trunk Alan Hourihane: I didn't found any regressions within the last two months with the patch applied - can I commit the patch, please ? Alan: Did you get the bugmail for the last comment ? Yesterday's bugzilla email seems to be lost somehow... ;-( Roland, I don't think you've probably done enough testing. Have you actually tried with compiling stand-alone Mesa and using 4x4 configuration of 1600x1200 displays and maximizing windows etc ? I'm certainly not comfortable that increasing it to this size wouldn't introduce overflow errors. I've talked to Brian Paul before about this. If you are really concerned about it, then post to the mesa3d-devel lists at sourceforge to start the discussion. (In reply to comment #11) > I don't think you've probably done enough testing. Have you actually tried > with compiling stand-alone Mesa and using 4x4 configuration of 1600x1200 > displays and maximizing windows etc ? I've tried and tested what I can do with my laptop (1600x1200) and then I tested the same with Xvfb at 2560x2048 and at 4096x4096. That was working properly so far. > I'm certainly not comfortable that increasing it to this size wouldn't > introduce overflow errors. I've talked to Brian Paul before about this. Correct me if I am wrong - any possible problem will NOT affect existing configurations at lower (e.g. >= 2048x2048) resolutions, right ? So why worry about that ? MAX_WIDTH and MAX_HEIGHT are mainly used for sizing arrays and to clamp some values - they are not involved in "real" calculations, right ? > If you are really concerned about it, then post to the mesa3d-devel lists at > sourceforge to start the discussion. Umpf... ;-/ We can only find issues when we actually test the code with these values set. I've done what I can do from my side, IMHO we should now let other people test whether they can find any issues with this values (we can undo that easily via restoring the original values so the risk is quite low). Do what you must Roland. I've told you how I think you should proceed, but you don't have to take my advice on it - it's open source after all. Oh, and regardless of the MAX_WIDTH/MAX_HEIGHT the floating point routines used in Mesa are the candidates for overflow. cc'ing the mailing list for comments. it might be preferable to not have the width and height fixed at compile time but instead inferred from env variables at runtime. Alan Hourihane wrote:
> Do what you must Roland. I've told you how I think you should proceed, but you
> don't have to take my advice on it - it's open source after all.
Umpf... this really wasn't tought as offense... we're just in hurry since there
are now less than two weeks left until the freeze. Right now we didn't found any
bugs so my proposal would be to try it in CVS trunk and let other people test
it. AFAIK you're the module owner and it's your decision to accept or to reject
the patch and I would not even dare to checkin anything which touches Mesa
without your permission :)
product shift I can't change those constants at this time. I'd have to do a lot of testing to be sure the change was safe in all cases. The issue is in rasterization accuracy/precision. We use fixed point arithmetic in a number of places during rasterization. If there aren't enough fractional bits, rasterization of a large triangle could turn out wrong. Colors might also be mis-interpolated. I'm not 100% certain that only large primitives could be effected by the change. Unfortunately, making MAX_WIDTH/HEIGHT into run-time limits would be a lot of work. There might be some real problems to solve too. marking this as wontfix, since a simple bump is not the solution. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.