Bug 17304 - [GEM] incomplete EXA/UXA rendering
Summary: [GEM] incomplete EXA/UXA rendering
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.3 (2007.09)
Hardware: x86 (IA32) Linux (All)
: highest critical
Assignee: Eric Anholt
QA Contact: Xorg Project Team
Depends on:
Reported: 2008-08-26 00:43 UTC by Tobias Hain
Modified: 2008-09-16 06:05 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

Xorg log taken from EXA launch (21.18 KB, text/plain)
2008-08-26 00:43 UTC, Tobias Hain
no flags Details
kern.log with WATCH_EXEC, WATCH_LRU enabled debugging (31.41 KB, text/plain)
2008-08-27 06:51 UTC, Tobias Hain
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Hain 2008-08-26 00:43:27 UTC
Created attachment 18516 [details]
Xorg log taken from EXA launch

System : Dell XPS M1330
Chipset: GM965 with 2 * 1GB memory in dual channel configuration
OS : Ubuntu 8.04.1

My gem enabled kernel, git xserver, libdrm, mesa, xf86-video-intel compile since the GEM enabled components entered the master branch.

The problem that I'm facing is that the desktop 2D rendering seems to be incomplete. Here's an example of EXA:

. no fonts (xserver build with --enable-builtin-fonts)
. hardly any icons

is it possible that only cpu rendered objects are visible?

Some more observations:

. EXA and compiz result in a black screen with some distortion. X is up and running, but you hardly see anything.

. UXA with tiling (= default) looks roughly like this:

. UXA without tiling looks similar to EXA:

. UXA without tiling and compiz looks fine except the 2D part:

Any ideas?

Some more information about the way I build all the components:

I followed pretty much this guide:
also recognizing these notes:

xserver is built with
--enable-builtin-fonts --disable-dri2

drm is built with

The kernel I used is

and it doesn't make a difference whether I used the kernel modules "i915, drm" taken from this git repository or those that I built in "drm/linux-core".

Kernel startet with "nopat" (no Page Attribute Table) option.
Comment 1 Tobias Hain 2008-08-27 01:37:14 UTC
I don't know whether it's related. I'm seeing two messages over and over again in kern.log:

[drm:i915_gem_execbuffer] *ERROR* Going to lose the write domain on obj 15 size 16777216
[drm:i915_gem_execbuffer] *ERROR* Going to lose the write domain on obj 14 size 16777216

thrown by i915_gem.c line 1924.

There's another strange message. Might be drm related too:

Pid: 0, comm: swapper Not tainted 2.6.27-rc2-gem #4
[<c01272ff>] warn_on_slowpath+0x5f/0xa0
[<c0170030>] mempool_free_pages+0x0/0x10
[<c017034f>] mempool_free+0x7f/0x90
[<c01425e1>] getnstimeofday+0x41/0xe0
[<c013f8d8>] ktime_get+0x18/0x40
[<c0146bb2>] tick_program_event+0x42/0x70
[<c01443da>] clocksource_get_next+0x3a/0x40
[<c0142e12>] update_wall_time+0x442/0x8d0
[<c033c919>] _spin_lock_irqsave+0x29/0x40
[<c012cc38>] local_bh_enable_ip+0x78/0xa0
[<f8f3ec91>] drm_lock_take+0x71/0xd0 [drm]
[<f8f3e1ac>] drm_locked_tasklet_func+0x3c/0x90 [drm]
[<c012c3a0>] tasklet_hi_action+0x70/0x100
[<c012c93a>] __do_softirq+0x8a/0x110
[<c012ca15>] do_softirq+0x55/0x60
[<c012cb9d>] irq_exit+0x5d/0x80
[<c0106330>] do_IRQ+0x40/0x70
[<c0104877>] common_interrupt+0x23/0x28
[<f8873121>] acpi_idle_enter_bm+0x318/0x39a [processor]
[<c02a3183>] cpuidle_idle_call+0x73/0xd0
[<c0102ce5>] cpu_idle+0x65/0x100
[ end trace 8b80460df52ba2be ]---
Comment 2 Tobias Hain 2008-08-27 06:51:20 UTC
Created attachment 18545 [details]
kern.log with WATCH_EXEC, WATCH_LRU enabled debugging 

The snippet is taken around the error messages to get information about the buffer states when "[drm:i915_gem_execbuffer] *ERROR*" is thrown.
Comment 3 Tobias Hain 2008-08-28 07:45:21 UTC
Meanwhile I updated the kernel from Eric's git repository 2.6.27-rc2 -> 2.6.27-rc4 with GEM patches. It didn't change anything regarding this bug/error.

I booted into a NON-GEM enabled kernel (the generic Ubuntu 8.04.1 one which calls itself 2.6.24-19-generic) and launched the GEM enabled libdrm, xserver, intel driver stack on top of this. Here everything works fine. No visual bugs except this message in kern.log:
[drm:i915_getparam] *ERROR* Unknown parameter 5

That means I haven't discovered any major GEM enabled intel driver regressions so far and the fall back to the TTM memory manager works fine. This was expected when you announced the intel 2.5.0 test driver:

If there's a suite of testcases available to throw at the GEM kernel backend, I'd be happy to do that.
Comment 4 Tobias Hain 2008-08-31 15:30:31 UTC
The patch of comment 5 in this bugreport

fixes the EXA rendering here as well. Those bugs seem to be duplicates/related.

Untiled UXA is not fixed by the patch as also reported by Philip Langdale in comment #8.

Furthermore EXA + compiz still doesn't work (UXA and compiz does) with GEM enabled kernels. However since I've never seen EXA + compiz + GEM working, it's most likely a different bug.
Comment 5 Gordon Jin 2008-09-09 19:00:25 UTC
cworth, any idea for this render accel failure?
This might dup with #17341.
Comment 6 liuhaien 2008-09-10 19:48:51 UTC
(In reply to comment #5)
> cworth, any idea for this render accel failure?
> This might dup with #17341.

this issue also happens on our gm965 and q965.
Comment 7 Gordon Jin 2008-09-10 23:58:07 UTC
This seems to be impacting various platforms.
Comment 8 Gordon Jin 2008-09-13 21:21:03 UTC
bug#17341 has been fixed and the patch committed.
Tobias/Haien, could you retest master branch to see if that helps this bug?
Comment 9 Tobias Hain 2008-09-14 03:41:17 UTC
I'm still blocked by http://bugs.freedesktop.org/show_bug.cgi?id=17531 and can't test this patch.

However since the commited patch is byte equal to the patch I tested in https://bugs.freedesktop.org/show_bug.cgi?id=17304#c4 I'm convinced this bug is resolved.


What do we do with the UXA case? I'm trying to get the puzzle together:

From Jesse's commit note "Only BO map render state if kernel mode setting is active"

and "Ok, just pushed this workaround."

This looks to me as if the UXA case would be fixed by running a kernel mode setting enabled kernel. On the other hand

"However the driver [] should run well on top of GEM enabled kernels (and a bit less well against mode setting enabled kernels if you include the patches I posted to dri-devel recently, though note that there's no video support with kernel mode setting yet)."

What does "no video support" mean in this posting?
Comment 10 Tobias Hain 2008-09-16 06:05:00 UTC
Yes, the commited patch of
fixes the EXA case.

The UXA case is fixed when using a DRI2 enabled xserver and running the (dri2) branch of intel 2d driver.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.