Re: drm: Branch 'master'
Eric Anholt wrote:
On Sun, 2008-04-06 at 02:21 -0700, Thomas Hellstrom wrote:
linux-core/drm_objects.h |2 ++
linux-core/drm_ttm.c | 12 +---
2 files changed, 11 insertions(+), 3 deletions(-)
New commits:
commit e89710bef7691e4e9d0bc7d427542bfae6ce4258
Author: Thomas Hellstrom thomas-at-tungstengraphics-dot-com
Date: Sun Apr 6 11:21:22 2008 +0200
Place highmem pages last in the ttm page array.
Could you add a comment explaining what this is about?
This is to prepare for Dave's linux 2.6.26 set_memory_uc_array()
interface which accepts an array of virtual addresses, and hence no
highmem pages.
We have two ways to handle this
a) Allocate a new temporary array that holds the virtual addresses. This
will in many cases fall back to using slow vmalloc() and not desirable.
b) Temporarily (during the set_memory_uc_array() call only) typecast the
page array entries and replace the (struct page) pointers with unsigned
long virtual addresses for the lomem pages. This avoids the vmalloc()
but OTOH is a bit ugly.
The above commit is to pave the way for b) if we want to go that way.
/Thomas
diff --git a/linux-core/drm_objects.h b/linux-core/drm_objects.h
index 9bd04ff..c32edac 100644
--- a/linux-core/drm_objects.h
+++ b/linux-core/drm_objects.h
@@ -311,6 +311,8 @@ struct drm_ttm_backend {
struct drm_ttm {
struct page *dummy_read_page;
struct page **pages;
+long first_himem_page;
+long last_lomem_page;
uint32_t page_flags;
unsigned long num_pages;
atomic_t vma_count;
diff --git a/linux-core/drm_ttm.c b/linux-core/drm_ttm.c
index da202a5..c306a2c 100644
--- a/linux-core/drm_ttm.c
+++ b/linux-core/drm_ttm.c
@@ -263,12 +263,16 @@ struct page *drm_ttm_get_page(struct drm_ttm *ttm, int
index)
struct page *p;
struct drm_buffer_manager *bm = ttm-dev-bm;
-p = ttm-pages[index];
-if (!p) {
+while(NULL == (p = ttm-pages[index])) {
p = drm_ttm_alloc_page();
if (!p)
return NULL;
-ttm-pages[index] = p;
+
+if (PageHighMem(p))
+ttm-pages[--ttm-first_himem_page] = p;
+else
+ttm-pages[++ttm-last_lomem_page] = p;
+
++bm-cur_pages;
}
return p;
@@ -376,6 +380,8 @@ struct drm_ttm *drm_ttm_create(struct drm_device *dev,
unsigned long size,
ttm-destroy = 0;
ttm-num_pages = (size + PAGE_SIZE - 1) PAGE_SHIFT;
+ttm-first_himem_page = ttm-num_pages;
+ttm-last_lomem_page = -1;
ttm-page_flags = page_flags;
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-patches mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-patches
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
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 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15382] Patches for dri2 linux-core
http://bugs.freedesktop.org/show_bug.cgi?id=15382 --- Comment #3 from Thomas Hellström [EMAIL PROTECTED] 2008-04-07 23:43:51 PST --- (In reply to comment #2) I met this problem as well. the 2nd patch works for me. this problem is brought in by following commit: commit c3888b97f60fbbc0b1382e5a16689eecaa2f79a5 Author: Thomas Hellstrom thomas-at-tungstengraphics-dot-com Date: Sun Apr 6 10:32:02 2008 +0200 Use clflush() when available for cache flushing. And should be fixed with Patrice Mandin's commit of the above patch, right? /Thomas -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15382] Patches for dri2 linux-core
http://bugs.freedesktop.org/show_bug.cgi?id=15382 --- Comment #4 from Shuang He [EMAIL PROTECTED] 2008-04-07 23:51:50 PST --- (In reply to comment #3) (In reply to comment #2) I met this problem as well. the 2nd patch works for me. this problem is brought in by following commit: commit c3888b97f60fbbc0b1382e5a16689eecaa2f79a5 Author: Thomas Hellstrom thomas-at-tungstengraphics-dot-com Date: Sun Apr 6 10:32:02 2008 +0200 Use clflush() when available for cache flushing. And should be fixed with Patrice Mandin's commit of the above patch, right? /Thomas yeah, it's fixed. -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15400] New: [915]mesa demo 'shadowtex 'run failed
http://bugs.freedesktop.org/show_bug.cgi?id=15400 Summary: [915]mesa demo 'shadowtex 'run failed 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:945 --Architecture(32-bit,64-bit,compatiblity):32bit 64bit --2D driver:master 24248097988775d62f6c416f2988e74d31c91cd0 --3D driver:master 28dfb0613b51c51d5f09010ea38d050a9ec817d7 --DRM:master e89710bef7691e4e9d0bc7d427542bfae6ce4258 --Xserver:master 539bf3c2836727e7560c64144071b086f8ea32fe --Kernel:2.6.24 Bug detailed description: -- startx, run shadowtex ,it will run fail, and print: Illegal instruction . and it can run normally on 965 Reproduce steps: 1.startx 2../shadowtex Current result: run failed Expected result: run normally -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15400] [915]mesa demo 'shadowtex 'run failed
http://bugs.freedesktop.org/show_bug.cgi?id=15400 --- Comment #1 from Colin.Joe [EMAIL PROTECTED] 2008-04-07 23:56:03 PST --- Created an attachment (id=15750) -- (http://bugs.freedesktop.org/attachment.cgi?id=15750) Xorg.0.log -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15203] r300 lockup
http://bugs.freedesktop.org/show_bug.cgi?id=15203 --- Comment #35 from Michel Dänzer [EMAIL PROTECTED] 2008-04-08 01:03:34 PST --- (In reply to comment #34) Or improve the error handling. That's tricky to get right though, and can cause different problems. E.g. if something gets an error return code and then tries to reset the CP while it's actually still chugging along happily, that can itself cause a lockup or other problems. But there's no reason to return an error in the first place. -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15386] r300: Vertex program has problems with more than 7 inputs
http://bugs.freedesktop.org/show_bug.cgi?id=15386
--- Comment #2 from Markus Amsler [EMAIL PROTECTED] 2008-04-08 02:58:15 PST
---
You're right.
Setting PVS_NUM_SLOTS to 9 (currently 10) fixes the problem.
Currently we're setting VAP_CNTL globally, looks like we should do it per
vertex program.
6.4.2 nicely describes how to set up VAP_CNTL, but I'm having some trouble
understanding it. I'm not sure what POR means or 'vertex data has been packed'.
I'm also not sure about {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE.
--
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 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15382] Patches for dri2 linux-core
http://bugs.freedesktop.org/show_bug.cgi?id=15382 Roland Test-tools Bär [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15382] Patches for dri2 linux-core
http://bugs.freedesktop.org/show_bug.cgi?id=15382 Roland Test-tools Bär [EMAIL PROTECTED] changed: What|Removed |Added Attachment #15732|0 |1 is obsolete|| --- Comment #6 from Roland Test-tools Bär [EMAIL PROTECTED] 2008-04-08 03:53:57 PST --- (From update of attachment 15732) Have to redo this... -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
BO fence second round :)
Hi Thomas, I got a question about BO object it seems that from kernel point of view we don't store the size the user requested for allocation, also there is no easy way to quickly get BO handle. I would need both for two reasons. I need to know user size allocation request so i can check if user is trying to access outside the area it has requested for (even though the request might still end in the allocated area as its rounded to page). I would need BO handle mostly to help debuguing user/kernel space interaction and quickly see about which object each other are thinking of. Also does fence class have ever been tested ? I would like to have a class for 3d and one for 2d on radeon (as flush and pipeline are different). Side remark should there be some check on flag, mask, hint the userspace ask for as for instance userspace might ask for buffer to not be fenced while it's needed. And am i right in assuming that validate will fail if userspace still have a mapping of the buffer active ? I don't think i fully understand bo-fence_type, it is set in drm_fence_buffer_objects. My understanding is that for instance if you get submited a command stream like this: -BO cmd, EXE fence -BO dst, WRITE fence -BO src, READ fence The fence emited will be EXE|WRITE|READ, fency_type will be set to EXE|WRITE|READ but yet once the EXE fence is signaled this EXE BO can be free (or reused) right ? ie fence not fully signaled. If that's right then i didn't fully understand fence yet :) If so, i think i already asked with one, does signaling multiple time same sequence number with different flag isn't troublesome ? Because then i will emit multiple time the sequence to free EXE buffer as soon as possible. Also when you call drm_bo_handle_validate you put the bo on the unfenced list, don't you ? Isn't there another way to get buffer object without putting it on validate list ? I need that because fence, class, mask will depend from the command stream and i don't want to scan 2 times the command stream one for getting proper fence class mask and bo flag mask second to update bo offset in command stream. Thanks a lot Thomas for all your help, you saved me hours of code reading :) And in the end i will have an optimal|beautifull BO fence code :) Cheers, Jerome Glisse [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15386] r300: Vertex program has problems with more than 7 inputs
http://bugs.freedesktop.org/show_bug.cgi?id=15386
--- Comment #3 from Alex Deucher [EMAIL PROTECTED] 2008-04-08 07:22:25 PST
---
(In reply to comment #2)
You're right.
Setting PVS_NUM_SLOTS to 9 (currently 10) fixes the problem.
Currently we're setting VAP_CNTL globally, looks like we should do it per
vertex program.
6.4.2 nicely describes how to set up VAP_CNTL, but I'm having some trouble
understanding it. I'm not sure what POR means or 'vertex data has been
packed'.
I'm also not sure about {INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE.
6.4.7, 6.5.1 and 6.5.2 have some additional information.
{INPUT|OUTPUT|TEMP}_VTX_MEM_SIZE refers to the size of your vertex stream(s)
(DWORDs IIRC). VAP_PROG_STREAM_CNTL_0-7 and VAP_PROG_STREAM_CNTL_EXT_0-7
describe how the elements are treated. Unfortunately, I'm not sure what POR
stands for.
--
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 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15404] New: DRI stops to work after libpciaccess enable xorg-server upgrade
http://bugs.freedesktop.org/show_bug.cgi?id=15404 Summary: DRI stops to work after libpciaccess enable xorg-server upgrade Product: DRI Version: XOrg CVS Platform: PowerPC OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: General AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] As I wanted to test is libpciaccess fixed bug #7248 I upgraded my xorg-server to recent git snapshot. The bug was fixed, but it seems that DRI stops to work here at all (mesa was upgraded to git too of coz). I tired with both XAA and EXA using drm modules from 2.6.24 and from git with same results. Starting any GL app cause server crash (glxinfo command produce this crash too) Looking in the logs I see: (II) RADEON(0): [drm] failure adding irq handler, there is a device already using that irq [drm] falling back to irq-free operation I remember there was a similar problem before (I mean the symptoms of coz) Also I wonder why card0 is opened so many times ? drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: open result is -1, (No such device or address) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci:0001:01:08.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:08.0 It seems it opens card0 twice and the second one is successfull, but later: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: Searching for BusID pci:0001:01:08.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:08.0 And later: drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: Searching for BusID pci:0001:01:08.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 8, (OK) drmOpenByBusid: drmOpenMinor returns 8 drmOpenByBusid: drmGetBusid reports pci::01:08.0 ... (EE) AIGLX error: drmOpenOnce failed (Operation not permitted) -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15404] DRI stops to work after libpciaccess enable xorg-server upgrade
http://bugs.freedesktop.org/show_bug.cgi?id=15404 --- Comment #1 from Marcin Kurek [EMAIL PROTECTED] 2008-04-08 08:43:13 PST --- Created an attachment (id=15760) -- (http://bugs.freedesktop.org/attachment.cgi?id=15760) Full Xorg.0.log -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15404] DRI stops to work after libpciaccess enable xorg-server upgrade
http://bugs.freedesktop.org/show_bug.cgi?id=15404 --- Comment #2 from Marcin Kurek [EMAIL PROTECTED] 2008-04-08 08:44:23 PST --- Created an attachment (id=15761) -- (http://bugs.freedesktop.org/attachment.cgi?id=15761) lspci -nn for this system Also I forgot to mention that my machine is Pegasos 2 1GHz G4 with 1GB of ram running kernel 2.6.24. -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15404] DRI stops to work after libpciaccess enable xorg-server upgrade
http://bugs.freedesktop.org/show_bug.cgi?id=15404 --- Comment #3 from Marcin Kurek [EMAIL PROTECTED] 2008-04-08 08:44:49 PST --- Created an attachment (id=15762) -- (http://bugs.freedesktop.org/attachment.cgi?id=15762) 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. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15404] DRI stops to work after libpciaccess enable xorg-server upgrade
http://bugs.freedesktop.org/show_bug.cgi?id=15404 --- Comment #4 from Marcin Kurek [EMAIL PROTECTED] 2008-04-08 08:45:27 PST --- Created an attachment (id=15763) -- (http://bugs.freedesktop.org/attachment.cgi?id=15763) /proc/interrupts Not sure is this important in this case. -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15404] DRI stops to work after libpciaccess enable xorg-server upgrade
http://bugs.freedesktop.org/show_bug.cgi?id=15404 --- Comment #5 from Marcin Kurek [EMAIL PROTECTED] 2008-04-08 08:53:13 PST --- Created an attachment (id=15764) -- (http://bugs.freedesktop.org/attachment.cgi?id=15764) log with backtrace from glxinfo The console output was: libGL error: open DRM failed (Operation not permitted) libGL error: reverting to (slow) indirect rendering X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 154 (GLX) Minor opcode of failed request: 5 (X_GLXMakeCurrent) Serial number of failed request: 26 Current serial number in output stream: 26 name of display: :0.0 And backtrace for crash: Backtrace: 0: /usr/bin/X(xf86SigHandler+0x94) [0x100916d0] 1: [0x100364] 2: [(nil)] 3: /usr/lib/xorg/modules/extensions//libglx.so(__glXContextDestroy+0x30) [0xe74f 4: /usr/lib/xorg/modules/extensions//libglx.so [0xe753710] 5: /usr/lib/xorg/modules/extensions//libglx.so(__glXFreeContext+0xb8) [0xe752700 6: /usr/lib/xorg/modules/extensions//libglx.so [0xe752764] 7: /usr/bin/X(FreeClientResources+0x104) [0x1002a4d0] 8: /usr/bin/X(CloseDownClient+0x8c) [0x1003dd5c] 9: /usr/bin/X(Dispatch+0x308) [0x1004461c] 10: /usr/bin/X(main+0x494) [0x100276d4] 11: /lib/libc.so.6 [0xf32e740] 12: /lib/libc.so.6 [0xf32e8dc] Fatal server error: Caught signal 11. Server aborting -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15404] DRI stops to work after libpciaccess enable xorg-server upgrade
http://bugs.freedesktop.org/show_bug.cgi?id=15404 Michel Dänzer [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #6 from Michel Dänzer [EMAIL PROTECTED] 2008-04-08 10:17:04 PST --- *** This bug has been marked as a duplicate of bug 7770 *** -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BO fence second round :)
Jerome Glisse wrote: Hi Thomas, I got a question about BO object it seems that from kernel point of view we don't store the size the user requested for allocation, also there is no easy way to quickly get BO handle. I would need both for two reasons. I need to know user size allocation request so i can check if user is trying to access outside the area it has requested for (even though the request might still end in the allocated area as its rounded to page). I would need BO handle mostly to help debuguing user/kernel space interaction and quickly see about which object each other are thinking of. Hi, Jerome. Requested allocation size is unfortunately not availabe, ATM. Handle is easier. It's bo-base.hash.key. Also does fence class have ever been tested ? I would like to have a class for 3d and one for 2d on radeon (as flush and pipeline are different). Yes, It has been tested thoroughly on Poulsbo, which has separate 2D and 3D engines. I think we've pushed all needed changes upstream. However, If you're thinking of doing swapbuffers with 2D, fence classes will force a wait for back-buffer idle when you validate the buffers for the swapbuffer operation. Here you might want to implement something clever hardware specific in command_stream_barrier() instead. Side remark should there be some check on flag, mask, hint the userspace ask for as for instance userspace might ask for buffer to not be fenced while it's needed. And am i right in assuming that validate will fail if userspace still have a mapping of the buffer active ? There are probably a lot of cases where you can supply illegal flags. However, the HINT_DONT_FENCE has been obsoleter for a while and should have no effect in practice. Validation of a mapped buffer will wait until the buffer becomes unmapped. I don't think i fully understand bo-fence_type, it is set in drm_fence_buffer_objects. My understanding is that for instance if you get submited a command stream like this: -BO cmd, EXE fence -BO dst, WRITE fence -BO src, READ fence The fence emited will be EXE|WRITE|READ, fency_type will be set to EXE|WRITE|READ but yet once the EXE fence is signaled this EXE BO can be free (or reused) right ? ie fence not fully signaled. Yes, that's correct. So the bo-fence_type of the CMD buffer will be EXE only. If that's right then i didn't fully understand fence yet :) If so, i think i already asked with one, does signaling multiple time same sequence number with different flag isn't troublesome ? Because then i will emit multiple time the sequence to free EXE buffer as soon as possible. Yes, it's OK to give the fence handler the same sequence multiple times. with the same fence type or with different fence types. Also when you call drm_bo_handle_validate you put the bo on the unfenced list, don't you ? Isn't there another way to get buffer object without putting it on validate list ? I need that because fence, class, mask will depend from the command stream and i don't want to scan 2 times the command stream one for getting proper fence class mask and bo flag mask second to update bo offset in command stream. With the command stream submit ioctl, you can only submit for a single fence class at a time. With that IOCTL, you usually also submit a list of buffers, carrying the validation flags and masks, and finally a list of relocations that may be used to patch the command stream, if needed. I think the intel_execbuf.c code does this in a good way now, so it's a good reference. I'm not really sure what you mean you need to scan the command stream? Thanks a lot Thomas for all your help, you saved me hours of code reading :) And in the end i will have an optimal|beautifull BO fence code :) Cheers, Jerome Glisse [EMAIL PROTECTED] Thanks, Thomas - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7770] PCI domain mismatch between X server and kernel, leaving clients unable to use direct rendering
http://bugs.freedesktop.org/show_bug.cgi?id=7770 Michel Dänzer [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] Status|REOPENED|NEW Component|DDX/xorg|DRM modules Product|xorg|DRI Version|7.0 |unspecified --- Comment #32 from Michel Dänzer [EMAIL PROTECTED] 2008-04-08 10:21:34 PST --- The xserver side should be fixed with pciaccess, now it's probably up to the DRM to use a real implementation of drm_get_pci_domain() instead of hardcoding it to 0. -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: BO fence second round :)
On Tue, 08 Apr 2008 19:29:50 +0200 Thomas Hellström [EMAIL PROTECTED] wrote: Jerome Glisse wrote: Hi Thomas, I got a question about BO object it seems that from kernel point of view we don't store the size the user requested for allocation, also there is no easy way to quickly get BO handle. I would need both for two reasons. I need to know user size allocation request so i can check if user is trying to access outside the area it has requested for (even though the request might still end in the allocated area as its rounded to page). I would need BO handle mostly to help debuguing user/kernel space interaction and quickly see about which object each other are thinking of. Hi, Jerome. Requested allocation size is unfortunately not availabe, ATM. Handle is easier. It's bo-base.hash.key. Do you mind if i add things to store this size and to get it ? Also does fence class have ever been tested ? I would like to have a class for 3d and one for 2d on radeon (as flush and pipeline are different). Yes, It has been tested thoroughly on Poulsbo, which has separate 2D and 3D engines. I think we've pushed all needed changes upstream. However, If you're thinking of doing swapbuffers with 2D, fence classes will force a wait for back-buffer idle when you validate the buffers for the swapbuffer operation. Here you might want to implement something clever hardware specific in command_stream_barrier() instead. Yes, i have seen this after writing my mail, does the barrier happen even if no buffer in the 2d class are in use in the 3d class (and the other way too) ? If that's right then i didn't fully understand fence yet :) If so, i think i already asked with one, does signaling multiple time same sequence number with different flag isn't troublesome ? Because then i will emit multiple time the sequence to free EXE buffer as soon as possible. Yes, it's OK to give the fence handler the same sequence multiple times. with the same fence type or with different fence types. Ok so i will add sequence with just exe before flush, i need to think a bit to flush so i don't add one at each command but when user ask for a fence flush for instance. Also when you call drm_bo_handle_validate you put the bo on the unfenced list, don't you ? Isn't there another way to get buffer object without putting it on validate list ? I need that because fence, class, mask will depend from the command stream and i don't want to scan 2 times the command stream one for getting proper fence class mask and bo flag mask second to update bo offset in command stream. With the command stream submit ioctl, you can only submit for a single fence class at a time. With that IOCTL, you usually also submit a list of buffers, carrying the validation flags and masks, and finally a list of relocations that may be used to patch the command stream, if needed. I think the intel_execbuf.c code does this in a good way now, so it's a good reference. I'm not really sure what you mean you need to scan the command stream? On radeon we scan packet to see if the packet is authorized or not, for instance we want to forbid user to submit a blit with no bo relocation so to arbitrary memory location. This is the type of command i scan in the stream which in the end determine if i want to flush 2d or 3d or both (and each buffer might not be on the same kind). Cheers, Jerome Glisse [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM modesetting sysfs
I just pushed a few changes updating the DRM modesetting sysfs support, both for debugging and eventual HAL friendliness. So far, the support is limited to describing outputs and generating hotplug events. A typical card0 directory now looks like this: . |-- card0-DAC-1 | |-- device - ../../../../../../devices/pci:00/:00:02.0/drm/card0 | |-- dpms | |-- edid | |-- modes | |-- power | | `-- wakeup | |-- status | |-- subsystem - ../../../../../../class/drm | `-- uevent |-- card0-LVDS-1 | |-- device - ../../../../../../devices/pci:00/:00:02.0/drm/card0 | |-- dpms | |-- edid | |-- modes | |-- power | | `-- wakeup | |-- status | |-- subsystem - ../../../../../../class/drm | `-- uevent |-- dev |-- device - ../../../../../devices/pci:00/:00:02.0 |-- dri_library_name |-- power | `-- wakeup |-- subsystem - ../../../../../class/drm `-- uevent Each output is listed, prefixed with its associated card number to disambiguate it at the top level /sys/class/drm directory (where it also has some symlinks). Currently, only DPMS, EDID, mode list and connection status properties are exported, but we could list more as needed. You can use 'udevmonitor --env' to look for hotplug events; you should see several at load time, and presumably some at connection hotplug time (though I haven't gotten that working yet, any ideas Jakob?). Any thoughts on the interface? Anything in particular people would like to see? Thanks, Jesse - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM modesetting sysfs
[Sorry for the DUP, forgot to cc lkml] I just pushed a few changes updating the DRM modesetting sysfs support, both for debugging and eventual HAL friendliness. So far, the support is limited to describing outputs and generating hotplug events. A typical card0 directory now looks like this: . |-- card0-DAC-1 | |-- device - ../../../../../../devices/pci:00/:00:02.0/drm/card0 | |-- dpms | |-- edid | |-- modes | |-- power | | `-- wakeup | |-- status | |-- subsystem - ../../../../../../class/drm | `-- uevent |-- card0-LVDS-1 | |-- device - ../../../../../../devices/pci:00/:00:02.0/drm/card0 | |-- dpms | |-- edid | |-- modes | |-- power | | `-- wakeup | |-- status | |-- subsystem - ../../../../../../class/drm | `-- uevent |-- dev |-- device - ../../../../../devices/pci:00/:00:02.0 |-- dri_library_name |-- power | `-- wakeup |-- subsystem - ../../../../../class/drm `-- uevent Each output is listed, prefixed with its associated card number to disambiguate it at the top level /sys/class/drm directory (where it also has some symlinks). Currently, only DPMS, EDID, mode list and connection status properties are exported, but we could list more as needed. You can use 'udevmonitor --env' to look for hotplug events; you should see several at load time, and presumably some at connection hotplug time (though I haven't gotten that working yet, any ideas Jakob?). Any thoughts on the interface? Anything in particular people would like to see? Thanks, Jesse - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7770] PCI domain mismatch between X server and kernel, leaving clients unable to use direct rendering
http://bugs.freedesktop.org/show_bug.cgi?id=7770 --- Comment #33 from Marcin Kurek [EMAIL PROTECTED] 2008-04-08 14:58:35 PST --- Created an attachment (id=15767) -- (http://bugs.freedesktop.org/attachment.cgi?id=15767) log from drm compiled without hardcoded domain It seems you have right as there is no crash when I replace the hardcoded domain from 0 to pci_domain_nr() in drmP.h. But GL still doesn't work as for some reason it doesn't add required visuals. [EMAIL PROTECTED] ~]$ glxinfo name of display: :0.0 Error: couldn't find RGB GLX visual visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x22 24 dc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None 0x6f 32 tc 1 0 0 c . . 0 0 0 0 0 0 0 0 0 0 0 0 0 None -- 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 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15386] r300: Vertex program has problems with more than 7 inputs
http://bugs.freedesktop.org/show_bug.cgi?id=15386 --- Comment #6 from Markus Amsler [EMAIL PROTECTED] 2008-04-08 16:31:46 PST --- (In reply to comment #5) (In reply to comment #4) The docs (both r500v1.3 and r300) also say to set VF_MAX_VTF_NUM in VAP_CNTL to 12=0xc. But this value crashes my card. fglrx sets it to 0xb, without crash. So for this value the doc is wrong. looks like that field is (vertices - 1), so 11 (0xb) would mean 12 vertices would be used. Still it's not real clear. My fault, doc is correct. 12 works fine, I mixed up some bits. -- 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 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14873] [i965] glean (around pbo case) crash X
http://bugs.freedesktop.org/show_bug.cgi?id=14873 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #9 from Shuang He [EMAIL PROTECTED] 2008-04-08 20:13:24 PST --- This issue seems gone. -- 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 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14873] [i965] glean (around pbo case) crash X
http://bugs.freedesktop.org/show_bug.cgi?id=14873 Shuang He [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #10 from Shuang He [EMAIL PROTECTED] 2008-04-08 20:13:54 PST --- 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 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
