On 8 Mar 2004 [EMAIL PROTECTED] wrote:

> Leif Delgass <[EMAIL PROTECTED]> writes:
> 
> > I forgot to bring in the drm_linux_list.h for bsd that was added on 
> > the mach64-0-0-6-branch.  I just added it and it is included from drmP.h.  
> > With any luck that should fix the compile errors in the kernel module.
> 
> ok, thank you again, that does fix the compile errors in the kernel module.
> I built the module, and loaded it:
> 
>     # kldstat | grep mach64
>      5    1 0xc4e88000 15000    mach64.ko
>     # ls -l /dev/dri/card0
>     crw-rw-rw-  1 root  wheel  145,   0 Mar  8 08:08 /dev/dri/card0
> 
> I set my ld path to point to the new gl libs:
> 
>     # setenv LD_LIBRARY_PATH 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/:$LD_LIBRARY_PATH
>     # ldd ````which glxinfo````
>     /usr/X11R6/bin/glxinfo:
>             libGLU.so.1 => 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGLU.so.1
>  (0x28079000)
>             libGL.so.1 => 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libGL.so.1
>  (0x280f3000)
>             libXext.so.6 => 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libXext.so.6
>  (0x2816f000)
>             libX11.so.6 => 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib//libX11.so.6
>  (0x2817e000)
>             libc_r.so.5 => /usr/lib/libc_r.so.5 (0x28246000)
>             libm.so.2 => /lib/libm.so.2 (0x2826a000)
>             libc.so.5 => /lib/libc.so.5 (0x28283000)
>             libstdc++.so.4 => /usr/lib/libstdc++.so.4 (0x2835d000)
>     # glxinfo -display :1
>     name of display: :1.0
>     display: :1  screen: 0
>     direct rendering: Yes
>     [rest of output snipped for clarity.]
> 
> but glxgears only gets about 115.3 frames:
> 
>     # glxgears -display :1 &
>     [1] 6381
>     577 frames in 5.0 seconds = 115.400 FPS
>     576 frames in 5.0 seconds = 115.200 FPS
>     576 frames in 5.0 seconds = 115.200 FPS
>     577 frames in 5.0 seconds = 115.400 FPS
> 
> which is the same as without dri. So gl thinks it has dri, but performance
>     is no better.

Don't expect huge numbers from glxgears, you'll notice more improvement in 
apps using textures and more geometry than gears.
 
> (note - the -display :1 is because I am running two Xservers. If I
>     disable the 2nd Xserver, I still get only 115 frames, but I
>     didn't have that output to paste.)
> 
> (note2 - I am going to try building a few gl games - gltron and tuxracer - and
>     see if they improve.)

You should see a significant difference in those.

> I looked at the log file, and here is the important output:
> 
> XFree86 Version 4.3.99.12 (DRI mach64-0-0-7-branch)
> [snip]
> (II) LoadModule: "glx"
> (II) Loading 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libglx.a
> (II) Module glx: vendor="The XFree86 Project"
>       compiled for 4.3.99.12, module version = 1.0.0
>       ABI class: XFree86 Server Extension, version 0.2
> (II) Loading sub module "GLcore"
> (II) LoadModule: "GLcore"
> (II) Loading 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libGLcore.a
> (II) Module GLcore: vendor="The XFree86 Project"
>       compiled for 4.3.99.12, module version = 1.0.0
>       ABI class: XFree86 Server Extension, version 0.2
> (II) Loading extension GLX
> (II) LoadModule: "dri"
> (II) Loading 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/extensions/libdri.a
> (II) Module dri: vendor="The XFree86 Project"
>       compiled for 4.3.99.12, module version = 1.0.0
>       ABI class: XFree86 Server Extension, version 0.2
> (II) Loading sub module "drm"
> (II) LoadModule: "drm"
> (II) Loading 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/freebsd/libdrm.a
> (II) Module drm: vendor="The XFree86 Project"
>       compiled for 4.3.99.12, module version = 1.0.0
>       ABI class: XFree86 Server Extension, version 0.2
> (II) Loading extension XFree86-DRI
> (II) LoadModule: "ati"
> (II) Loading 
> /2nd/usr/X11R6-DRI/mach64-0-0-7-branch/07_march_2004_no_strict_aliasing/lib/modules/drivers/ati_drv.o
> (II) Module ati: vendor="The XFree86 Project"
>       compiled for 4.3.99.12, module version = 6.5.3
>       Module class: XFree86 Video Driver
>       ABI class: XFree86 Video Driver, version 0.7
> [snip]
> (II) ATI:  Shared PCI/AGP Mach64 in slot 1:0:0 detected.
> (II) ATI:  Shared PCI/AGP Mach64 in slot 1:0:0 assigned to active "Device" section 
> "card0".
> [snip]
> (II) ATI(0): [drm] SAREA 2200+1208: 3408
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 7, (OK)
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 7, (OK)
> drmOpenByBusid: Searching for BusID pci:0000:01:00.0
> drmOpenDevice: node name is /dev/dri/card0
> drmOpenDevice: open result is 7, (OK)
> drmOpenByBusid: drmOpenMinor returns 7
> drmOpenByBusid: drmGetBusid reports pci:0000:01:00.0
> (II) ATI(0): [drm] DRM interface version 1.2
> (II) ATI(0): [drm] created "mach64" driver at busid "pci:0000:01:00.0"
> (II) ATI(0): [drm] added 8192 byte SAREA at 0xc4f0d000
> (II) ATI(0): [drm] mapped SAREA 0xc4f0d000 to 0x282d3000
> (II) ATI(0): [drm] framebuffer handle = 0xfd000000
> (II) ATI(0): [drm] added 1 reserved context for kernel
> (II) ATI(0): [drm] Will request pseudo-DMA (MMIO) mode
                                  ^^^^^^^^^^^^^^^^^
[snip rest of log]

Everything in the log looks fine, but you are getting MMIO mode and not 
real DMA mode.  You should use real DMA to get the best performance.  
Actually, I thought real DMA mode was the default, but you should be able 
to force it on with:

Option "DMAMode" "async"

in the Device section of XF86Config.

This is somewhat offtopic here, but I should point out that MMIO mode is
not necessarily more secure than DMA mode right now.  We have code to
verify what registers are being written to by the commands in client
submitted buffers.  The verification is done regardless of whether the
commands are passed to the card via DMA or MMIO.  However, in the drm
driver we are copying the submitted buffers to other "unused" client
buffers for verfication.  The "unused" buffers are still mapped in
userspace and can be written by clients.  The intention is to instead use
a pool of private buffers not mapped to userspace (rather than continually
unmapping and mapping client buffers).  The part that is missing (and
preventing us from merging with the trunk) is a way to allocate and use a
set of private unmapped buffers in addition to the client buffers in the
DRM.

-- 
Leif Delgass 
http://www.retinalburn.net




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to