[Bug 12968] Blender crashes on recent radeon dri drivers
http://bugs.freedesktop.org/show_bug.cgi?id=12968 --- Comment #8 from [EMAIL PROTECTED] 2007-11-01 02:34 PST --- Besides the crashes/machine hangs I already reported, if you notice, on Mesa version 6.4.2 (including 7.0.1 and current GIT version) half of the exactly horizontal and vertical lines are drawn incorrectly. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12968] Blender crashes on recent radeon dri drivers
http://bugs.freedesktop.org/show_bug.cgi?id=12968 --- Comment #7 from [EMAIL PROTECTED] 2007-11-01 02:30 PST --- Created an attachment (id=12292) -- (http://bugs.freedesktop.org/attachment.cgi?id=12292action=view) Part of Blender's interface drawn with Mesa GIT on a radeon card -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mapped cached memory and pre-fetching.
Dave Airlie wrote: On 10/31/07, Thomas Hellström [EMAIL PROTECTED] wrote: Dave Airlie wrote: On 10/31/07, Thomas Hellström [EMAIL PROTECTED] wrote: Dave, When starting out with TTM i did look a little at AGP caching issues and there was an issue with cached memory and speculative pre-fetching that may affect the mapped-cached memory, and that we need to know about but perhaps ignore. Suppose you bind a page to the AGP aperture, but don't change the kernel linear map caching policy. Then a speculatively prefetching processor may read the memory into its cache and then decide it doesn't want to use it, and actually write it back. Meanwhile the GPU may have changed the contents of the page and that change will be overwritten. Apparently there were big problems with AMD Athlons actually doing this. Linux people claiming it was an Athlon bug and AMD people claiming it was within specs. http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/061/6148/6148s1.html Is what I believe you are talking about, I'll add something to the comment mentioning this.. Yup. In the end I believe the change_page_attr(), global_flush_tlb() sequence was the final outcome of this, but as I understand it, with your new code we never write through the GTT, which makes the only possible problem overwrites of GPU written data. Well so far we've only dealt with Intel CPU/GPU combinations which hopefully don't suffer from this issue.. I'll put a comment in but tbh there are lots of ways to mess up things with the current APIs.. Try allocating a snooped batchbuffer, or a snooped private back buffer or anything involved in a blit I'm going to add checks for some of the more stupid things in the Intel superioctl code... Well i915 (and friends') snooped memory is, as you say not very useful, but it works fine AFAICT for things like the flip move from VRAM (which has been disabled ATM due to HW lock issues). Should also be fine for readpixels and zero copy texturing, although I doubt that there is any performance gain in the latter. /Thomas Dave. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: mapped cached memory and pre-fetching.
Thomas Hellström wrote: Dave Airlie wrote: On 10/31/07, Thomas Hellström [EMAIL PROTECTED] wrote: Dave Airlie wrote: On 10/31/07, Thomas Hellström [EMAIL PROTECTED] wrote: Dave, When starting out with TTM i did look a little at AGP caching issues and there was an issue with cached memory and speculative pre-fetching that may affect the mapped-cached memory, and that we need to know about but perhaps ignore. Suppose you bind a page to the AGP aperture, but don't change the kernel linear map caching policy. Then a speculatively prefetching processor may read the memory into its cache and then decide it doesn't want to use it, and actually write it back. Meanwhile the GPU may have changed the contents of the page and that change will be overwritten. Apparently there were big problems with AMD Athlons actually doing this. Linux people claiming it was an Athlon bug and AMD people claiming it was within specs. http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/061/6148/6148s1.html Is what I believe you are talking about, I'll add something to the comment mentioning this.. Yup. In the end I believe the change_page_attr(), global_flush_tlb() sequence was the final outcome of this, but as I understand it, with your new code we never write through the GTT, which makes the only possible problem overwrites of GPU written data. Well so far we've only dealt with Intel CPU/GPU combinations which hopefully don't suffer from this issue.. I'll put a comment in but tbh there are lots of ways to mess up things with the current APIs.. Try allocating a snooped batchbuffer, or a snooped private back buffer or anything involved in a blit I'm going to add checks for some of the more stupid things in the Intel superioctl code... Well i915 (and friends') snooped memory is, as you say not very useful, but it works fine AFAICT for things like the flip move from VRAM (which has been disabled ATM due to HW lock issues). Should also be fine for readpixels and zero copy texturing, although I doubt that there is any performance gain in the latter. FWIW, zero copy texturing is a good win when the texture is used only once, eg for video. The streamingrect application (when it was working) showed a very good improvement with the cow-pbo hack (also when it was working). To make it work transparently is quite difficult fragile though. Keith - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch] mach64 port to vblank rework
Jesse Barnes a écrit : I think this bit might cause problems. Since it doesn't look like you're using a hardware provided vblank count register, you'll want to keep vblank interrupts on after the first enable call so that it'll keep getting incremented in mach64_driver_irq_handler(), otherwise after the first disable() it'll stand still. Mostly this won't be a problem, but for some applications it's possible that it would cause them to hang or behave unexpectedly. I see that the actual vblank disabling code is also disabled for r128 which doesn't seems to have an hardware vbl count register neither. Forgive my lack of global understanding of the whole issue but my conclusion is that we just can't disable vbl interrupt on hardware which lack vbl count in hardware, right ? -- Mathieu Bérard - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch] mach64 port to vblank rework
On Thursday, November 01, 2007 11:24 Mathieu Bérard wrote: Jesse Barnes a écrit : I think this bit might cause problems. Since it doesn't look like you're using a hardware provided vblank count register, you'll want to keep vblank interrupts on after the first enable call so that it'll keep getting incremented in mach64_driver_irq_handler(), otherwise after the first disable() it'll stand still. Mostly this won't be a problem, but for some applications it's possible that it would cause them to hang or behave unexpectedly. I see that the actual vblank disabling code is also disabled for r128 which doesn't seems to have an hardware vbl count register neither. Forgive my lack of global understanding of the whole issue but my conclusion is that we just can't disable vbl interrupt on hardware which lack vbl count in hardware, right ? That's one option, yes. The other option is to calculate how many vblank interrupts have occurred between off and on periods. You could do this by recording the time when interrupts were disabled, figuring out how much time has passed between then and when they become enabled again, then dividing by the refresh rate. That should work in theory, but I don't think anyone's tried to do this in practice yet. Doing the latter will keep interrupts off more of the time, so it should save more power. Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch] mach64 port to vblank rework
Jesse Barnes a écrit : Forgive my lack of global understanding of the whole issue but my conclusion is that we just can't disable vbl interrupt on hardware which lack vbl count in hardware, right ? That's one option, yes. The other option is to calculate how many vblank interrupts have occurred between off and on periods. You could do this by recording the time when interrupts were disabled, figuring out how much time has passed between then and when they become enabled again, then dividing by the refresh rate. That should work in theory, but I don't think anyone's tried to do this in practice yet. Doing the latter will keep interrupts off more of the time, so it should save more power. That sound great but another harder to met criteria is for the drm layer to be able to keep track if the refresh rates change during an irq off period, right ? -- Mathieu Bérard - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch] mach64 port to vblank rework
On Thursday, November 01, 2007 12:06 Mathieu Bérard wrote: Jesse Barnes a écrit : Forgive my lack of global understanding of the whole issue but my conclusion is that we just can't disable vbl interrupt on hardware which lack vbl count in hardware, right ? That's one option, yes. The other option is to calculate how many vblank interrupts have occurred between off and on periods. You could do this by recording the time when interrupts were disabled, figuring out how much time has passed between then and when they become enabled again, then dividing by the refresh rate. That should work in theory, but I don't think anyone's tried to do this in practice yet. Doing the latter will keep interrupts off more of the time, so it should save more power. That sound great but another harder to met criteria is for the drm layer to be able to keep track if the refresh rates change during an irq off period, right ? Yeah, it's definitely trickier to do. Client applications should be using the new modesetting ioctl in the vblank-rework tree to tell the DRM core when the mode has changed though, so it should be possible to calculate a new refresh rate at that time (possibly by leaving interrupts on for a time until a stable number emerges or by extending the ioctl to include a refresh rate). Jesse - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Patch] mach64 port to vblank rework
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jesse Barnes wrote: The other option is to calculate how many vblank interrupts have occurred between off and on periods. You could do this by recording the time when interrupts were disabled, figuring out how much time has passed between then and when they become enabled again, then dividing by the refresh rate. That should work in theory, but I don't think anyone's tried to do this in practice yet. Doing the latter will keep interrupts off more of the time, so it should save more power. Two issues with this plan occurred to me while I was doing the MGA port. 1. The kernel doesn't (currently) have any way to know what the refresh rate is. 2. Even if it did know the refresh rate, the refresh rate can change while vblank interrupts are disabled. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHKh45X1gOwKyEAw8RAnNSAJ47MPa06urPFt3D228TzPF5AASb2wCgnZEC WzYCh+WyUVfRtZUiOuO3iCo= =XbSF -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12855] glean abort with X Error of failed request: BadDrawable
http://bugs.freedesktop.org/show_bug.cgi?id=12855 --- Comment #6 from [EMAIL PROTECTED] 2007-11-01 17:15 PST --- could you please retest on the tip? thanks. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 12855] glean abort with X Error of failed request: BadDrawable
http://bugs.freedesktop.org/show_bug.cgi?id=12855 --- Comment #7 from [EMAIL PROTECTED] 2007-11-01 17:51 PST --- seems the issue is different now with the tip, I will look into this issue to find out. following is the current result: [EMAIL PROTECTED] bin]# ./glean -r shuang api2: NOTE rgba8, db, z24, s8, win+pmap, id 33 Test skipped/non-applicable api2: NOTE rgba8, db, z24, s8, win+pmap, id 34 Test skipped/non-applicable basic: PASS rgba8, db, z24, s8, win+pmap, id 33 Segmentation fault -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11131] Mesa 6.5.2 implementation error: i915_program_error: Exceeded max nr indirect texture lookups
http://bugs.freedesktop.org/show_bug.cgi?id=11131 --- Comment #7 from [EMAIL PROTECTED] 2007-11-01 18:47 PST --- Created an attachment (id=12309) -- (http://bugs.freedesktop.org/attachment.cgi?id=12309action=view) my xorg.conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11131] Mesa 6.5.2 implementation error: i915_program_error: Exceeded max nr indirect texture lookups
http://bugs.freedesktop.org/show_bug.cgi?id=11131 --- Comment #6 from [EMAIL PROTECTED] 2007-11-01 18:46 PST --- Created an attachment (id=12308) -- (http://bugs.freedesktop.org/attachment.cgi?id=12308action=view) console log of steam running half life 2 on wine -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 11131] Mesa 6.5.2 implementation error: i915_program_error: Exceeded max nr indirect texture lookups
http://bugs.freedesktop.org/show_bug.cgi?id=11131 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #5 from [EMAIL PROTECTED] 2007-11-01 18:42 PST --- I have duplicated this bug on Ubuntu 7.10 with wine-0.9.48 and Half Life 2 with the latest updates on my acer aspire 5570 2067 with intel gma 945 chipset. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13056] New: [G33]drmOpen failed when start x
http://bugs.freedesktop.org/show_bug.cgi?id=13056 Summary: [G33]drmOpen failed when start x Product: DRI Version: XOrg CVS Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM modules AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] System Environment: -- --Platform: G33 --Architecture(32-bit,64-bit): ia32e,ia32 --3D driver: Mesa mastercommit:ee793281b221415f794af6aadaa9764023612e0b --DRM: git commit:1b176e76134224e2af94d24ff7b33c7b536eaeea --Xserver: git commit:2338d5c9914e2a43c3a4f7ee0f4355ad0a1ad9e7 --Kernel: 2.6.22 Description: when machine boot,following error messages will output: [drm] Initialized drm 1.1.0 20060810 DRM: drm_get_dev failed. after into the system,if you start a x ,following errors happen: (II) intel(0): Kernel reported 208896 total, 1 used (II) intel(0): I830CheckAvailableMemory: 835580 kB available drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::00:02.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: drmOpenMinor returns -19 drmOpenDevice: node name is /dev/dri/card1 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card10 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card11 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card12 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card13 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card14 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed (EE) [drm] drmOpen failed. (EE) intel(0): [dri] DRIScreenInit failed. Disabling DRI. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13058] New: [i915 i965 GLX_SGI_swap_control] glxgears get tearing output
http://bugs.freedesktop.org/show_bug.cgi?id=13058 Summary: [i915 i965 GLX_SGI_swap_control] glxgears get tearing output Product: Mesa Version: CVS Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/i915 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] System Environment: -- --Platform: i915, i965 --Architecture(32-bit,64-bit,compatiblity):all --2D driver: 50d3693a6862028e50bc5ba8c788e7ea573c3eb8 --Mesa: ee793281b221415f794af6aadaa9764023612e0b --DRM: 1b176e76134224e2af94d24ff7b33c7b536eaeea --Xserver: 566610680c4e1cab3e7fc7146adbeaba52fdd0ad --Kernel: 2.6.22-rc5 Bug detailed description: -- glxgears get obviously tearing it seems it's caused by 's issue GLX_SGI_video_sync is working well Reproduce steps: start X run glxgears Current result: have obvious tearing Expected result: run smoothly Basic root-causing log: -- caused by issues in OpenGL extension GLX_SGI_swap_control -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
