New DRI interface changes landed
Hi, I've committed the new DRI interface that will enable GLX 1.4 and redirected rendering. The interface is not backwards compatible, so the git X server will not be able to load older DRI drivers for AIGLX and the DRI drivers from Mesa git wont work with older X servers. So to get AIGLX running, get and install git mesa, the compile the X server against that. Furthermore, the X server now needs the 1.4.9 version of glproto, since I added support for GLX_SGIX_pbuffer. I only tagged 1.4.9 in git, but didn't do tarballs or send out a release yet. Will do that as soon as possible. cheers, Kristian - 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: New DRI interface changes landed
2007/10/13, Kristian Høgsberg <[EMAIL PROTECTED]>:
> Hi,
>
> I've committed the new DRI interface that will enable GLX 1.4 and
> redirected rendering. The interface is not backwards compatible, so
> the git X server will not be able to load older DRI drivers for AIGLX
> and the DRI drivers from Mesa git wont work with older X servers. So
> to get AIGLX running, get and install git mesa, the compile the X
> server against that.
>
> Furthermore, the X server now needs the 1.4.9 version of glproto,
> since I added support for GLX_SGIX_pbuffer. I only tagged 1.4.9 in
> git, but didn't do tarballs or send out a release yet. Will do that
> as soon as possible.
Hi,
I built everything from git after your changes, and I now have a crash
in the xserver when launching compiz.
Configuration :
- Intel G33 chipset using the driver from git
(e04333a6352040bc883655d606923c912d005981)
- git mesa f9c6dfc4d12451c21f39f38b048758cbee5723cf + patch from
http://bugs.freedesktop.org/show_bug.cgi?id=9264 (to run compiz)
- xserver : 927757e1028f45f7fd94b9a2ab35567e0f34b2a8
Backtrace of the crash when launching compiz :
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47580776315008 (LWP 6095)]
glxFillAlphaChannel (pixmap=, x=,
y=0, width=, height=)
at ../../../GL/glx/glxdri.c:318
318 *p++ |= 0xFF00;
(gdb) bt
#0 glxFillAlphaChannel (pixmap=,
x=, y=0, width=,
height=) at ../../../GL/glx/glxdri.c:318
#1 0x2b46438c153c in __glXDRIbindTexImage (
baseContext=, buffer=,
glxPixmap=0x13b5120) at ../../../GL/glx/glxdri.c:435
#2 0x2b464388f5bc in __glXDisp_BindTexImageEXT (cl=,
pc=) at ../../../GL/glx/glxcmds.c:1594
#3 0x2b464388e722 in __glXDisp_VendorPrivate (cl=0x13de848,
pc=) at ../../../GL/glx/glxcmds.c:2316
#4 0x2b4643892692 in __glXDispatch (client=0x13de690)
at ../../../GL/glx/glxext.c:506
#5 0x0044d0f0 in Dispatch () at ../../dix/dispatch.c:502
#6 0x00435955 in main (argc=10, argv=0x7fff69a196c8,
envp=) at ../../dix/main.c:452
(gdb) bt full
#0 glxFillAlphaChannel (pixmap=,
x=, y=0, width=,
height=) at ../../../GL/glx/glxdri.c:318
p = (CARD32 *) 0x0
end = (CARD32 *) 0x1e00
pixels = (CARD32 *) 0x0
#1 0x2b46438c153c in __glXDRIbindTexImage (
baseContext=, buffer=,
glxPixmap=0x13b5120) at ../../../GL/glx/glxdri.c:435
numRects =
p =
pRegion = (RegionPtr) 0x0
pixmap = (PixmapPtr) 0x19a1ae0
bpp = 4
override = 0
texname = 12
format = 32993
type = 5121
pScreen =
__func__ = "__glXDRIbindTexImage"
#2 0x2b464388f5bc in __glXDisp_BindTexImageEXT (cl=,
pc=) at ../../../GL/glx/glxcmds.c:1594
client = (ClientPtr) 0x13de690
context = (__GLXcontext *) 0xa529a0
pGlxDraw = (__GLXdrawable *) 0x0
drawId = 46137754
error =
#3 0x2b464388e722 in __glXDisp_VendorPrivate (cl=0x13de848,
pc=) at ../../../GL/glx/glxcmds.c:2316
req = (xGLXVendorPrivateReq *) 0x26ef384
proc = (__GLXdispatchVendorPrivProcPtr) 0
#4 0x2b4643892692 in __glXDispatch (client=0x13de690)
at ../../../GL/glx/glxext.c:506
stuff = (xGLXSingleReq *) 0x26ef384
opcode =
proc = (
__GLXdispatchSingleProcPtr) 0x2b464388e6f0 <__glXDisp_VendorPrivate>
cl = (__GLXclientState *) 0x13de848
retval = 1
#5 0x0044d0f0 in Dispatch () at ../../dix/dispatch.c:502
clientReady =
result =
client =
nready = 0
start_tick = 31860
#6 0x00435955 in main (argc=10, argv=0x7fff69a196c8,
envp=) at ../../dix/main.c:452
pScreen =
i = 1
error = 0
xauthfile =
alwaysCheckForInput = {0, 1}
--
I can provide more information if necessary,
Vincent
-
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: New DRI interface changes landed
On Sat, 2007-10-13 at 19:44 +0200, Vincent Vanackere wrote: > > I built everything from git after your changes, and I now have a crash > in the xserver when launching compiz. > Configuration : > - Intel G33 chipset using the driver from git > (e04333a6352040bc883655d606923c912d005981) > - git mesa f9c6dfc4d12451c21f39f38b048758cbee5723cf + patch from > http://bugs.freedesktop.org/show_bug.cgi?id=9264 (to run compiz) > - xserver : 927757e1028f45f7fd94b9a2ab35567e0f34b2a8 > > Backtrace of the crash when launching compiz : [...] > #0 glxFillAlphaChannel (pixmap=, > x=, y=0, width=, > height=) at ../../../GL/glx/glxdri.c:318 > p = (CARD32 *) 0x0 I suppose you're using EXA? My recent EXA changes broke the __glXDRIbindTexImage fallback code, it should be fixed to use proper X functions to manipulate the pixmap data instead of touching it directly. > #1 0x2b46438c153c in __glXDRIbindTexImage ( > baseContext=, buffer=, > glxPixmap=0x13b5120) at ../../../GL/glx/glxdri.c:435 > numRects = > p = > pRegion = (RegionPtr) 0x0 > pixmap = (PixmapPtr) 0x19a1ae0 > bpp = 4 > override = 0 The question is why it doesn't use zero-copy texture-from-pixmap in the first place though. > I can provide more information if necessary, As always, the X log file might be useful. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - 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: New DRI interface changes landed
2007/10/15, Michel Dänzer <[EMAIL PROTECTED]>: > > On Sat, 2007-10-13 at 19:44 +0200, Vincent Vanackere wrote: > > > > I built everything from git after your changes, and I now have a crash > > in the xserver when launching compiz. > > Configuration : > > - Intel G33 chipset using the driver from git > > (e04333a6352040bc883655d606923c912d005981) > > - git mesa f9c6dfc4d12451c21f39f38b048758cbee5723cf + patch from > > http://bugs.freedesktop.org/show_bug.cgi?id=9264 (to run compiz) > > - xserver : 927757e1028f45f7fd94b9a2ab35567e0f34b2a8 > > > > Backtrace of the crash when launching compiz : > > [...] > > > #0 glxFillAlphaChannel (pixmap=, > > x=, y=0, width=, > > height=) at ../../../GL/glx/glxdri.c:318 > > p = (CARD32 *) 0x0 > > I suppose you're using EXA? My recent EXA changes broke the > __glXDRIbindTexImage fallback code, it should be fixed to use proper X > functions to manipulate the pixmap data instead of touching it directly. Yes, using EXA... > > #1 0x2b46438c153c in __glXDRIbindTexImage ( > > baseContext=, buffer=, > > glxPixmap=0x13b5120) at ../../../GL/glx/glxdri.c:435 > > numRects = > > p = > > pRegion = (RegionPtr) 0x0 > > pixmap = (PixmapPtr) 0x19a1ae0 > > bpp = 4 > > override = 0 > > The question is why it doesn't use zero-copy texture-from-pixmap in the > first place though. > > > > I can provide more information if necessary, > > As always, the X log file might be useful. > I'm attaching the log from the latest xserver/mesa (from git, still crashing with the same backtrace when I launch compiz). Best regards, Vincent This is a pre-release version of the X server from The X.Org Foundation. It is not supported in any way. Bugs may be filed in the bugzilla at http://bugs.freedesktop.org/. Select the "xorg" product for bugs you find in this release. Before reporting bugs in pre-release versions please check the latest version in the X.Org Foundation git repository. See http://wiki.x.org/wiki/GitPage for git access instructions. X.Org X Server 1.4.0.1 Release Date: 5 September 2007 X Protocol Version 11, Revision 0 Build Operating System: Linux Ubuntu Current Operating System: Linux marvin 2.6.23-r4 #1 SMP PREEMPT Sat Oct 13 14:22:02 CEST 2007 x86_64 Build Date: 15 October 2007 06:54:41PM Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 15 19:04:10 2007 (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "Default Layout" (**) |-->Screen "Default Screen" (0) (**) | |-->Monitor "B2403WS" (**) | |-->Device "GMA 3100" (**) Option "AllowEmptyInput" (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType (==) RgbPath set to "/etc/X11/rgb" (==) ModulePath set to "/usr/lib/xorg/modules" (II) Open ACPI successful (/var/run/acpid.socket) (II) Loader magic: 0x7a60c0 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 3.0 X.Org XInput driver : 2.0 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on linux (++) using VT number 7 (--) PCI:*([EMAIL PROTECTED]:2:0) unknown vendor (0x8086) unknown chipset (0x29c2) rev 2, Mem @ 0xf220/524288, 0xe000/268435456, 0xf210/1048576, I/O @ 0xe200/8 (--) PCI: ([EMAIL PROTECTED]:2:1) unknown vendor (0x8086) unknown chipset (0x29c3) rev 2, Mem @ 0xf228/524288 (II) OS-reported resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) All system resource ranges: [0] -1 0 0x - 0x (0x1) MX[B] [1] -1 0 0x000f - 0x000f (0x1) MX[B] [2] -1 0 0x000c - 0x000e (0x3) MX[B] [3] -1 0 0x - 0x0009 (0xa) MX[B] [4] -1 0 0x - 0x (0x1) IX[B] [5] -1 0 0x - 0x (0x1) IX[B] (II) LoadModule: "extmod" (II) Loading /usr/lib/xorg/modules/extensions//libextmod.so (II) Module extmod: vendor="X.Org Foundation" compiled for 1.4.0.1, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 0.3 (II) Loading extension SHAPE (II) Loading extension MIT-SUNDRY-NONSTAN
Re: New DRI interface changes landed
On Mon, 2007-10-15 at 19:54 +0200, Vincent Vanackere wrote: > > (II) AIGLX: enabled GLX_MESA_copy_sub_buffer > (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control Update from xserver and mesa Git and try again. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - 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: New DRI interface changes landed
On 10/16/07, Michel Dänzer <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-10-15 at 19:54 +0200, Vincent Vanackere wrote: > > > > (II) AIGLX: enabled GLX_MESA_copy_sub_buffer > > (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control > > Update from xserver and mesa Git and try again. Thanks Michel, that looks like the right fix. I think I just disabled the tex offset extension when I was developing the buffer object based tfp and forgot to add it back. Kristian - 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: New DRI interface changes landed
On Tue, 2007-10-16 at 20:30 +0200, Vincent Vanackere wrote: > > On 10/16/07, Michel Dänzer <[EMAIL PROTECTED]> wrote: > > > > > > On Mon, 2007-10-15 at 19:54 +0200, Vincent Vanackere wrote: > > > > > > > > (II) AIGLX: enabled GLX_MESA_copy_sub_buffer > > > > (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control > > > > > > Update from xserver and mesa Git and try again. > > [ I had to also update libdrm from git to make everything compile. ] > The good news : X doesn't segfault anymore when running compiz... The > bad one : I now have another problem and I'm now getting an infinite > loop instead (100% cpu taken by Xorg). I'm getting the following > message ad nauseam in the logs : > > tossed event which came in late > mieqEnequeue: out-of-order valuator event; dropping. > tossed event which came in late > mieqEnequeue: out-of-order valuator event; dropping. > [...] > > Here's what I get if I attach a debugger : > > (gdb) bt > #0 0x2aed809c16c7 in ioctl () from /lib/libc.so.6 > #1 0x2aed81fc2926 in drmFenceWait (fd=10, flags=, > fence=0x1611fa0, flush_type=) at xf86drm.c:2520 > #2 0x2aed9300b9e6 in dri_ttm_fence_wait (fence=0x1611f80) > at intel_bufmgr_ttm.c:694 > #3 0x2aed92fee12e in intelFinish (ctx=0x15f79a0) at intel_context.c:318 > #4 0x2aed8175e8be in __glXDisp_Finish (cl=0x1627f48, > pc=) at ../../../GL/glx/single2.c:238 Looks like a GPU lockup. Does this also happen if you use the i915 kernel module from your kernel instead of from drm Git? The Mesa i915 driver is currently very slow using the TTM due to issues to be worked out in the DRM anyway. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer - 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: New DRI interface changes landed
2007/10/17, Michel Dänzer <[EMAIL PROTECTED]>: > > Here's what I get if I attach a debugger : > > > > (gdb) bt > > #0 0x2aed809c16c7 in ioctl () from /lib/libc.so.6 > > #1 0x2aed81fc2926 in drmFenceWait (fd=10, flags=, > > fence=0x1611fa0, flush_type=) at xf86drm.c:2520 > > #2 0x2aed9300b9e6 in dri_ttm_fence_wait (fence=0x1611f80) > > at intel_bufmgr_ttm.c:694 > > #3 0x2aed92fee12e in intelFinish (ctx=0x15f79a0) at intel_context.c:318 > > #4 0x2aed8175e8be in __glXDisp_Finish (cl=0x1627f48, > > pc=) at ../../../GL/glx/single2.c:238 > > Looks like a GPU lockup. Does this also happen if you use the i915 > kernel module from your kernel instead of from drm Git? The Mesa i915 > driver is currently very slow using the TTM due to issues to be worked > out in the DRM anyway. Indeed the non-git i195 kernel module makes things working again with compiz, except that I now occasionnaly get some screen corruption (a typical case occurs when minimising/maximising some windows, it looks like the some parts of the screen are not refreshed correctly). How can I help debug this issue better ? Vincent - 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
