From: Felix <fx...@gm...> - 2002-03-28 23:46:24
|
Hi, when I move a gl window to the right and/or bottom edge of the screen, a one pixel wide line/row is not redrawn correctly. Sometimes parts of previous frames remain visible and even hide new stuff. It looks to me as if the z-buffer is not cleared in that line/row. I can reproduce the problem with the xscreensaver circuit demo, quake2 without fullscreen and quake1. Probably more non-fullscreen apps which draw till the edge of the window. My color depth is 16 bits. I tried the resolutions 1152x864 and 1024x768. While I was experimenting with different color depths I saw some more problems. With 24 bits I see everything like through a mesh, but slightly different meshes in different parts of the screen. It is black in the beginning but it can be overwritten by very close objects like my own gun (sometimes) or the polygons drawn to flash the screen. So it may be z-buffer related as well. With 15 bits colors look strange. I guess the driver generates 16 bit colors and puts them on a 15 bit screen. And in quake3 fullscreen the resolution is not changed. I just get a small quake3 "window" in the bottom left corner of a black screen. But that might be a problem in the Xvidmode extension, not the DRI. With 15 bits I have the same artefacts on the right/bottom edge. With 24 bits ... I can't tell ;-) Regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Leif D. <lde...@re...> - 2002-03-29 00:59:18
|
On Fri, 29 Mar 2002, Felix K=FChling wrote: > Hi, >=20 > when I move a gl window to the right and/or bottom edge of the screen, > a one pixel wide line/row is not redrawn correctly. Sometimes parts of > previous frames remain visible and even hide new stuff. It looks to me > as if the z-buffer is not cleared in that line/row. Actually, this is probably a problem with scissors/clipping. If a polygo= n=20 edge extends beyond the scissor a line is drawn along the scissor=20 boundary. I'll check it out. > I can reproduce the problem with the xscreensaver circuit demo, quake2 > without fullscreen and quake1. Probably more non-fullscreen apps which > draw till the edge of the window. >=20 > My color depth is 16 bits. I tried the resolutions 1152x864 and > 1024x768. While I was experimenting with different color depths I saw > some more problems. With 24 bits I see everything like through a mesh, > but slightly different meshes in different parts of the screen. It is=20 > black in the beginning but it can be overwritten by very close objects=20 > like my own gun (sometimes) or the polygons drawn to flash the screen.=20 > So it may be z-buffer related as well. With 15 bits colors look=20 > strange. I guess the driver generates 16 bit colors and puts them on a=20 > 15 bit screen. And in quake3 fullscreen the resolution is not changed.=20 > I just get a small quake3 "window" in the bottom left corner of a black= =20 > screen. But that might be a problem in the Xvidmode extension, not the=20 > DRI. >=20 > With 15 bits I have the same artefacts on the right/bottom edge. With=20 > 24 bits ... I can't tell ;-) Only 16 and 32 bit depths are currently supported. 32 bit is mostly untested, I think. I'm suprised you actually get direct rendering with 1= 5 or 24, I thought it would be disabled. --=20 Leif Delgass=20 http://www.retinalburn.net |
From: Felix <fx...@gm...> - 2002-03-29 10:17:54
|
> Only 16 and 32 bit depths are currently supported. 32 bit is mostly > untested, I think. I'm suprised you actually get direct rendering > with 15 > or 24, I thought it would be disabled. It was slower than 16 bit with both 15 and 24 bits, but still a lot faster than indirect rendering. Strange, when I try to start the xserver with 32 bits I get the following messages in the end of XFree86.0.log: (EE) ATI(0): Driver does not support depth 32 at fbbpp 32. (II) UnloadModule: "ati" (II) UnloadModule: "atimisc" (II) Unloading /usr/X11R6-mach64003/lib/modules/drivers/atimisc_drv.o (EE) Screen(s) found, but none have a usable configuration. Regards, Felix __\|/__ ___ ___ ___ __Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___ _____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____ fx...@gm... >o<__/ \___/ \___/ at the same time! |
From: Leif D. <lde...@re...> - 2002-03-29 21:13:57
|
On Fri, 29 Mar 2002, Felix K=FChling wrote: > > Only 16 and 32 bit depths are currently supported. 32 bit is mostly > > untested, I think. I'm suprised you actually get direct rendering > > with 15 > > or 24, I thought it would be disabled. >=20 > It was slower than 16 bit with both 15 and 24 bits, but still a lot=20 > faster than indirect rendering. > Strange, when I try to start the xserver with 32 bits I get the=20 > following messages in the end of XFree86.0.log: >=20 > (EE) ATI(0): Driver does not support depth 32 at fbbpp 32. > (II) UnloadModule: "ati" > (II) UnloadModule: "atimisc" > (II) Unloading /usr/X11R6-mach64003/lib/modules/drivers/atimisc_drv.o > (EE) Screen(s) found, but none have a usable configuration. OK, here's what I've found out. The DDX driver doesn't support depth 32 a= t fbbpp 32, but depth 24 at fbbpp 32 is supported, so using a depth of 24 i= n XF86Config should work. I just discovered that the problem with depth 24 is with the depth buffer. I should have that fixed soon. Running at depth 15 should disable direct rendering right now. The problem was that the framebuffer bpp is still 16 with depth 15, and the driver was looking at the framebuffer bpp, so direct rendering wasn't being disabled. --=20 Leif Delgass=20 http://www.retinalburn.net |
From: Leif D. <lde...@re...> - 2002-03-30 03:32:15
|
On Fri, 29 Mar 2002, Leif Delgass wrote: > On Fri, 29 Mar 2002, Felix K=FChling wrote: >=20 > > > Only 16 and 32 bit depths are currently supported. 32 bit is mostl= y > > > untested, I think. I'm suprised you actually get direct rendering > > > with 15 > > > or 24, I thought it would be disabled. > >=20 > > It was slower than 16 bit with both 15 and 24 bits, but still a lot=20 > > faster than indirect rendering. > > Strange, when I try to start the xserver with 32 bits I get the=20 > > following messages in the end of XFree86.0.log: > >=20 > > (EE) ATI(0): Driver does not support depth 32 at fbbpp 32. > > (II) UnloadModule: "ati" > > (II) UnloadModule: "atimisc" > > (II) Unloading /usr/X11R6-mach64003/lib/modules/drivers/atimisc_drv.o > > (EE) Screen(s) found, but none have a usable configuration. >=20 > OK, here's what I've found out. The DDX driver doesn't support depth 32= at > fbbpp 32, but depth 24 at fbbpp 32 is supported, so using a depth of 24= in > XF86Config should work. I just discovered that the problem with depth = 24 > is with the depth buffer. I should have that fixed soon. Running at > depth 15 should disable direct rendering right now. The problem was th= at > the framebuffer bpp is still 16 with depth 15, and the driver was looki= ng > at the framebuffer bpp, so direct rendering wasn't being disabled. I've hardcoded 16bpp for the depth buffer in the kernel init struct and=20 this seems to fix rendering at 24 bit color depth (32 bpp framebuffer).=20 The problem seemed to be with depth buffer clears which were being done a= t=20 32bpp instead of 16bpp. I'm still a bit confused about this however. It seems from the screen init (ATIScreenInit) that a 32bpp depth buffer is allocated. The texture memory is calculated assuming 3 equal buffers for front, back, and depth buffers. Texture memory is FB mem - 3 * buffer size - pixmap cache. Other drivers such as r128 and radeon seem to use a 24bpp depth buffer, optionally with an interleaved 8 bit stencil buffer. The Z coordinate register of the mach64 setup engine only uses 16 bits, so anything more than that would seem to be unsupported or wasted. It seems like this is = a waste of memory that could be used for textures or pixmap cache. Can anyone illuminate me on this? :) --=20 Leif Delgass=20 http://www.retinalburn.net |