DRI - VIA - CLE266

[Luc Verhaegen]

On Fri, Jun 02, 2006 at 12:10:06AM -0700, Gregoire Gentil wrote:
> Hello,
> 
> I'm trying to use DRI on a VIA Chipset (CLE266) with 256MB of Ram. I
> have compiled and installed via_drv.so from unichrome.sf.net (latest
> version as of 5/31/2006). I have also compiled and installed
> unichrome_dri.so, libGL.so.1.2 and libGLU.so.1.3.060500 from MesaLib6.5
> (latest version as of 5/31/2006). I have the following drirc file:
> 
> <driconf>
>     <device screen="0" driver="unichrome">
>         <application name="all">
>         </application>
>     </device>
> </driconf>
> 
> A glxinfo returns:
> 
> root at ubuntu:~# LIBGL_DEBUG=verbose glxinfo
> name of display: :0.0
> libGL: XF86DRIGetClientDriverName: 5.0.0 unichrome (screen 0)
> libGL: OpenDriver: trying /usr/lib/dri/unichrome_dri.so
> drmOpenByBusid: Searching for BusID PCI:1:0:0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 4, (OK)
> drmOpenByBusid: drmOpenMinor returns 4
> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> __driCreateNewScreen_20050727 - succeeded
> AllocateDmaBuffer fail
> display: :0  screen: 0
> direct rendering: No
> 
> Xorg.0.log returns:
> 
> (II) VIA(0): 3D Engine has been initialized.
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 6, (OK)
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 6, (OK)
> drmOpenByBusid: Searching for BusID PCI:1:0:0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 6, (OK)
> drmOpenByBusid: drmOpenMinor returns 6
> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> (II) VIA(0): [drm] DRM interface version 1.2
> (II) VIA(0): [drm] created "via" driver at busid "PCI:1:0:0"
> (II) VIA(0): [drm] added 8192 byte SAREA at 0xd03d3000
> (II) VIA(0): [drm] mapped SAREA 0xd03d3000 to 0xb72fc000
> (II) VIA(0): [drm] framebuffer handle = 0xd8000000
> (II) VIA(0): [drm] added 1 reserved context for kernel
> (II) VIA(0): [dri] visual configs initialized.
> (II) VIA(0): [drm] register handle = 0xde000000
> (II) VIA(0): [drm] mmio Registers = 0xde000000
> (II) VIA(0): [dri] mmio mapped.
> (II) VIA(0): [drm] using DRM driver version 2.7.4 (20051116)
> (WW) VIA(0): [drm] Not using DMA for copying to FB (drm driver older
> than 2.7.5).
> (II) VIA(0): Using XFree86 Acceleration Architecture (XAA)
> 
> I have the latest Ubuntu kernel available: 2.6.15-23.
> 
> What can I make DRI work? Is it the problem with DMA?
> 
> Thanks by advance for your answer,
> 
> Gregoire
> 
> 
I read your personal mail, just didn't get round to answering it yet.

The short answer is: Please set your Framebuffer to more than 8MB.

The long answer is:

This is a static FB allocation issue i'm still pondering about.

I still need to push the fix that makes the static allocation not claim 
more than what ram is available. This includes the dri initialisation 
properly checking remaining FB and warning about it, and properly 
reserving some space for the cursor beforehand.

I still need to move the cursor allocation to right after the front and 
back buffers, so that the cursor can function as a canary: If the cursor 
buggers up, then more pixmap cache was used than was allowed. This is 
not fatal, as i remember the cursor going bonkers all the time back when 
i was using windows 98 and an S3 trio, just nasty.

I'm also still wondering wether I really need to claim all of FB for 
pixmap cache when in a low memory situation.

Right now, it tries to claim 2048lines for combined front and back 
buffers (save cursor and virtuous gueue). Which is exactly 8MB for 
something as low as 1024x768 at 32bpp.

But then again, at 8MB, you don't want to run DRI. My Xv code requires 
at least once the actual YUV buffer, plus twice the YUY conversion; or 
2227kB for a PAL DVD. But this is also something one can live without at 
8MB.

I will need to test what the implications are of a reduced pixmap cache.

Luc Verhaegen.