| Summary: | R300 regression caused by git change aceccda56b08338e217991e54607f1c9f18fc3e6 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Phil Armstrong <phil> | ||||||
| Component: | General | Assignee: | Default DRI bug account <dri-devel> | ||||||
| Status: | RESOLVED INVALID | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | DRI git | ||||||||
| Hardware: | x86 (IA32) | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
Phil Armstrong
2008-01-18 15:25:23 UTC
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.