Playing half-life 2 under wine, I thought I'd try the micro-tiling patches which allow DXT compression with multitexturing to work correctly. Unfortunately it turns out that git HEAD has introduced some fairly visible rendering errors, combined with a very obvious performance drop (without the microtiling patches applied: this is just the dri git sources). Doing a git bisect narrows the problem down to this change: phil@kantaka:~/code/DRI/mesa-bisect$ git bisect good aceccda56b08338e217991e54607f1c9f18fc3e6 is first bad commit commit aceccda56b08338e217991e54607f1c9f18fc3e6 Author: Kristian Høgsberg <krh@hinata.boston.redhat.com> Date: Thu May 10 15:52:22 2007 -0400 Drop __DRInativeDisplay and pass in __DRIscreen pointers instead. Many DRI entry points took a __DRInativeDisplay pointer and a screen index as arguments. The only use for the native display pointer was to pass it back to the loader when looking up the __DRIscreen for the given screen index. Instead, let's just pass in the __DRIscreen pointer directly, which let's drop the __DRInativeDisplay type and the getScreen function. The assumption is now that the loader will be able to retrieve context from the __DRIscreen pointer when necessary. :040000 040000 4c70ec7d8475ee44b25b4d900bf8088e29f30f72 231d46d59379c83c7d7af8a8ff6734cdbbb25cb5 M include :040000 040000 6d0383baa53e0b3cc3f4995c6541d8d41386ca8a 17e2b60c4c7d4435b14de5eaa59cc6266549bb7a M src I'll attach screenshots of the output of both this code and that which immediately preceeds it. It's possible that the DRM code is correct and wine is doing something wrong of course. I don't see any performance regression with quake3. The hardware is an AGP Radeon 9550: 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 AS [Radeon 9550] [1002:4153] Platform: Linux kantaka 2.6.23-1-686 #1 SMP Fri Dec 21 13:57:07 UTC 2007 i686 GNU/Linux (Debian unstable as of today) Wine version 0.9.52
Created attachment 13783 [details] Screenshot with rendering errors
Created attachment 13784 [details] Correct screenshot (from immediately preceeding changeset)
Addendum: this is all with texture compression turned off. Obviously if you turn it on you get similar errors thanks to the DXT/multitexturing bug on r300 git that the microtiling patches fix. cheers, Phil
I think this change or surrounding changes broke the interface between DRI driver and loader, did you check that direct rendering was always used?
glxinfo confirms that direct rendering is working with the broken version: phil@kantaka:~/code/DRI/mesa-bisect/lib$ LD_LIBRARY_PATH=`pwd` LIBGL_DRIVERS_PATH=`pwd` glxinfo name of display: :0.0 display: :0 screen: 0 direct rendering: Yes ... Plus, quake3 plays fine with the same drivers. I'll try with the git HEAD libdrm kernel module just in case that's making a difference.
No change with the kernel modules from git drm: I see exactly the same behaviour. cheers, Phil
Is there any difference in glxinfo output before and after the regression? If not, maybe Kristian has ideas what could be going on.
From mesa 7.0.2, the release immediately after the git changeset adds GL_ARB_depth_texture, GL_ARB_blend_logic_op and GL_SGIX_depth_texture Both have direct rendering on. I'll compile up the immediately preceeding changeset to see if there's any differences introduced at this point. Extra weirdness: it seems that I get the rainbow textures (but not the slowdown) with drm git kernel modules and 7.0.2 mesa userspace drivers. Very odd. cheers, Phil
Ah. The "extra weirdness" appears to be because the latest stable mesa release in Debian is ignoring ~/.drirc & therefore using DXT textures regardless of the choices made in driconf. I guess I'll be filing another bug for that one. Perhaps that's why I'm getting the rainbow textures with git mesa as well? Doesn't explain the slowdown however :(
(NB downgrading to the last Debian mesa release fixes the ignoring ~/.drirc bug)
To be more specific: the s3tc settings don't seem to be being applied by the latest mesa stable release in Debian unstable: I don't know whether it's actually reading the drirc file or not. I'll check ASAP & file then appropriate bugs if necessary.
I'm going to close this bug on the grounds that I obviously can't get any useful debug information & I think there's another bug here (which I'll make a separate report on if the git-bisect does anything sane) which is confusing the issue. (Currently, I suspect the slowdown may be due to other libGL versions lying around, whilst the display corruption is real, but unrelated.) cheers, Phil
Addendum: the rendering errors appear to be down to a single patch in mesa. I'll file a separate bug for that. The slowdown with HEAD comes and goes :(
NB. The rendering errors were nothing to do with the prescence or abscence of S3TC, but the symptoms were exactly the same (so presumbly it's another mutitexturing issue of some sort), hence the confusion Apologies for the bugzilla noise. Phil
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.