Bug 17490

Summary:

[GEM] Virtual Desktop size more restrictive compared to TTM on GM965

Product:

xorg

Reporter:

Tobias Hain <tobias.hain>

Component:

Driver/intel

Assignee:

Eric Anholt <eric>

Status:

RESOLVED FIXED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

minor

Priority:

medium

CC:

bryan.christ, haien.liu, jian.j.zhao, ormandj, shuang.he, udo.rader

Version:

7.3 (2007.09)

Keywords:

regression

Hardware:

x86 (IA32)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Bug Depends on:

Bug Blocks:

16990, 18858

Attachments:

Description	Flags
Xorg.0.log failing to allocate buffers	none
Xorg.0.log TTM memory manager succesful allocation of 3200 x 3000 virtual	none
Xorg.0.log successful GEM memory allocation	none
xorg.conf	none
Xorg.0.log successful GEM memory allocation with DRI2	none

Description Tobias Hain 2008-09-08 16:04:59 UTC

Created attachment 18753 [details]
Xorg.0.log failing to allocate buffers

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

tested with git tip components of 09/08/2008:
libdrm: (master)2880c86eb246aceeb5c750e27259a7b6d8897328
mesa 3d: (master)11d694b1bb0cb384d802d7e0e252cf5119febb98
xserver: (master)2db1afbf2e56d8743c701d81a5797001ce9e5c52
xf86-video-intel: (master)b9ef0ed7d7b96eca6394cd0d367369ec511d1bcd
gem kernel (eric's 2.6.27-rc4)1063ef90845d7c84f4799ac34bd23ef37860bdc0
http://cgit.freedesktop.org/~anholt/linux-2.6/commit/?h=drm-gem-merge&id=1063ef90845d7c84f4799ac34bd23ef37860bdc0

The virtual desktop is for example useful when having multiple screens simultaneous attached and providing a tiled view by means of xrandr. If the horizontal or vertical arrangement changes or rotated desktops come into play it is convenient to define a rather big virtual size in xorg.conf that accommodates for all cases. Such as:

        SubSection "Display"
                Virtual 3200 3000
        EndSubSection

With GEM as well as with TTM the intel driver reports on my machine:
(==) intel(0): VideoRam: 262144 KB

For example the above 3200 x 3000 with TTM results in this memory allocation:
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x0001ffff: ring buffer (128 kB)
(II) intel(0): 0x00020000-0x00029fff: HW cursors (40 kB)
(II) intel(0): 0x0002a000-0x00031fff: logical 3D context (32 kB)
(II) intel(0): 0x00032000-0x00043fff: exa G965 state buffer (72 kB)
(II) intel(0): 0x00044000-0x00044fff: overlay registers (4 kB)
(II) intel(0): 0x00045000-0x00045fff: power context (4 kB)
(II) intel(0): 0x00050000-0x0275ffff: front buffer (40000 kB)
(II) intel(0): 0x0077f000:            end of stolen memory
(II) intel(0): 0x02760000-0x0953cfff: exa offscreen (112500 kB)
(II) intel(0): 0x0953d000-0x0b9dbfff: back buffer (37500 kB)
(II) intel(0): 0x0b9dc000-0x0de7afff: depth buffer (37500 kB)
(II) intel(0): 0x0de7b000-0x0fe7afff: classic textures (32768 kB)
(II) intel(0): 0x10000000:            end of aperture

If I start the GEM enabled intel driver with the above virtual size of 3200 x 3000 it crashes failing to allocate some buffers:

(EE) intel(0): Failed to pin overlay registers: Cannot allocate memory
Fatal server error:
Couldn't bind memory for BO overlay registers

As https://bugs.freedesktop.org/show_bug.cgi?id=17442 shows the actual buffer allocation that fails may differ. Over at this bug it is:

(EE) intel(0): Failed to pin front buffer: Cannot allocate memory
Fatal server error:
Couldn't bind memory for BO front buffer

This was done using EXA acceleration.

Since there are multiple buffers involved used for different purposes the actual maximum number of total pixels in the virtual space changes with the X:Y aspect ratio.

I give two GEM examples here. Using 3200 horizontal pixel, the maximum vertical pixels possible without getting an error were 2238 resulting in this allocation:

(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x005fffff: compressed frame buffer (6144 kB, 0x000000007f800000 physi
cal
)
(II) intel(0): 0x00600000-0x00600fff: compressed ll buffer (4 kB, 0x000000007fe00000 physical
)
(II) intel(0): 0x00601000-0x00601fff: power context (4 kB)
(II) intel(0): 0x0077f000:            end of stolen memory
(II) intel(0): 0x0077f000-0x08808fff: DRI memory manager (131624 kB)
(II) intel(0): 0x08809000-0x0d9fefff: exa offscreen (83928 kB)
(II) intel(0): 0x0d9ff000-0x0f9fefff: classic textures (32768 kB)
(II) intel(0): 0x10000000:            end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x0077f000:            start of memory manager
(II) intel(0): 0x0079f000-0x022f6fff: depth buffer (28000 kB) Y tiled
(II) intel(0): 0x0279f000-0x042f6fff: back buffer (28000 kB) X tiled
(II) intel(0): 0x04800000-0x06f0ffff: front buffer (40000 kB) X tiled
(II) intel(0): 0x0479f000-0x0479ffff: overlay registers (4 kB)
(II) intel(0): 0x047a0000-0x047b1fff: exa G965 state buffer (72 kB)
(II) intel(0): 0x047c0000-0x047c7fff: logical 3D context (32 kB)
(II) intel(0): 0x047c8000-0x047d1fff: HW cursors (40 kB)
(II) intel(0): 0x08809000:            end of memory manager

The second example uses 1600 horizontal pixels and the maximum vertical pixels possible without getting an error were 5040 resulting in this allocation:
(II) intel(0): Fixed memory allocation layout:
(II) intel(0): 0x00000000-0x005fffff: compressed frame buffer (6144 kB, 0x000000007f800000 physi
cal
)
(II) intel(0): 0x00600000-0x00600fff: compressed ll buffer (4 kB, 0x000000007fe00000 physical
)
(II) intel(0): 0x00601000-0x00601fff: power context (4 kB)
(II) intel(0): 0x0077f000:            end of stolen memory
(II) intel(0): 0x0077f000-0x07a04fff: DRI memory manager (117272 kB)
(II) intel(0): 0x07a05000-0x0d9fefff: exa offscreen (98280 kB)
(II) intel(0): 0x0d9ff000-0x0f9fefff: classic textures (32768 kB)
(II) intel(0): 0x10000000:            end of aperture
(II) intel(0): BO memory allocation layout:
(II) intel(0): 0x0077f000:            start of memory manager
(II) intel(0): 0x0079f000-0x0279cfff: depth buffer (32760 kB) Y tiled
(II) intel(0): 0x0279f000-0x0479cfff: back buffer (32760 kB) X tiled
(II) intel(0): 0x04800000-0x067fdfff: front buffer (32760 kB) X tiled
(II) intel(0): 0x0479f000-0x0479ffff: overlay registers (4 kB)
(II) intel(0): 0x047a0000-0x047b1fff: exa G965 state buffer (72 kB)
(II) intel(0): 0x047c0000-0x047c7fff: logical 3D context (32 kB)
(II) intel(0): 0x047c8000-0x047d1fff: HW cursors (40 kB)
(II) intel(0): 0x07a05000:            end of memory manager

The walkaround currently is to find a sufficient small, but still useful virtual desktop size with GEM.

Comment 1 Tobias Hain 2008-09-08 16:06:09 UTC

Created attachment 18754 [details]
Xorg.0.log TTM memory manager succesful allocation of 3200 x 3000 virtual

Comment 2 Tobias Hain 2008-09-08 16:06:58 UTC

Created attachment 18755 [details]
Xorg.0.log successful GEM memory allocation

Comment 3 Gordon Jin 2008-09-16 19:08:56 UTC

*** Bug 17618 has been marked as a duplicate of this bug. ***

Comment 4 Eric Anholt 2008-09-23 17:23:51 UTC

The solution to this problem is going to be a couple of things:

1) Allocate fewer buffers.
- If you're using GEM, you don't need the 32MB classic textures area.
- If you're using DRI2, you don't need the static front/back/depth buffers.
- If you're using UXA, you don't need the giant EXA pixmaps area.

2) Dynamically allocate front buffers so that people don't have to use xorg.conf to work around static limits.
We're going to require at least GEM and UXA for this, though likely DRI2 as well.

There are things that could be done between now and then to ease the pain (like tune down the exa pixmaps area), but I'd rather be spending time getting to GEM+DRI2+UXA everywhere.

Comment 5 zhao jian 2008-10-30 22:36:15 UTC

On G45 with GEM kernel also has such issue now. It will has such problem when I set it to 2900x2900 while 2800x2800 is OK. Error message is as following: 
(==) Log file: "/opt/X11R7/var/log/Xorg.0.log", Time: Fri Oct 31 13:14:22 2008
(==) Using config file: "/etc/X11/xorg.conf"
(EE) Failed to load module "freetype" (module does not exist, 0)
(EE) Failed to load module "type1" (module does not exist, 0)
(EE) intel(0): Failed to pin depth buffer: Cannot allocate memory

Fatal server error:
Couldn't bind memory for BO depth buffer


Libdrm: (master)1d930fc75b99a89fc77d35d8f95f2877cfd5d7f0
Mesa:   (master)2a877411dbe35abdd8c15fb4821d9232619d89cc
Xf86_video_intel:       (master)87ea531c5dc5b39809395b277c330854aaaaf019
Xserver:        (master)102c4dac7c521941f52652152b1660cd7f559d56
GEM_kernel:       (drm-intel-next)af1f46ebc03f4eab533e7a695d836ad9f255bf49

Comment 6 Gordon Jin 2008-12-09 00:43:05 UTC

*** Bug 18903 has been marked as a duplicate of this bug. ***

Comment 7 Wang Zhenyu 2008-12-09 21:40:52 UTC

*** Bug 16990 has been marked as a duplicate of this bug. ***

Comment 8 zhao jian 2008-12-11 01:15:38 UTC

Chipset: GM965 
OSD:		Fedora release 9 (Sulphur)
Kernel:		2.6.28-rc6
Libdrm:		(master)b0d93c74d884b40bd94469a5ef75fdb2fef17680
Mesa:		(master)154a9e5317f890618932cea0129ef887e16baf84
Xserver:	(server-1.6-branch) b268458eab2f213ec14dfe8013aa714c187e3aab
Xf86_video_intel:   (master)        07f5a8223187c1abc79c104d2fa5859a54cecd30

On gm965 in UXA mode which will use DRI2, it can support virtual 8000x8000 allocating buffers successfully.

Comment 9 zhao jian 2008-12-11 17:05:53 UTC

Created attachment 21076 [details]
xorg.conf

Comment 10 zhao jian 2008-12-11 17:12:40 UTC

Created attachment 21077 [details]
Xorg.0.log successful GEM memory allocation with DRI2

Comment 11 Bryan Christ 2008-12-12 10:36:14 UTC

I tried using uxa for acceleration but my keyboard stopped responding at the GDM greeter screen.  What are the requirements for using uxa?

intel driver level?
kernel version?
xorg version? etc...

Comment 12 Gordon Jin 2008-12-13 04:32:37 UTC

(In reply to comment #11)
> I tried using uxa for acceleration but my keyboard stopped responding at the
> GDM greeter screen.  What are the requirements for using uxa?

Comment#8 seems to already answer.

> intel driver level?

master branch or xf86-video-intel-2.6-branch or the upcoming 2.6 release.

> kernel version?

Linus's kernel tree, or 2.6.28 kernel.

> xorg version? etc...

xserver master branch or server-1.6-branch.

Comment 13 Eric Anholt 2008-12-15 09:24:13 UTC

Marking this fixed as everything in step 1) is in, and it's been tested with UXA, and 2) is for review on the mailing list as well.

Comment 14 Bryan Christ 2008-12-15 09:31:02 UTC

[response to comment #12]
Thanks, Gordon.  Looks like Fedora 10 (even with latest updates) is a version behind on every one of these requirements :/

Comment 15 Gordon Jin 2008-12-24 17:45:03 UTC

*** Bug 19179 has been marked as a duplicate of this bug. ***

Comment 16 Gordon Jin 2009-01-30 20:15:26 UTC

*** Bug 19824 has been marked as a duplicate of this bug. ***

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.