[Bug 17491] [GM965] OpenGL corruption when vblank-sync is enabled
http://bugs.freedesktop.org/show_bug.cgi?id=17491 Tomas Carnecky <[EMAIL PROTECTED]> changed: What|Removed |Added Summary|x11-drivers/xf86-video- |[GM965] OpenGL corruption |intel-2.4.2-r1 xorg-server- |when vblank-sync is enabled |1.5.0 mesa-7.1 DRI enabled | |by looks weird | --- Comment #8 from Tomas Carnecky <[EMAIL PROTECTED]> 2008-09-10 01:43:08 PST --- (In reply to comment #7) > btw. Should I report a new vblank-sync bug? Because it definitely does not > work > right :) On the other hand turning it of was your first suggestion so I guess > you know about it and it's one the To-Do... This bug is still valid. I changed the subject to better describe the bug. Btw, I only new about the vblank-sync because I also had low fps in glxgears and asked about it on IRC. I didn't know it would fix the bug. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17075] Radeon + DRI on r300: X goes 99.9% CPU
http://bugs.freedesktop.org/show_bug.cgi?id=17075 --- Comment #31 from Doron <[EMAIL PROTECTED]> 2008-09-10 03:00:15 PST --- Created an attachment (id=18801) --> (http://bugs.freedesktop.org/attachment.cgi?id=18801) gdb avoiding normal switch, using finish Hi Michel, OK, used the handle command I got to the break point. I used finish 7 times, ang X hanged ! Can you see something meaningful here ? Doron. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM object zeroing for VRAM
Dave Airlie wrote: > Hi Thomas, > > I've made some changes you might be interested in on the > modesetting-gem branch of the main repo. > > 1. removed all the TTM interfaces and ioctls from the kernel API. > 2. removed drm_bo_lock.c (we need to discuss what we want that for) > 3. built a radeon GEM interface on top of the TTM internals. > Dave, I plan to pick up this code and do the following: 1) The drm_bo.c, drm_bo_move.c, and drm_fence.c files will to into ttm/ttm_bo, ttm/ttm_bo_util, and ttm/ttm_fence. Functions and types will be prefixed ttm_ instead of drm and all (if not already done) user-space interaction will be stripped, as well as the dev->struct_mutex dependance, but in essence the interfaces you use in the Radeon code will be kept with minimal changes. 2) Radeon logically derives from drm_gem_object and ttm_bo to obtain the buffer objects, which is fine. I plan to add ttm_base object code so that it is possible to derive from ttm_base_object and ttm_bo to obtain buffer objects visible to user space and ttm_base_object and ttm_fence_object to obtain buffer- and fence objects visible to user space. However, this construct is entirely optional for a driver writer and only for those drivers that don't use GEM, or want to make fence objects visible to user-space for swapbuffer throttling, sub-allocation and command stream error reporting (mainly video acceleration). It's intended to suit the user-space interface posted for review earlier. The ttm_base_object code will also live separately in the ttm subdirectory. The per-file and per-device management code for the ttm_base_objects will be called from the device driver load / unload / fops hooks. 3) The ttm_bo vm code will still be closely tied to the ttm_bo object, but needs to be moved out from the drm core. The plan is to have separate ttm_mmap() ttm_read() and ttm_write() functionality for the driver to use in the .fops hooks. If any of these functions detect (based on the address space offset) that we're dealing with a legacy drm map, the corresponding drm core function will be called instead. 4) Swapout. (long term) I think this is most easily handled by demand-allocation of shmem objects into which we either copy or DMA the data. In the Radeon case, it should be easy to use the GEM shmem object. 5) Write-combined / unmapped page pool (long term). Did you ever get to implement this? I think it's still a very desirable thing, but it looks like the effect of buffer creation / destruction latency for at least fire-and-forget buffers (some pbos, temporary drawpixels / glbitmap, exaUploadToScrach) can be worked around by using VRAM or a small pre-bound AGP area. Does this sound acceptable? /Thomas - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17075] Radeon + DRI on r300: X goes 99.9% CPU
http://bugs.freedesktop.org/show_bug.cgi?id=17075 --- Comment #32 from Michel Dänzer <[EMAIL PROTECTED]> 2008-09-10 03:10:43 PST --- (In reply to comment #31) > Can you see something meaningful here ? I'm afraid not - Dispatch() is the main protocol request processing function, so it could still be pretty much anything, we've only ruled out that the problem is triggered from RADEONEnterVT directly. Does the problem also happen with a 'naked' X server (without any clients)? Other than that I'm running out of ideas, maybe someone else can chime in... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM object zeroing for VRAM
On Wed, Sep 10, 2008 at 8:03 PM, Thomas Hellström <[EMAIL PROTECTED]> wrote: > Dave Airlie wrote: >> >> Hi Thomas, >> >> I've made some changes you might be interested in on the >> modesetting-gem branch of the main repo. >> >> 1. removed all the TTM interfaces and ioctls from the kernel API. >> 2. removed drm_bo_lock.c (we need to discuss what we want that for) >> 3. built a radeon GEM interface on top of the TTM internals. >> > > Dave, > I plan to pick up this code and do the following: > > 1) The drm_bo.c, drm_bo_move.c, and drm_fence.c files will to into > ttm/ttm_bo, ttm/ttm_bo_util, and ttm/ttm_fence. Functions and types will be > prefixed ttm_ instead of > drm and all (if not already done) user-space interaction will be stripped, > as well as the dev->struct_mutex > dependance, but in essence the interfaces you use in the Radeon code will be > kept with minimal changes. Makes sense, I'm happy to change the internals interfaces at any time. > 2) Radeon logically derives from drm_gem_object and ttm_bo to obtain the > buffer objects, which is fine. > I plan to add ttm_base object code so that it is possible to derive from > ttm_base_object and ttm_bo to obtain buffer objects > visible to user space and ttm_base_object and ttm_fence_object to obtain > buffer- and fence objects visible to > user space. However, this construct is entirely optional for a driver writer > and only for those drivers that don't use GEM, > or want to make fence objects visible to user-space for swapbuffer > throttling, sub-allocation and command stream > error reporting (mainly video acceleration). > It's intended to suit the user-space interface posted for review earlier. > The ttm_base_object code will also live separately in the ttm subdirectory. > The per-file and per-device management code for the ttm_base_objects will be > called from the device driver load / unload / fops hooks. > > 3) The ttm_bo vm code will still be closely tied to the ttm_bo object, but > needs to be moved out from the drm core. > The plan is to have separate ttm_mmap() ttm_read() and ttm_write() > functionality for the driver to use in the .fops hooks. > If any of these functions detect (based on the address space offset) that > we're dealing with a legacy drm map, the corresponding drm core function > will be called instead. Yes that makes sense, it may interact with how GEMs GTT mappings end up working, not sure that interface is fully specified yet. > 4) Swapout. (long term) > I think this is most easily handled by demand-allocation of shmem objects > into which we either copy or > DMA the data. In the Radeon case, it should be easy to use the GEM shmem > object. Yes I'm currently just allocating the shmem object with no pages backing it. I plan on just kicking the pages into cached mappings and shoving them into the backing object address mapping. Then shmem will take care of swapping the data hopefully. > > 5) Write-combined / unmapped page pool (long term). > Did you ever get to implement this? I think it's still a very desirable > thing, but it looks like > the effect of buffer creation / destruction latency for at least > fire-and-forget buffers > (some pbos, temporary drawpixels / glbitmap, exaUploadToScrach) can be > worked around > by using VRAM or a small pre-bound AGP area. I've started this using a simple idr allocator, I got a bit sidetracked into doing filesystem based on shmem, before I realise it was probably pointless. http://cgit.freedesktop.org/~airlied/drm/tree/linux-core/drm_uncached.c?id=a4554d1f4c6d7adaad755789fe5106819a46f59a is the last bits of the uncached allocator I got to. I realised one problem with buffer reuse when VRAM is involved, we have some 2D operations, that always work on the buffer in local RAM, migrated to GTT or VRAM and blit from there. Reusing those buffers is a lot more overhead than throwing it away. It made me realise doing page reuse in the kernel may be a better plan. Dave. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17075] Radeon + DRI on r300: X goes 99.9% CPU
http://bugs.freedesktop.org/show_bug.cgi?id=17075 --- Comment #33 from Doron <[EMAIL PROTECTED]> 2008-09-10 04:02:14 PST --- (In reply to comment #32) > > Does the problem also happen with a 'naked' X server (without any clients)? No. I can switch out of and into X with no issues. > > Other than that I'm running out of ideas, maybe someone else can chime in... > I can only hope... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM object zeroing for VRAM
Dave Airlie wrote: > >> 3) The ttm_bo vm code will still be closely tied to the ttm_bo object, but >> needs to be moved out from the drm core. >> The plan is to have separate ttm_mmap() ttm_read() and ttm_write() >> functionality for the driver to use in the .fops hooks. >> If any of these functions detect (based on the address space offset) that >> we're dealing with a legacy drm map, the corresponding drm core function >> will be called instead. >> > > Yes that makes sense, it may interact with how GEMs GTT mappings end > up working, not sure that interface is > fully specified yet. > > Yes, let's see how that ends up. Anyway, the ttm vm code will need ttm_bo objects, but not vice versa, so the driver could actually plug in any vm handler for these objects. This also might come in handy for replacing fbdev fops, where drm may actually decide which buffer object is currently backing the user-space fbdev "display memory", and switch "on-the-fly". > > I've started this using a simple idr allocator, I got a bit > sidetracked into doing filesystem based on shmem, > before I realise it was probably pointless. > http://cgit.freedesktop.org/~airlied/drm/tree/linux-core/drm_uncached.c?id=a4554d1f4c6d7adaad755789fe5106819a46f59a > is the last bits of the uncached allocator I got to. > > I realised one problem with buffer reuse when VRAM is involved, we > have some 2D operations, that always work on the buffer in local RAM, > migrated to GTT or VRAM and blit from there. Reusing those buffers is > a lot more overhead than throwing it away. It made me realise doing > page > reuse in the kernel may be a better plan. > > OK. /Thomas > Dave. > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17075] Radeon + DRI on r300: X goes 99.9% CPU
http://bugs.freedesktop.org/show_bug.cgi?id=17075 --- Comment #34 from Michel Dänzer <[EMAIL PROTECTED]> 2008-09-10 07:22:12 PST --- (In reply to comment #33) > > Does the problem also happen with a 'naked' X server (without any clients)? > No. I can switch out of and into X with no issues. Interesting - so the problem could be related to a specific acceleration primitive which isn't hit by the root weave. With XAA, you can disable specific acceleration primitives using Option "XaaNo..." documented in the xorg.conf manpage. Basically, for each primitive listed after the log line (II) RADEON(0): Using XFree86 Acceleration Architecture (XAA) try the corresponding XaaNo... option and see if you can find a single such option which avoids the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
glxgears crash with latest mesa swrast module
I tried latest git from mesa master (latest commit is): commit 11d694b1bb0cb384d802d7e0e252cf5119febb98 Author: Brian Paul <[EMAIL PROTECTED]> Date: Fri Sep 5 08:06:59 2008 -0600 mesa: replace MALLOC w/ CALLOC to fix memory error in glPushClientAttrib() Glxgears crash as soon as it starts. This is gdb trace: [EMAIL PROTECTED]:~$ gdb glxgears GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/bin/glxgears [Thread debugging using libthread_db enabled] [New process 11011] [New Thread -1211914576 (LWP 11011)] libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1211914576 (LWP 11011)] 0x47206769 in ?? () (gdb) bt #0 0x47206769 in ?? () #1 0xb7f09deb in glXSwapBuffers (dpy=0x804c008, drawable=35651586) at glxcmds.c:859 #2 0x0804a69b in main (argc=1, argv=0xbfc857b4) at glxgears.c:338 (gdb) Bye Marco - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxgears crash with latest mesa swrast module
I don't see how that change could be related to a SwapBuffers crash. Maybe try recompile everything from scratch. -Brian Marco wrote: > I tried latest git from mesa master (latest commit is): > commit 11d694b1bb0cb384d802d7e0e252cf5119febb98 > Author: Brian Paul <[EMAIL PROTECTED]> > Date: Fri Sep 5 08:06:59 2008 -0600 > > mesa: replace MALLOC w/ CALLOC to fix memory error in glPushClientAttrib() > > > > Glxgears crash as soon as it starts. This is gdb trace: > [EMAIL PROTECTED]:~$ gdb glxgears > GNU gdb 6.6-debian > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > Using host libthread_db library "/lib/libthread_db.so.1". > (gdb) run > Starting program: /usr/bin/glxgears > [Thread debugging using libthread_db enabled] > [New process 11011] > [New Thread -1211914576 (LWP 11011)] > libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1211914576 (LWP 11011)] > 0x47206769 in ?? () > (gdb) bt > #0 0x47206769 in ?? () > #1 0xb7f09deb in glXSwapBuffers (dpy=0x804c008, drawable=35651586) > at glxcmds.c:859 > #2 0x0804a69b in main (argc=1, argv=0xbfc857b4) at glxgears.c:338 > (gdb) > > Bye > Marco > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > -- > ___ > Dri-devel mailing list > Dri-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dri-devel > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch][rfc] bitops: remove volatile
On Mon, 2008-09-01 at 14:51 +0200, Nick Piggin wrote: > Hi, > > This is a sweep of the tree to remove volatile qualifier from bitops, and I > have then tried to fix the resulting fallout. This will be split up as > individual patches before submission, but for now I include the entire thing > in one. > > The benefit of this is to relieve the compiler of the constraints demanded > by volatile, we get a smaller icache footprint, generally due to fewer loads > and stores. It saves over 20k of text on an allyesconfig on x86-64. (BTW. gcc > really does some idiotic things when inline is nooped: it out of lines things > like constant_test_bit...) > > The downside is that we can no longer use bitops on volatile data types, but > there are very few users of this, and it would be nice to convert them away > from volatile anyway. I have attempted to do that here: > drm: Made wrapped and context_state non volatile. Remember set_bit and > clear_bit can't be used to open and close a critical section (is > wrapped OK here?). Our ioctls rely on a lock being held around all the code, which is guaranteed by using .ioctl instead of .unlocked_ioctl as I understand. Removing the volatile from both of these should be safe. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 10088] Freeze after rotating 3D view in Blender
http://bugs.freedesktop.org/show_bug.cgi?id=10088 Sven Arvidsson <[EMAIL PROTECTED]> changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #8 from Sven Arvidsson <[EMAIL PROTECTED]> 2008-09-10 12:09:52 PST --- I no longer own this hardware and have no way of reproducing the bug so it's probably a good idea to close this report. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17196] [GEM] a lot of glean cases run failed
http://bugs.freedesktop.org/show_bug.cgi?id=17196 Eric Anholt <[EMAIL PROTECTED]> changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #8 from Eric Anholt <[EMAIL PROTECTED]> 2008-09-10 15:27:52 PST --- Please don't repurpose a bug in comment #7. File a new bug with the full information: logs, sha1s, readpix results, etc. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 17196] [GEM] a lot of glean cases run failed
http://bugs.freedesktop.org/show_bug.cgi?id=17196 Shuang He <[EMAIL PROTECTED]> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #9 from Shuang He <[EMAIL PROTECTED]> 2008-09-10 19:09:27 PST --- (In reply to comment #8) > Please don't repurpose a bug in comment #7. > > File a new bug with the full information: logs, sha1s, readpix results, etc. > ok, verified -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: glxgears crash with latest mesa swrast module
> I don't see how that change could be related to a SwapBuffers crash Sorry I was misunderstod: that is latest commit I have. Last mesa sources I had was from 20/08/2008, and glxgears was running fine, then I upgraded till the commit of Fri Sep 5 08:06:59 2008 -0600 and glxgears now crashes. Bye - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
