Am Montag, 14. Juli 2003 14:33 schrieb Richard F Weber: > Dieter Nützel wrote: > >Am Montag, 14. Juli 2003 12:56 schrieb Richard F Weber: > >>Michel Dänzer wrote: > >>>On Mon, 2003-07-14 at 02:59, Alex Deucher wrote: > >>>>--- Michel Dnzer <[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>><snip> > >>>> > >>>>>It's not clear to me what exactly you have tried, please describe in > >>>>>more detail. > >>>> > >>>>I created a virtual framebuffer of size 2080x480. I then started an > >>>>instance of glxgears and resized the window to about 3/4 of the size of > >>>>the frambuffer. I then started a second instance of glxgears and > >>>>placed it next to the first instance, then resized it. it resized fine > >>>>until I hit the 2048 boundry, then the window (the one I was resizing), > >>>>went black; the first window was still showed gears. resizing smaller, > >>>>the gears came back when I crossed the 2048 boundry again. > >>> > >>>Weird, I don't understand what would cause the window to go blank. What > >>>happens when you enlarge a single window beyond 2048, does it go blank > >>>as well, or is the rendering cropped to 2048? In the latter case I > >>>suspect this is a different problem. > >> > >>Sorry for jumping in, but I found the bug and initially posted comments > >>to it on dri-users. > >> > >>I'll go over the basics quickly. I've got a dual-head running > >>1280x1024 (virtual 2560x1024) on both heads using the mergedfb code to > >>create a single desktop. If I create an opengl application it works > >>fine placing the window anywhere, up until 1 side of it hits the 2048 > >>mark. Once it hits 2048, the entire window goes blank. Doesn't matter > >>how large or small the window is, once it crosses 2048, it's done. If I > >>move the window back away from the border, the window shows it's > >>contents again. Judging from the framerates, the calculation is > >>actually occurring in the background, but it's just not rendering to the > >>screen. Framerates jump from ~650 to ~1300 when the window doesn't draw > >>to the screen. > > > >[-] > > > >>I'm running a Radeon 7500 VE dual-head, and if you need me to run any > >>tests, or sample code, let me know and I'll do the best I can. > > > >Can you please try "stex3d"? > >It shows wrong rendering/clipping even if you run a single head and move > > the window to the right side of the screen (1280x1024x24/32). > >Snapshots available if needed. > > Ok. Weird result (at least for me). > > First off, I'm running RH 9.0 which comes with Mesa 4.3.0 and no > MesaDemos are available. So I downloaded Mesa 5.0.1, compiled it and > the demos, and it works. > > Ran stex3d, and some of the other demos and they work across the entire > screen. I then installed the librares into /usr/local/lib, did an > export LD_LIBRARY_PATH=/usr/local/lib, and ran glxgears, and now > glxgears is happy. > > However, based on the framerates (~360 vs. ~650) I'd say it's doing > software rendering. Checking ldd indicates they are static, and further > digging show they were linked against the Mesa 5.0.1 libraries > > I then hacked the demos and told them to use my system, 4.3.0 libraries > and rebuilt. And well, the results are more normal. > > 1/2 the demos don't work (mainly because the extensions aren't present), > but that's besides the point. > > gears works as expected (dies @ 2048). stex3d does some real weird > stuff. (See attached image) > > So is the answer it's a bug in the Mesa libraries?
I point at the radeon/r200 driver. All fine with software Mesa 5.0.2 (setenv LIBGL_ALWAYS_INDIRECT). > I guess the next > step would be to recompile 5.0.1 with HW support and test that, right? DRI CVS on-top of your setup. GL_VERSION: 1.3 Mesa 5.0.2 GL_RENDERER: Mesa DRI R200 20030328 AGP 4x x86/MMX+/3DNow!+/SSE TCL I get the error. -Dieter
<<attachment: stex3d-1.png>>
