Re: DRI2 and lock-less operation
I'm trying to figure out how context switches acutally work... the DRI lock is overloaded as context switcher, and there is code in the kernel to call out to a chipset specific context switch routine when the DRI lock is taken... but only ffb uses it... So I'm guessing the way context switches work today is that the DRI driver grabs the lock and after potentially updating the cliprects through X protocol, it emits all the state it depends on to the cards. Is the state emission done by just writing out a bunch of registers? Is this how the X server works too, except XAA/EXA acceleration doesn't depend on a lot of state and thus the DDX driver can emit everything for each operation? So yes userspaces notices context has changed and just re-emits everything into the batchbuffer it is going to send, for XAA/EXA stuff in Intel at least there is an invarient state emission functions that notices what the context was and what the last server 3D users was (EXA or Xv texturing) and just dumps the state into the batchbuffer.. (or currently into the ring) How would this work if we didn't have a lock? You can't emit the state and then start rendering without a lock to keep the state in place... If the kernel doesn't restore any state, whats the point of the drm_context_t we pass to the kernel in drmLock? Should the kernel know how to restore state (this ties in to the email from jglisse on state tracking in drm and all the gallium jazz, I guess)? How do we identify state to the kernel, and how do we pass it in in the super-ioctl? Can we add a list of registers to be written and the values? I talked to Dave about it and we agreed that adding a drm_context_t to the super-ioctl would work, but now I'm thinking if the kernel doesn't track any state it wont really work. Maybe cross-client state sharing isn't useful for performance as Keith and Roland argues, but if the kernel doesn't restore state when it sees a super-ioctl coming from a different context, who does? My guess for one way is to store a buffer object with the current state emission in it, and submit it with the superioctl maybe, and if we have lost context emit it before the batchbuffer.. Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
Dave Airlie wrote: I'm trying to figure out how context switches acutally work... the DRI lock is overloaded as context switcher, and there is code in the kernel to call out to a chipset specific context switch routine when the DRI lock is taken... but only ffb uses it... So I'm guessing the way context switches work today is that the DRI driver grabs the lock and after potentially updating the cliprects through X protocol, it emits all the state it depends on to the cards. Is the state emission done by just writing out a bunch of registers? Is this how the X server works too, except XAA/EXA acceleration doesn't depend on a lot of state and thus the DDX driver can emit everything for each operation? So yes userspaces notices context has changed and just re-emits everything into the batchbuffer it is going to send, for XAA/EXA stuff in Intel at least there is an invarient state emission functions that notices what the context was and what the last server 3D users was (EXA or Xv texturing) and just dumps the state into the batchbuffer.. (or currently into the ring) How would this work if we didn't have a lock? You can't emit the state and then start rendering without a lock to keep the state in place... If the kernel doesn't restore any state, whats the point of the drm_context_t we pass to the kernel in drmLock? Should the kernel know how to restore state (this ties in to the email from jglisse on state tracking in drm and all the gallium jazz, I guess)? How do we identify state to the kernel, and how do we pass it in in the super-ioctl? Can we add a list of registers to be written and the values? I talked to Dave about it and we agreed that adding a drm_context_t to the super-ioctl would work, but now I'm thinking if the kernel doesn't track any state it wont really work. Maybe cross-client state sharing isn't useful for performance as Keith and Roland argues, but if the kernel doesn't restore state when it sees a super-ioctl coming from a different context, who does? My guess for one way is to store a buffer object with the current state emission in it, and submit it with the superioctl maybe, and if we have lost context emit it before the batchbuffer.. There are probably various ways to do this, which is another argument for keeping super-ioctls device-specific. For i915-type hardware, Dave's approach above is probably the most attracting one. For Poulsbo, all state is always implicitly included, usually as a reference to a buffer object, so we don't really bother about contexts here. For hardware like the Unichrome, the state is stored in a limited set of registers. Here the drm can keep a copy of those registers for each context and do a smart update on a context switch. However, there are cases where it is very difficult to use cliprects from the drm, though I wouldn't say impossible. /Thomas Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
Dave Airlie wrote: I'm trying to figure out how context switches acutally work... the DRI lock is overloaded as context switcher, and there is code in the kernel to call out to a chipset specific context switch routine when the DRI lock is taken... but only ffb uses it... So I'm guessing the way context switches work today is that the DRI driver grabs the lock and after potentially updating the cliprects through X protocol, it emits all the state it depends on to the cards. Is the state emission done by just writing out a bunch of registers? Is this how the X server works too, except XAA/EXA acceleration doesn't depend on a lot of state and thus the DDX driver can emit everything for each operation? So yes userspaces notices context has changed and just re-emits everything into the batchbuffer it is going to send, for XAA/EXA stuff in Intel at least there is an invarient state emission functions that notices what the context was and what the last server 3D users was (EXA or Xv texturing) and just dumps the state into the batchbuffer.. (or currently into the ring) How would this work if we didn't have a lock? You can't emit the state and then start rendering without a lock to keep the state in place... If the kernel doesn't restore any state, whats the point of the drm_context_t we pass to the kernel in drmLock? Should the kernel know how to restore state (this ties in to the email from jglisse on state tracking in drm and all the gallium jazz, I guess)? How do we identify state to the kernel, and how do we pass it in in the super-ioctl? Can we add a list of registers to be written and the values? I talked to Dave about it and we agreed that adding a drm_context_t to the super-ioctl would work, but now I'm thinking if the kernel doesn't track any state it wont really work. Maybe cross-client state sharing isn't useful for performance as Keith and Roland argues, but if the kernel doesn't restore state when it sees a super-ioctl coming from a different context, who does? My guess for one way is to store a buffer object with the current state emission in it, and submit it with the superioctl maybe, and if we have lost context emit it before the batchbuffer.. The way drivers actually work at the moment is to emit a full state as a preamble to each batchbuffer. Depending on the hardware, this can be pretty low overhead, and it seems that the trend in hardware is to make this operation cheaper and cheaper. This works fine without the lock. There is another complimentary trend to support one way or another multiple hardware contexts (obviously nvidia have done this for years), meaning that effectively the hardware (effectively) does the context switches. This is probably how most cards will end up working in the future, if not already. Neither of these need a lock for detecting context switches. Keith - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI2 and lock-less operation
Keith Whitwell wrote: Dave Airlie wrote: I'm trying to figure out how context switches acutally work... the DRI lock is overloaded as context switcher, and there is code in the kernel to call out to a chipset specific context switch routine when the DRI lock is taken... but only ffb uses it... So I'm guessing the way context switches work today is that the DRI driver grabs the lock and after potentially updating the cliprects through X protocol, it emits all the state it depends on to the cards. Is the state emission done by just writing out a bunch of registers? Is this how the X server works too, except XAA/EXA acceleration doesn't depend on a lot of state and thus the DDX driver can emit everything for each operation? So yes userspaces notices context has changed and just re-emits everything into the batchbuffer it is going to send, for XAA/EXA stuff in Intel at least there is an invarient state emission functions that notices what the context was and what the last server 3D users was (EXA or Xv texturing) and just dumps the state into the batchbuffer.. (or currently into the ring) How would this work if we didn't have a lock? You can't emit the state and then start rendering without a lock to keep the state in place... If the kernel doesn't restore any state, whats the point of the drm_context_t we pass to the kernel in drmLock? Should the kernel know how to restore state (this ties in to the email from jglisse on state tracking in drm and all the gallium jazz, I guess)? How do we identify state to the kernel, and how do we pass it in in the super-ioctl? Can we add a list of registers to be written and the values? I talked to Dave about it and we agreed that adding a drm_context_t to the super-ioctl would work, but now I'm thinking if the kernel doesn't track any state it wont really work. Maybe cross-client state sharing isn't useful for performance as Keith and Roland argues, but if the kernel doesn't restore state when it sees a super-ioctl coming from a different context, who does? My guess for one way is to store a buffer object with the current state emission in it, and submit it with the superioctl maybe, and if we have lost context emit it before the batchbuffer.. The way drivers actually work at the moment is to emit a full state as a preamble to each batchbuffer. Depending on the hardware, this can be pretty low overhead, and it seems that the trend in hardware is to make this operation cheaper and cheaper. This works fine without the lock. There is another complimentary trend to support one way or another multiple hardware contexts (obviously nvidia have done this for years), meaning that effectively the hardware (effectively) does the context switches. This is probably how most cards will end up working in the future, if not already. Neither of these need a lock for detecting context switches. Keith I will go this way too for r300/r400/r500 there is not so much registers change with different contexts and registers which need special treatment will be handled by the drm (this boils down to where 3d get rendered and where is the zbuffer and pitch/tile informations on this 2 buffers; this informations will be embedded in drm_drawable as the cliprect if i am right :)). It will be up to client to reemit enough state for the card to be in good shape for its rendering and i don't think it's worthwhile to provide facilities to keep hw in a given state. So i don't need a lock and indeed my actual code doesn't use any except for ring buffer emission (only shared area among different client i can see in my case). Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13358] New: Radeon X800XL 256 (R430) can only run the first started opengl program after X is loaded
http://bugs.freedesktop.org/show_bug.cgi?id=13358 Summary: Radeon X800XL 256 (R430) can only run the first started opengl program after X is loaded Product: Mesa Version: CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] My R430 based graphics card can only run the first opengl program after X is loaded. For example, I can load glxgears, and then after I close glxgears and try to load it again I get an error message saying that it can't get a double buffer RBG visual.If I restart X I can once again load the first opengl program, but none after that until I restart X. I currently have Xserver 1.4 installed, or Xorg 7.3 installed with the git clone of mesa, libdrm, and drm modules.This bug started about a month ago. I was thinking of testing the three additional GLX extensions since Mesa 7.0 was released. One more thing is that if I install mesa 7.0 I can get opengl working again without restarting the X server. -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI2 cliprect
Hi Kristian, Got a question on cliprect this might be dumb but what happen if hw is limited on numbers of cliprect it can handle ? Does the X server also provide some kind of informations like buffer draw order (in which case cliprect are only usefull to save cpy memory) ? I haven't looked yet in this cliprect stuff so this might be a trivial question, sorry if it is :) Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13362] Error with i915tex in file dri_bufmgr.c
http://bugs.freedesktop.org/show_bug.cgi?id=13362 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Error with i915tex in file |Error with i915tex in file |dri_bufmgr.c Mesa 7.0.2 |dri_bufmgr.c --- Comment #1 from [EMAIL PROTECTED] 2007-11-22 17:56 PST --- this maybe is because libdrm is not 2.3.0 , anyway you could delete i915tex dir safely -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 13362] New: Error with i915tex in file dri_bufmgr.c
http://bugs.freedesktop.org/show_bug.cgi?id=13362
Summary: Error with i915tex in file dri_bufmgr.c
Product: Mesa
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/i915
AssignedTo: dri-devel@lists.sourceforge.net
ReportedBy: [EMAIL PROTECTED]
I try to compile the latest Mesa on my Fujitsu Simens notebook with a GMA 950
and Gentoo and get following compile error:
make[6]: Leaving directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2/src/mesa/drivers/dri/i915tex'
make[6]: Entering directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2/src/mesa/drivers/dri/i915tex'
i686-pc-linux-gnu-gcc -c -I. -I../../../../../src/mesa/drivers/dri/common
-Iserver -I../../../../../include -I../../../../../include/GL/internal
-I../../../../../src/mesa -I../../../../../src/mesa/main
-I../../../../../src/mesa/glapi -I../../../../../src/mesa/math
-I../../../../../src/mesa/transform -I../../../../../src/mesa/shader
-I../../../../../src/mesa/swrast -I../../../../../src/mesa/swrast_setup
-I../../../../../src/egl/main -I../../../../../src/egl/drivers/dri `pkg-config
--cflags libdrm` -O2 -march=i686 -pipe -fno-strict-aliasing -fPIC -m32
-D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE
-D_GNU_SOURCE -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
-DHAVE_POSIX_MEMALIGN -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-I../intel ../common/dri_bufmgr.c -o ../common/dri_bufmgr.o
In file included from ../common/dri_bufmgr.c:37:
../common/dri_bufmgr.h:83: Fehler: expected declaration specifiers or »...«
before »drmBOList«
../common/dri_bufmgr.h:84: Fehler: expected »)« before »*« token
../common/dri_bufmgr.h:85: Fehler: expected »)« before »*« token
../common/dri_bufmgr.h:87: Fehler: expected declaration specifiers or »...«
before »drmBOList«
../common/dri_bufmgr.c: In Funktion »driFenceBuffers«:
../common/dri_bufmgr.c:102: Warnung: Übergabe des Arguments 3 von
»drmFenceBuffers« erzeugt Ganzzahl von Zeiger ohne Typkonvertierung
../common/dri_bufmgr.c:102: Fehler: Zu wenige Argumente für Funktion
»drmFenceBuffers«
../common/dri_bufmgr.c: Auf höchster Ebene:
../common/dri_bufmgr.c:437: Fehler: expected declaration specifiers or »...«
before »drmBOList«
../common/dri_bufmgr.c: In Funktion »driBOCreateList«:
../common/dri_bufmgr.c:440: Fehler: »list« nicht deklariert (erste Benutzung
in dieser Funktion)
../common/dri_bufmgr.c:440: Fehler: (Jeder nicht deklarierte Bezeichner wird
nur einmal aufgeführt
../common/dri_bufmgr.c:440: Fehler: für jede Funktion in der er auftritt.)
../common/dri_bufmgr.c: Auf höchster Ebene:
../common/dri_bufmgr.c:445: Fehler: expected »)« before »*« token
../common/dri_bufmgr.c:453: Fehler: expected »)« before »*« token
../common/dri_bufmgr.c:487: Fehler: expected declaration specifiers or »...«
before »drmBOList«
../common/dri_bufmgr.c: In Funktion »driBOValidateList«:
../common/dri_bufmgr.c:490: Fehler: »list« nicht deklariert (erste Benutzung
in dieser Funktion)
make[6]: *** [../common/dri_bufmgr.o] Fehler 1
make[6]: Leaving directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2/src/mesa/drivers/dri/i915tex'
make[5]: *** [subdirs] Fehler 1
make[5]: Leaving directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2/src/mesa/drivers/dri'
make[4]: *** [linux-solo] Fehler 2
make[4]: Leaving directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2/src/mesa'
make[3]: *** [default] Fehler 2
make[3]: Leaving directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2/src/mesa'
make[2]: *** [subdirs] Fehler 1
make[2]: Leaving directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2/src'
make[1]: *** [default] Fehler 1
make[1]: Leaving directory
`/var/tmp/portage/media-libs/mesa-7.0.2/work/Mesa-7.0.2'
make: *** [linux-dri-x86] Fehler 2
?[31;01m*?[0m
?[31;01m*?[0m ERROR: media-libs/mesa-7.0.2 failed.
?[31;01m*?[0m Call stack:
?[31;01m*?[0m ebuild.sh, line 1701: Called dyn_compile
?[31;01m*?[0m ebuild.sh, line 1039: Called qa_call 'src_compile'
?[31;01m*?[0m ebuild.sh, line 44: Called src_compile
?[31;01m*?[0m mesa-7.0.2.ebuild, line 213: Called die
?[31;01m*?[0m The specific snippet of code:
?[31;01m*?[0m emake -j1 ${CONFIG} || die Build failed
?[31;01m*?[0m The die message:
?[31;01m*?[0m Build failed
--
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: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
[Bug 13362] Error with i915tex in file dri_bufmgr.c Mesa 7.0.2
http://bugs.freedesktop.org/show_bug.cgi?id=13362 [EMAIL PROTECTED] changed: What|Removed |Added Summary|Error with i915tex in file |Error with i915tex in file |dri_bufmgr.c|dri_bufmgr.c Mesa 7.0.2 -- 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
