Re: No DRM on Radeon X850

Jared D. McNeill wrote:
> On Sat, 31 Mar 2007, Arto Huusko wrote:
>> When I start X with "Load "dri"" in the modules section, the system
>> just hangs (with no signal on monitor). Even though I had
>> (sleep 60; shutdown -r) running in the background and ddb.onpanic=0,
>> the machine wouldn't reboot, so apparently it locked up. And of course
>> there's no Xorg.log.
> 
> Try adding the "NoTrapSignals" option to the ServerFlags section of 
> xorg.conf. Also, I tend to use ddb.tee_msgbuf=1 sysctl so I can see any 
> errors after a reboot.

When I started X with DRI as root just now, I finally managed to get
something, but not much better. X came up with signal on monitor,
but the display was all garbled up (fireworks display). Only the
mouse cursor was displayed clearly.

After I moved the mouse around a bit, the cursor disappeared and
soon after that the monitor signal went out, too. I was logged in
via ssh from another machine, and that connection had died also,
so the machine wedged completely. ddb.onpanic was 0, and I had
ddb.tee_msgbuf=1, but there were no messages in the msgbuf, besides
the drm debug stuff.

However, I managed to save the X logs, which are attached, and I
also attached the DRM_DEBUG output I got.

_XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6
_XSERVTransOpen: transport open failed for inet6/lady:0

Re: No DRM on Radeon X850

Hello,

I managed to start X with DRI by changing the radeon driver's BusType
to PCI, and glxinfo now reports

OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R300 20060815 TCL
OpenGL version string: 1.3 Mesa 6.5.2
OpenGL extensions:

However, glxgears will not run. It just exits with the error

drmRadeonCmdBuffer: -22 (exiting)

DRM_DEBUG output, however, does not contain any error messages.
Am I mistaken that when I run glxgears, it will try to communicate
with the DRM driver directly, and not through the X server?
I'm asking because I only see X server's pid in DRM_DEBUG output.

Re: drm on amd64

This is exactly the same problem I had on amd64; I've since switched
to i386 (for reasons other than drm; linux compatability on amd64 for
EMT64 processors is broken).  Could you file a PR for this, please?

Thanks,

--Blair

--

-- 
Support WFMU-FM: free-form radio for the masses!
<http://www.wfmu.org/>

"The frivolity and boredom which unsettle the established order, the
vague foreboding of something unknown, these are the heralds of
approaching change.  The gradual crumbling that left unaltered the
face of the whole is cut short by a sunburst which, in one flash,
illuminates the features of the new world."  --G.W.F. Hegel,
_Phenomenology of Spirit_ 5:11

Re: Good news! (was Re: Radeon DRI)

Jared D. McNeill wrote:
>  * Had to modify Xorg to link against libpthread to make AIGLX happy.

I'm not yet convinced libpthread is necessary.
On my system, neither Xorg nor anything in /usr/pkg/lib/xorg/modules
or /usr/pkg/lib/dri is linked against libpthread, and AIGLX (i915)
works. I also havn't found any evidence in the xorg-server code
that multiple threads are used.

>   * That score, by the way, was captured while running GNOME 2.16, AIGLX,
>     and compiz + gtk-window-decorator, with all of the fancy wobbly /
>     expose / fade / etcrap plugins active.

I've been running compiz with fvwm, worked well too. Only that
Xv video output conflicts. The "XAANoOffscreenPixmaps" option
is necessary for i915 too.
If you have ideas for pkgsrc/wm/compiz, feel free to commit.

best regards
Matthias

Re: Good news! (was Re: Radeon DRI)

Matthias Drochner wrote:
> Jared D. McNeill wrote:
>>  * Had to modify Xorg to link against libpthread to make AIGLX happy.
> 
> I'm not yet convinced libpthread is necessary.
> On my system, neither Xorg nor anything in /usr/pkg/lib/xorg/modules
> or /usr/pkg/lib/dri is linked against libpthread, and AIGLX (i915)
> works. I also havn't found any evidence in the xorg-server code
> that multiple threads are used.

My libGL ended up being linked against libpthread, this is why I needed it.

Cheers,
Jared

[ANNOUNCE] A Build System For X.Org Modular (fwd)

I haven't looked at this yet, but I read it supports cross-compiling ...

---------- Forwarded message ----------
Date: Mon, 2 Apr 2007 23:50:19 +0200
From: Egbert Eich <eich <at> freedesktop.org>
To: xorg <at> lists.freedesktop.org
Subject: [ANNOUNCE] A Build System For X.Org Modular

I while ago I started to work on a build system for the modular
bits of X.Org.
Today I have attached a preliminary version to the bugzilla:
      https://bugs.freedesktop.org/show_bug.cgi?id=10511

The build system consists of 2 parts:
- A 'Maintainer' stage where the dependency information is obtained from
  the tree. This should be done in the SCM whenever a dependency of a module
  changes or new modules are added.
- A 'Builder' stage. Here the actual build takes place.
  The build stage can optionally pull or update modules from the SCM,
  build and install the modules. It supports lndir and sourcedir builds
  as well as a build 'prefix' and the DESTDIR variable.
  It also supports cross compiling.

This is work in progress. Two items are presently on my TODO list:
1. Support for tarball download and build.
2. Support for version dependencies.

I've been using this system to generate my X.Org builds for a while
now. 
In case others will find it useful, too I will add it to the SCM.

Re: NetBSD DRI Status documentation

On Fri, 2007-03-30 at 17:20 -0400, Jared D. McNeill wrote:
> On Fri, 30 Mar 2007, Iain Hibbert wrote:
> > I fairly ignorant in this field so not sure if or how this work will
> > affect my visual experience, is it possible that DVD rendering will be
> > improved?
> 
> Potentially.. DRI is a prerequisite for Xvideo motion compensation 
> acceleration. This feature is unavailable in the Radeon drivers as far as 
> I can tell (what I've been testing with so far), but I have a funny 
> feeling that the Xorg/DRI/DRM S3 Savage drivers support it.

Right, nobody's REed the Radeon motion-comp hardware yet.

--

-- 
Eric Anholt                             anholt <at> FreeBSD.org
eric <at> anholt.net                         eric.anholt <at> intel.com

Re: DRM... what's needed?

On Thu, 2007-03-22 at 11:41 -0400, Michael Lorenz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> On Mar 21, 2007, at 14:17, Juan RP wrote:
> 
> > Hi, I have built a kernel with DRM support for my i945 chip.
> >
> > But xorg reports:
> >
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 9, (OK)
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 9, (OK)
> > drmOpenByBusid: Searching for BusID pci:0000:00:02.0
> > drmOpenDevice: node name is /dev/dri/card0
> > drmOpenDevice: open result is 9, (OK)
> > drmOpenByBusid: drmOpenMinor returns 9
> > drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
> > (II) I810(0): [drm] DRM interface version 1.2
> > (II) I810(0): [drm] created "i915" driver at busid "pci:0000:00:02.0"
> > (II) I810(0): [drm] added 8192 byte SAREA at 0xffff800002956000
> > (II) I810(0): [drm] drmMap failed
> > (EE) I810(0): [dri] DRIScreenInit failed. Disabling DRI.
> 
> Smells like amd64.
> I think we need to rewrite the memory management and mapping code. It 
> makes a whole bunch of assumptions that are really only true on i386 ( 

Re: drm drivers for NetBSD

On Thu, 2007-03-22 at 20:36 +0100, Matthias Drochner wrote:
> yhardy <at> uj.ac.za said:
> > > The "glxgears" score is actually a bit less than with software
> > > rendering
> > Did you turn off debugging? 
> 
> The code is compiled in, but the "hw.dri.debug" sysctl flag
> is switched off.
> 
> Checked a bit more throughly and found that software is only faster
> with the (relatively small) default window size of glxgears.
> At full screen size, dri wins: I'm getting 80 fps; about 9%
> of a CPU (of 2 on a dual-core) is used plus ~10% system time.
> Software rendering gives 64 fps and uses 99% of a CPU.
> The worst combination is btw to have dri enabled but AIGLX
> disabled. It uses a different way of software rendering
> appearently which causes flickering output and gives 19fps
> at 99% CPU load. In case it matters, the driver modules are
> from Mesa-6.5.2.

This sort of stuff is one of the reasons that every DRI developer ever
will yell at you and say "glxgears is not a benchmark!" :)  It's not a
representative workload of 3d activity that needs hardware acceleration,
and furthermore doesn't use normal techniques that any
performance-sensitive application uses.

Some have actually gone so far as to make glxgears require that you pass
-iacknowledgethatglxgearsisnotabenchmark to get the fps numbers.

--

-- 

drm radeon page fault

Hello,

I have a kernel page fault when I start X with the use of DRM. kernel
log is:

[drm:pid14460:drm_open] open_count = 0
[drm:pid14460:drm_open_helper] pid = 14460, minor = 0
[drm:pid14460:radeon_driver_open]
[drm:pid14460:drm_addmap] offset = 0x00000000, size = 0x00002000, type = 2
[drm:pid14460:drm_addmap] 8192 13 0xc0d8b000
[drm:pid14460:drm_addmap] Added map 2 0xc0d8b000/0x2000
[drm:pid14460:drm_addmap] offset = 0xff9f0000, size = 0x00010000, type = 1
[drm:pid14460:drm_ioremap] ioremap mem found: 0xd0900000
[drm:pid14460:drm_addmap] Added map 1 0xff9f0000/0x10000
[drm:pid14460:drm_addmap] offset = 0xf0000000, size = 0x08000000, type = 0
[drm:pid14460:drm_mtrr_add] offset=f0000000 size=134217728
uvm_fault(0xcbc2ce04, 0, 1) -> 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c01c32c8 cs 8 eflags 13246 cr2 c ilevel 0
panic: trap
syncing disks... 3 2 1 1 done

I have a radeon M6 (RV100) PCI detected at boot time:

radeondrm0 at vga0
info: [drm] ATI Radeon LY RV100 Mobility M6 (unit 0)
[drm:pid0:drm_load]
[drm:pid0:radeon_driver_load] PCI card detected
[drm:pid0:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0
[drm:pid0:drm_ctxbitmap_init] drm_ctxbitmap_init : 0