http://bugs.winehq.org/show_bug.cgi?id=12557
--- Comment #56 from Tobias Jakobi liquid.acid@gmx.net 2008-05-04 08:11:36 --- (In reply to comment #53)
On nvidia i've issues with readtex in these games (http://bugs.winehq.org/show_bug.cgi?id=12890). With default settings it works visually ok on geforce 2 mx and geforce 6100, although on geforce2 mx performance is poor (just few fps vs what feels like at least 20-30 fps on windows xp in 1024x768).
Does wine really create such high amount of overhead?
Don't know about the color lines. Considering the effect of RT lock mode setting, i guess it's glDrawPixels that produces issues? I guess it may be worth seeking some non-wine opengl tests or demos that do read/draw pixels a lot. If same thing shows up there then obviously it's not wine's problem.
Any application/demo you can suggest?
I'm going to file a bugreport for mesa nonetheless. If the radeon OS driver is also affected this may be a bug that's affecting more than one card.
Still no answer from the mesa3d-users ml yet. I'm going to try bumping some of my gfx components to GIT, maybe I can get the features this way. Currently I'm suspecting that the mesa build system still creates the ordinary "old" i915 driver. Why do I think that? I can find 4 libs in /usr/lib/dri: i810_dri.so i915_dri.so i915tex_dri.so i965_dri.so
According to my knowledge about the mesa i915 driver development the i915tex_dri.so should not exist at all. There should be only one lib, the i915_dri.so - so I tried to symlink i915tex_dri.so to i915_dri.so, resulting in indirect rendering. Reason was a too old DRM interface (LIBGL_DEBUG=verbose).
My DRM interface version is 1.6.0 and the i915tex driver wants a 1.7.x interface. So the i915 driver seems to be satisfied with only the old 1.6.0 interface. Another proof more me that I'm not using the modern driver rewrite, since this one uses TTM and the more recent goodies from the DRM tree.