On Mon, 2003-07-14 at 12:56, Richard F Weber wrote: > > 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. > > Now a couple of weirdness things. > 1) If I maximize the window, the entire window goes blank except for > about for the left ~600 pixels. That far left is still drawing that > portion of the window. Sort of like: > > ------------------------------------------------- > ---------------------- --------------------- > |xxxxxxxx | | | > |xxxxxxxx | | | > |xxxxxxxx | | | > ---------------------- --------------------- > <--1280--> <--1280--> > x = Drawn area > > -------------------------------------------------- > > > 2) Just noticed this one. If the window is maximized, and you have > another dialog on top of it, Everything to the left of that dialog is > drawn correctly. Up until the window hits the 2048 mark on one side. > > ------------------------------------------------- > ---------------------- --------------------- > |xxxxxxxx | | | > |xxxxxxxxxxxxxxxxxxxx| |xxxWW | > |xxxxxxxx | | | > ---------------------- --------------------- > <--1280--> <--1280--> > x = Drawn area > W = Dialog on top of OpenGL Window
Oh well, it seems that I have trusted the name of the register too easily: RADEON_RE_WIDTH_HEIGHT . Both your description and the DRM code in radeon_emit_clip_rect() suggest that it should rather be called RADEON_RE_RIGHT_BOTTOM, i.e. the right and bottom borders are limited to 2048, not the width and height. :( Sorry folks. > Now the weird thing is I booted up in Win2k, and you can run an > acclerated OpenGL application full-screen, or move the window anywhere > and it seems to work fine. So it looks like it is _possible_ to run > OpenGL on a wide desktop, just don't know how ATI does it. Indeed, I don't see how they can do it except by treating both screens separately such that they never hit the 2048 limit. -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer ------------------------------------------------------- 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/bulletproofapps1 _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
