Re: missing definition
fre, 13,.05.2005 kl. 08.56 -0400, skrev David Kesselring: > I'm trying to build the software only mesa on cygwin but have a compile > error for a missing definition. Would any of you know where to look for > "M_E" from the following snip? > > t_vp_build.c, build_fog() > > case GL_EXP: emit_op1(p, VP_OPCODE_ABS, tmp, 0, input); > emit_op2(p, VP_OPCODE_MUL, tmp, 0, tmp, swizzle1(params,X)); > emit_op2(p, VP_OPCODE_POW, fog, WRITEMASK_X, > register_const1f(p, M_E), negate(tmp)); > ^^^ M_E is the mathematical constant e, usually defined in from glibc : # define M_E 2.7182818284590452354 /* e */ -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: No output on dvi ports when doing fullscreen 3d.
tor, 13,.01.2005 kl. 19.17 -0800, skrev Steve P. Shack: > This is an interesting bug I've come across. When using the Radeon > graphics driver doing full screen 3d on a DVI port. Output is only > displayed at 1280x1024 (native) resolution for the display. > > Plug the display into the D-sub connector, and the display is fine. Plug > in a dvi cable and you get no display. Raise the resolution to 1280x1024 > and you get display. Lower the resolution, to say 640x480, no display. > > Here's the kicker. I've only noticed this on one of the two lcd's I have > to test. A samsung 172T. 3d display works fine with my benq 783. > Unfortunately, they're different cables, and I haven't been able to test > with the same cable to remove that variable from the problem. > > Anyone have any ideas? Would mode setting code be setting an out of spec > mode on the DVI port that the Benq is handling more gracefully? perhaps > sending an analog signal on the DVI output for 3d applications? > > My tests for full screen 3d are bzflag, Wolfenstein 3d and my own opengl > applications. The particular card I'm using is a generic "power color" > Radeon 9200se. > It's a known problem, you can work around it by adding Option "DDCMode" "on" to the Device section of your xorg.conf Something in the radeon driver screws up when validating modes (compare xrandr output with and without ddcmode on) on lcd panels connected via dvi. There's a bugzilla entry for it, but I don't have the number at hand. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] r200 atom emit order again
Since the last reordering that fixed neverball, ut2k4 have had some very annoying flickering on my rv250. Today I finally found a new ordering that cures my problem without breaking neverball again. Please test on r200/rv280 and commit if it doesn't break. -- Ronny V. Vindenes <[EMAIL PROTECTED]> Index: src/mesa/drivers/dri/r200/r200_cmdbuf.c === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r200/r200_cmdbuf.c,v retrieving revision 1.13 diff -u -r1.13 r200_cmdbuf.c --- src/mesa/drivers/dri/r200/r200_cmdbuf.c 2 Oct 2004 05:22:19 - 1.13 +++ src/mesa/drivers/dri/r200/r200_cmdbuf.c 14 Nov 2004 13:42:01 - @@ -92,11 +92,7 @@ insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.tex[i] ); for (i = 0; i < mtu; ++i) insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.cube[i] ); - for (i = 0; i < 6; ++i) - insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.pix[i] ); - for (i = 0; i < 8; ++i) - insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.lit[i] ); for (i = 0; i < 3 + mtu; ++i) insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.mat[i] ); insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.eye ); @@ -105,6 +101,11 @@ insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.mtl[i] ); for (i = 0; i < 6; ++i) insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.ucp[i] ); + for (i = 0; i < 8; ++i) + insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.lit[i] ); + for (i = 0; i < 6; ++i) + insert_at_tail( &rmesa->hw.atomlist, &rmesa->hw.pix[i] ); + } static void r200SaveHwState( r200ContextPtr rmesa )
Re: Re: Re: UT2003/4 nearly all textures are broken
lÃr, 25,.09.2004 kl. 17.00 +0200, skrev Dieter NÃtzel: > > lÃr, 25,.09.2004 kl. 15.00 +0200, skrev Dieter NÃtzel: > > > > fre, 24,.09.2004 kl. 14.06 +0200, skrev Dieter NÃtzel: > > > > > > > > > > > > > > Latest DRI and DRM CVS. > > > > > > > > > > Yesterday's DRI CVS was fine (textures). > > > > > > > > I see this too, but not only in ut2k3/4 - I see it in several programs, > > > > but often it doesn't happen immediately e.g. neverball is fine untill I > > > > enter the option screen - then all textures are broken untill I restart > > > > the game. > > > > cvs as of today is almost fixed - the textures no longer disappear > > completely, but sometimes they flash off-on. I see it in both ut2k4 and > > neverball > > Can you please try Q3A, to? > No, running x86-64 biarch. When are we going to break 64bit arches to allow 32 & 64 bit clients at the same time? -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Re: UT2003/4 nearly all textures are broken
lÃr, 25,.09.2004 kl. 15.00 +0200, skrev Dieter NÃtzel: > > fre, 24,.09.2004 kl. 14.06 +0200, skrev Dieter NÃtzel: > > > > > > > > Latest DRI and DRM CVS. > > > > > > Yesterday's DRI CVS was fine (textures). > > > > I see this too, but not only in ut2k3/4 - I see it in several programs, > > but often it doesn't happen immediately e.g. neverball is fine untill I > > enter the option screen - then all textures are broken untill I restart > > the game. cvs as of today is almost fixed - the textures no longer disappear completely, but sometimes they flash off-on. I see it in both ut2k4 and neverball > > > > On a happier note, ipers is giving the best performance yet > > We know;-) > > > - 1168000 > > Can you elaborate? ati 9000 agp on athlon64 3200+ -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: UT2003/4 nearly all textures are broken
fre, 24,.09.2004 kl. 14.06 +0200, skrev Dieter NÃtzel: > > Latest DRI and DRM CVS. > > Yesterday's DRI CVS was fine (textures). I see this too, but not only in ut2k3/4 - I see it in several programs, but often it doesn't happen immediately e.g. neverball is fine untill I enter the option screen - then all textures are broken untill I restart the game. On a happier note, ipers is giving the best performance yet - 1168000 (and no problems with textures either). -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r250 and black screen
sÃn, 05,.09.2004 kl. 21.13 -0400, skrev Michel DÃnzer: > On Fri, 2004-09-03 at 17:03 +0200, Luca Zini wrote: > > I have an ati 9000 on a asus a7n8x-x. > > the direct rendering works well, and I can use glxgears, celestia and > > some other application that need it, but a lot of games don't work. > > For example when I try to start tuxracer the screen goes black and I > > can only exit pressing esc. I can listen game's audio, but the video is > > completely black. > > Sounds like https://freedesktop.org/bugzilla/show_bug.cgi?id=982 ? > > Have you tried lower AGP modes? (I wouldn't expect that to make a > difference for a non-lockup though) > For me at least this problem started with xorg 6.7.99.x from cvs, the old XFree86 releases and DRI cvs worked fine. I don't have to do any 3d to have the screen black out, just ctrl-+/- or xrandr -s. Also doing ctrl-+ then ctrl-- doesn't return me to the original mode, I have to keep pushing ctrl-+ or ctrl-- a random number of times, if I run xrandr while doing this it sometimes appears very confused - listing resolutions in wrong order or no order at all. The heat issue Felix mentioned doesn't seem to apply to me as I can run ut2k4 in windowed mode for hours (even if I make the window fullscreen) without problem, but as soon as I try to run fullscreen mode at a different resolution it blacks out. I did a quick diff between radeon_driver.c in dri and xorg cvs but there's been too many changes for me to easily find a suspect since I don't really know that part of the code at all. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to get patch accepted into trunk?
tir, 24,.08.2004 kl. 13.40 -0700, skrev Ian Romanick:
> Ronny V. Vindenes wrote:
>
> > tir, 24,.08.2004 kl. 16.08 +0100, skrev Keith Whitwell:
> >
> >>Has anyone had a chance to try out Philipp's changes? I haven't & don't want
> >>to break the driver by commiting them without a little testing of my own.
> >
> > I haven't tested it yet either, but it struck me that if we're going to
> > add support for "non-essential" software-only extensions then we
> > probably should add a driconf option to enable/disable such extensions
> > since their existence can affect which code paths clients take?
>
> I think this is a good idea for vertex programs *for now*. Once we
> actually generate machine code that runs well from the vertex programs,
> the vertex programs should be enabled by default in all drivers. We're
> just in a funky situation right now where vertex program performance is
> much worse than regular software TCL performance.
>
> Of course, once we get to that point, I think we should get the existing
> TCL paths and run everything as a vertex program. I guess we can cross
> (and debate) that bridge when we come to it...
>
I agree, my concern was that particularly games test for certain
extensions then pick a suitable code path, either because it's
theoretically faster or because it allows more/better eye-candy, under
the assumption that any supported extension is fully accelerated. I
don't know if GL_ARB_vertex_program is actually used like that, it just
happened to make me think (out loud).
I've now briefly tested Philipp's patches on x86-64; didn't see anything
break and the GL_ARB_vertex_program tests in progs/{demos,tests} all
seemed to work.
--
Ronny V. Vindenes <[EMAIL PROTECTED]>
---
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to get patch accepted into trunk?
tir, 24,.08.2004 kl. 16.08 +0100, skrev Keith Whitwell: > Philipp Klaus Krause wrote: > > Some time ago I sent patches that enable vertex program support > > in the r200 driver (software only though) to this list. > > Now I wonder if they will be integrated into the driver and how this > > process works. Do the driver maintainers read this list, lok at the > > patches and decide what they integrate? Will I get any feedback if > > it's accepted or rejected and why? Is this list the right place to send > > patches to (I occassionally see them in some messages, but for > > something as important as the DRI I'd expect there were more patches > > coming in). My own experience is that some patches get feedback, others don't - regardless of whether they are accepted or dropped. For the most part you can get good feedback by attending the weekly IRC meetings. > > Has anyone had a chance to try out Philipp's changes? I haven't & don't want > to break the driver by commiting them without a little testing of my own. > I haven't tested it yet either, but it struck me that if we're going to add support for "non-essential" software-only extensions then we probably should add a driconf option to enable/disable such extensions since their existence can affect which code paths clients take? -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: s3tc: Court Overturns Ban on Posting: No Evidence DeCSS Was a Trade Secret.
lÃr, 05.06.2004 kl. 06.26 skrev Mike Mestnik: > http://www.eff.org/IP/Video/DVDCCA_case/20040227_eff_pr.php > > I found this article amusing, it showes that the DeCSS DVD decryption > computer code is in the public domain and no longer a trade secret. It > dose also say that there will be an appeal. > > I was wondering where we where with the s3tc? The patch and lib are > definatly in the public domain and so far non has had any lawsuits. If I > may be so boald to say it's just a matter of opinion now rather then an > interpitation of law. Just my 2cents. > IANAL, but there are big differences between a trade secret and a patent. The biggest being that patents are given a time limited protection in exchange for being publicly disclosed, while trade secrets remain protected for as long as it remains secret (potentially indefinitely). -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Build & use DRI drivers directly from Mesa
tor, 29.04.2004 kl. 17.07 skrev Ronny V. Vindenes:
> tor, 29.04.2004 kl. 16.45 skrev Keith Whitwell:
> > Keith Whitwell wrote:
> > > Ronny V. Vindenes wrote:
> > >
> > >> 0x002a9579b885 in DoBindContext (dpy=0x5045a0, draw=52428802,
> > >> read=52428802, ctx=0x511070, modes=0x50c4d0, psp=0x50ed40)
> > >> at dri_util.c:480
> > >> 480 DRM_SPINLOCK(&psp->pSAREA->drawable_lock,
> > >> psp->drawLockID);
> > >
> > >
> > > OK, it looks like there might be some x86_64 magic missing to get
> > > spinlocks working...
> >
> > Please try this diff - it will complain if no DRM_CAS is defined, which is one
> > way to cause the infinite loop in DRM_SPINLOCK.
> >
> > Keith
> >
>
> That helped track it down. Using this target instead of the one I posted
> earlier fixes it.
Actually, scratch that. Here's simple patch and a new config.
--
Ronny V. Vindenes <[EMAIL PROTECTED]>
Index: src/mesa/drivers/dri/dri_client/imports/xf86drm.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/dri_client/imports/xf86drm.h,v
retrieving revision 1.1
diff -u -r1.1 xf86drm.h
--- src/mesa/drivers/dri/dri_client/imports/xf86drm.h 14 Apr 2004 12:39:58 - 1.1
+++ src/mesa/drivers/dri/dri_client/imports/xf86drm.h 29 Apr 2004 15:25:48 -
@@ -295,7 +295,7 @@
#define DRM_LOCK_CONT 0x4000 /**< Hardware lock is contended */
#if defined(__GNUC__) && (__GNUC__ >= 2)
-# if defined(__i386) || defined(__AMD64__)
+# if defined(__i386) || defined(__amd64__)
/* Reflect changes here to drmP.h */
#define DRM_CAS(lock,old,new,__ret)\
do { \
# -*-makefile-*-
# Configuration for linux-dri: Linux DRI hardware drivers for XFree86 & others
include $(TOP)/configs/default
CONFIG_NAME = linux-dri-x86-64
# Compiler and flags
CC = gcc
CXX = g++
CFLAGS = -m64 -Wmissing-prototypes -g -std=c99 -Wundef -fPIC -ffast-math
-D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DPTHREADS
-D_GNU_SOURCE -DGLX_DIRECT_RENDERING -I/usr/X11R6/include
-I/usr/X11R6/include/X11/extensions
CXXFLAGS = -m64 -Wall -g -ansi -pedantic -fPIC -D_POSIX_SOURCE
-D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE
#ASM_SOURCES = $(X86_SOURCES)
LIB_DIR = $(TOP)/lib64
# Library/program dependencies
GL_LIB_DEPS = -L/usr/X11R6/lib64 -lX11 -lXext -lm -lpthread -lexpat -ldl
GLUT_LIB_DEPS = -L$(LIB_DIR) -lGLU -lGL -L/usr/X11R6/lib64 -lX11 -lXmu -lXt -lXi -lm
GLW_LIB_DEPS = -L$(LIB_DIR) -lGL -L/usr/X11R6/lib64 -lXt -lXm -lX11
# Directories
SRC_DIRS = mesa glu glut/glx glw
DRIVER_DIRS = dri
PROGRAM_DIRS =
WINDOW_SYSTEM=dri
# ffb & savage missing:
#
DRI_DIRS = dri_client gamma i810 i830 mach64 mga r128 r200 radeon sis tdfx unichrome
[Dri-devel] Re: [Mesa3d-dev] Build & use DRI drivers directly from Mesa
tor, 29.04.2004 kl. 16.45 skrev Keith Whitwell: > Keith Whitwell wrote: > > Ronny V. Vindenes wrote: > > > >> 0x002a9579b885 in DoBindContext (dpy=0x5045a0, draw=52428802, > >> read=52428802, ctx=0x511070, modes=0x50c4d0, psp=0x50ed40) > >> at dri_util.c:480 > >> 480 DRM_SPINLOCK(&psp->pSAREA->drawable_lock, > >> psp->drawLockID); > > > > > > OK, it looks like there might be some x86_64 magic missing to get > > spinlocks working... > > Please try this diff - it will complain if no DRM_CAS is defined, which is one > way to cause the infinite loop in DRM_SPINLOCK. > > Keith > That helped track it down. Using this target instead of the one I posted earlier fixes it. -- Ronny V. Vindenes <[EMAIL PROTECTED]> # -*-makefile-*- # Configuration for linux-dri: Linux DRI hardware drivers for XFree86 & others include $(TOP)/configs/default CONFIG_NAME = linux-dri-x86-64 # Compiler and flags CC = gcc CXX = g++ CFLAGS = -Wmissing-prototypes -g -std=c99 -Wundef -fPIC -ffast-math -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -DPTHREADS -D_GNU_SOURCE -DGLX_DIRECT_RENDERING -I/usr/X11R6/include -I/usr/X11R6/include/X11/extensions -D__AMD64__ CXXFLAGS = -Wall -g -ansi -pedantic -fPIC -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_SVID_SOURCE -D_BSD_SOURCE -D__AMD64__ #ASM_SOURCES = $(X86_SOURCES) LIB_DIR = $(TOP)/lib64 # Library/program dependencies GL_LIB_DEPS = -L/usr/X11R6/lib64 -lX11 -lXext -lm -lpthread -lexpat -ldl GLUT_LIB_DEPS = -L$(LIB_DIR) -lGLU -lGL -L/usr/X11R6/lib64 -lX11 -lXmu -lXt -lXi -lm GLW_LIB_DEPS = -L$(LIB_DIR) -lGL -L/usr/X11R6/lib64 -lXt -lXm -lX11 # Directories SRC_DIRS = mesa glu glut/glx glw DRIVER_DIRS = dri PROGRAM_DIRS = WINDOW_SYSTEM=dri # ffb & savage missing: # DRI_DIRS = dri_client gamma i810 i830 mach64 mga r128 r200 radeon sis tdfx unichrome
[Dri-devel] Re: [Mesa3d-dev] Build & use DRI drivers directly from Mesa
tor, 29.04.2004 kl. 16.19 skrev Keith Whitwell: > Ronny V. Vindenes wrote: > > tor, 29.04.2004 kl. 14.59 skrev Keith Whitwell: > > > > How exactly does glxinfo fail? Do you have a backtrace? It just sucks up cpu cycles and makes no progress. LIBGL_DRIVERS_PATH=~/cvs/freedesktop.org/Mesa/lib64 LIBGL_DEBUG=verbose glxinfo name of display: :0.0 libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0) libGL: OpenDriver: trying /home/rvv/cvs/freedesktop.org/Mesa/lib64/r200_dri.so drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 4, (OK) drmOpenByBusid: drmOpenMinor returns 4 drmOpenByBusid: drmGetBusid reports pci::01:00.0 libGL error: Can't open configuration file /etc/drirc: No such file or directory. libGL error: Can't open configuration file /home/rvv/.drirc: No such file or directory. at which point cpu load goes ~100%. gdb has this to say: 0x002a9579b885 in DoBindContext (dpy=0x5045a0, draw=52428802, read=52428802, ctx=0x511070, modes=0x50c4d0, psp=0x50ed40) at dri_util.c:480 480 DRM_SPINLOCK(&psp->pSAREA->drawable_lock, psp->drawLockID); (gdb) bt #0 0x002a9579b885 in DoBindContext (dpy=0x5045a0, draw=52428802, read=52428802, ctx=0x511070, modes=0x50c4d0, psp=0x50ed40) at dri_util.c:480 #1 0x002a9579b96e in driBindContext3 (dpy=0x5045a0, scrn=0, draw=52428802, read=52428802, ctx=0x511070) at dri_util.c:519 #2 0x003175479b90 in BindContextWrapper (dpy=0x6b7370, gc=0x0, draw=7041424, read=0) at glxext.c:1482 #3 0x003175479ed5 in MakeContextCurrent (dpy=0x5045a0, draw=52428802, read=52428802, gc=0x510910) at glxext.c:1580 #4 0x00401520 in ?? () #5 0x0040237a in ?? () #6 0x003ced91c632 in __libc_start_main () from /lib64/tls/libc.so.6 #7 0x004010ea in ?? () #8 0x007fb7e8 in ?? () #9 0x in ?? () -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Build & use DRI drivers directly from Mesa
tor, 29.04.2004 kl. 14.59 skrev Keith Whitwell:
> I've committed a patch to allow people to build DRI drivers directly in Mesa
> CVS. There are still a couple of gotchas, so I'm going to give some build
> instructions here:
>
> 1) Update your mesa CVS...
>
> 2) Ensure you have a checkout of DRM cvs somewhere.
> 3) Edit /config/linux-dri to set DRM_SOURCE_PATH to point to the DRM
> cvs tree.
>
> 4) In , type: make linux-dri
> -- This should (hopefully) build the *_dri.so files and place them in
> /lib
>
> To use the drivers:
>
> 1) export LIBGL_DRIVERS_PATH=/lib
>
> and then go off and run some demos to check.
>
> I've tested a few things such as quake, tuxracer and the Mesa demos, and all
> seems well. Additionally, I've verified that DRI cvs continues to build.
>
I've tried to use mesa built r200 driver but all programs hang (see
attached strace of glxinfo), and I've noticed there's a big file size
difference between the driver built in dri cvs and in mesa:
Mesa/lib64/r200_dri.so: ELF 64-bit LSB shared object, AMD x86-64,
version 1 (SYSV), not stripped
24430245 apr 29 15:25 Mesa/lib64/r200_dri.so
xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so: ELF 64-bit LSB shared
object, AMD x86-64, version 1 (SYSV), not stripped
15831912 apr 29 15:41 xc/xc/lib/GL/mesa/drivers/dri/r200/r200_dri.so
--
Ronny V. Vindenes <[EMAIL PROTECTED]>
execve("/usr/X11R6/bin/glxinfo", ["glxinfo"], [/* 34 vars */]) = 0
uname({sys="Linux", node="terminal126.gozu.lan", ...}) = 0
brk(0) = 0x504590
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a95556000
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=72953, ...}) = 0
mmap(NULL, 72953, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2a95557000
close(3)= 0
open("/usr/X11R6/lib64/libGLU.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\322"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=532328, ...}) = 0
mmap(0x317560, 1576608, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x317560
mprotect(0, 1056416, PROT_NONE) = -1 ENOMEM (Cannot allocate memory)
mmap(0x317570, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x317570
close(3)= 0
open("/usr/X11R6/lib64/libGL.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300\23C"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=4198586, ...}) = 0
mmap(0x317540, 1919560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x317540
mprotect(0, 1104456, PROT_NONE) = -1 ENOMEM (Cannot allocate memory)
mmap(0x317550, 864256, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x317550
mmap(0x31755d3000, 6728, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x31755d3000
close(3)= 0
open("/usr/X11R6/lib64/libXext.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\3005 \356"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=68304, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a95569000
mmap(0x3cee20, 1113576, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x3cee20
mprotect(0, 1048040, PROT_NONE) = -1 ENOMEM (Cannot allocate memory)
mmap(0x3cee30, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x3cee30
close(3)= 0
open("/usr/X11R6/lib64/libX11.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\222\1"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=901432, ...}) = 0
mmap(0x3cee00, 1947776, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x3cee00
mprotect(0, 1067136, PROT_NONE) = -1 ENOMEM (Cannot allocate memory)
mmap(0x3cee10, 901120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x3cee10
close(3)= 0
open("/lib64/tls/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0V\300\356"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=1114448, ...}) = 0
mmap(0x3ceec0, 1069944, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x3ceec0
mprotect(0, 1004408, PROT_NONE) = -1 ENOMEM (Cannot allocate memory)
mmap(0x3ceed0, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x10) =
0x3ceed0
mmap(0x3ceed02000, 13176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS,
-1, 0) = 0x3ceed02000
close(3)= 0
open("/lib64/tls/libm.so.6&qu
[Dri-devel] Re: [Mesa3d-cvs] CVS Update: Mesa (branch: trunk)
Ian Romanick <[EMAIL PROTECTED]> writes: > CVSROOT: /cvs/mesa > Module name: Mesa > Repository: Mesa/src/mesa/tnl/ > Changes by: [EMAIL PROTECTED] 04/04/12 15:40:55 > > Log message: > Conditionally compile code for x86 specific TNL codegen. This fixes problem > with x86-64 and PowerPC. > > Reported by: sublett on #dri-devel. > Here are the additional patches needed to get dri building on x86-64. The mesa linux-x86-64 config is still broken. Also there are some odd color bugs with r200, some objects turn dark or purple. I see this with simple programs like glxgears, but not in more complex things like UT2004. Index: imports.h === RCS file: /cvs/mesa/Mesa/src/mesa/main/imports.h,v retrieving revision 1.34 diff -u -r1.34 imports.h --- imports.h 11 Apr 2004 22:22:23 - 1.34 +++ imports.h 13 Apr 2004 09:46:57 - @@ -222,7 +222,7 @@ *** USE_IEEE: Determine if we're using IEEE floating point ***/ #if defined(__i386__) || defined(__386__) || defined(__sparc__) || \ -defined(__s390x__) || defined(__powerpc__) || \ +defined(__s390x__) || defined(__powerpc__) || defined(__AMD64__) || \ ( defined(__alpha__) && ( defined(__IEEE_FLOAT) || !defined(VMS) ) ) #define USE_IEEE #define IEEE_ONE 0x3f80 Index: host.def === RCS file: /cvs/dri/xc/xc/config/cf/host.def,v retrieving revision 1.67 diff -u -r1.67 host.def --- host.def 9 Apr 2004 00:18:44 - 1.67 +++ host.def 13 Apr 2004 11:17:17 - @@ -38,6 +38,11 @@ #define XF86CardDrivers tdfx i810 mga ati glint vga sis #define DriDrivers r200 mga i810 r128 radeon gamma i830 sis tdfx ffb +#elif defined(AMD64Architecture) + +#define XF86CardDrivers tdfx i810 mga ati glint vga sis +#define DriDrivers r200 mga i810 r128 radeon gamma i830 sis tdfx + #else #define XF86CardDrivers tdfx mga ati glint vga @@ -66,7 +71,7 @@ * expat. */ -#if defined(LinuxArchitecture) +#if defined(LinuxArchitecture) && !defined(AMD64Architecture) # define ExpatLibrary StaticLibrary($(BUILDLIBDIR),expat) # define NormalLibExpat YES #endif Index: Imakefile.inc === RCS file: /cvs/dri/xc/xc/lib/GL/mesa/tnl/Imakefile.inc,v retrieving revision 1.5 diff -u -r1.5 Imakefile.inc --- Imakefile.inc 30 Mar 2004 00:22:49 - 1.5 +++ Imakefile.inc 13 Apr 2004 12:44:32 - @@ -76,7 +76,6 @@ #if defined(i386Architecture) && MesaUseX86Asm #define MesaTnlAsmObjs $(MESATNLBUILDDIR)t_vtx_x86.o \ $(MESATNLBUILDDIR)t_vtx_x86_gcc.o -#endif MESA_TNL_OBJS = $(MESATNLBUILDDIR)t_array_api.o \ $(MESATNLBUILDDIR)t_array_import.o \ @@ -100,6 +99,29 @@ $(MESATNLBUILDDIR)t_vtx_exec.o \ MesaTnlAsmObjs \ $(MESATNLBUILDDIR)t_vtx_generic.o +#else + MESA_TNL_OBJS = $(MESATNLBUILDDIR)t_array_api.o \ + $(MESATNLBUILDDIR)t_array_import.o \ + $(MESATNLBUILDDIR)t_context.o \ + $(MESATNLBUILDDIR)t_pipeline.o \ + $(MESATNLBUILDDIR)t_save_api.o \ + $(MESATNLBUILDDIR)t_save_loopback.o \ + $(MESATNLBUILDDIR)t_save_playback.o \ + $(MESATNLBUILDDIR)t_vb_fog.o \ + $(MESATNLBUILDDIR)t_vb_light.o \ + $(MESATNLBUILDDIR)t_vb_normals.o \ + $(MESATNLBUILDDIR)t_vb_points.o \ + $(MESATNLBUILDDIR)t_vb_program.o \ + $(MESATNLBUILDDIR)t_vb_render.o \ + $(MESATNLBUILDDIR)t_vb_texgen.o \ + $(MESATNLBUILDDIR)t_vb_texmat.o \ + $(MESATNLBUILDDIR)t_vb_vertex.o \ + $(MESATNLBUILDDIR)t_vertex.o \ + $(MESATNLBUILDDIR)t_vtx_api.o \ + $(MESATNLBUILDDIR)t_vtx_eval.o \ + $(MESATNLBUILDDIR)t_vtx_exec.o \ + $(MESATNLBUILDDIR)t_vtx_generic.o +#endif #if defined(DoSharedLib) && DoSharedLib #if defined(i386Architecture) && MesaUseX86Asm -- Ronny V. Vindenes <[EMAIL PROTECTED]>
Re: [Dri-devel] r200 new "revolutionary" lighting
On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote: > Hello again > > now that the lighting bugs are finally mostly gone, I've just gone ahead > and changed the lighting code a bit more... (patch against cvs, without > the earlier colormat fix). > This patch causes the driver to no longer use the PREMULT lighting, > instead it will use the SOURCE_MATERIAL stuff. Looking at r200_reg.h it > looked to me like the chip can handle a lot what is currently done in > software. So I changed that ;-) > What's new: > - no more bazillion calls of update_light_colors with lots of color > multiplications, since the chip handles that now itself. > - two-side-lighting with different materials no longer causes a tcl > fallback (so samples/fog now runs correctly, of course if you use > tcl_mode=0 it is still hosed - it looks like the tcl fallback if both > fog and two-side lighting are enabled is broken on both radeon and r200, > but that's another topic. It was the starting point for this patch > however, but I was unable to figure out what's wrong with the fallback. > The tnl stuff is scary :-(). > - removed the strange fallback if materials between begin / end were > discovered. Couldn't figure out why it was there (the comment said the > chip handles it just fine?), I thought maybe because material changes > caused for instance lighting updates, which now no longer happens. Well > so far it didn't lock up... > > There are some things I'm unsure about. For one, the > update_global_ambient now has an impossible if condition, but I have no > idea if the function works correctly now or not - it could also work > better than before, who knows ;-). There's also a lot of guesswork > involved, but at first glance things seemed to look quite good - the > patch passes the nwn and glxgears test ;-) (and some others too, but > didn't test extensively yet). > > Maybe I missed something important and this lighting code fails in some > cases horribly, but if not I think this lighting code would be much > nicer (it should likely also help TNL performance quite a bit, unless > you run on a P5 10Ghz). The code is also quite a bit simpler than before > IMHO, most of the code is just two large copy/paste if statements. > > Comments? OK, I've spent a few hours playing with the updated patch today, and all I can say is: Good work! It fixes lighting and fog issues in many cases (including one program that segfaults without it). Also, in most the programs I've tested there are small performance improvements* (~5 fps), but the most noticable improvement (other than visual issues) is that cpu load is much lower now, especially in combination with wine. I haven't found any regressions, and unless someone finds some big error, I think this should be merged asap. My setup is Athlon64 3200, 1gb ram and radeon 9000 128mb running linux 2.6.2-rc2-mm2. Programs tested include ET, UT, Postal 2, NWN, Quake 3, Civ 3 (wine) and tons of OpenGL (native and wine) and Direct3D demos. * Notable exception being nwn which is still just as slow, but atleast it looks correct now. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 new "revolutionary" lighting
On Sat, 2004-01-31 at 03:30, Roland Scheidegger wrote: > Hello again > > now that the lighting bugs are finally mostly gone, I've just gone ahead > and changed the lighting code a bit more... (patch against cvs, without > the earlier colormat fix). patching file r200_state.c Hunk #2 succeeded at 810 with fuzz 1. Hunk #3 FAILED at 820. 1 out of 9 hunks FAILED -- saving rejects to file r200_state.c.rej patching file r200_state_init.c Sounds good on paper though :) -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Migrated i830 driver to t_vertex.[ch]
On Mon, 2004-01-19 at 11:49, Keith Whitwell wrote: > I've just committed a change to move the i830 driver to the new t_vertex.[ch] > mechanism for specifying and emitting hardware vertices. > I had to apply this patch against dri cvs to get it compiling again. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- Imakefile.inc.orig 2004-01-19 23:23:27.559064075 +0100 +++ Imakefile.inc 2004-01-19 23:24:46.963724565 +0100 @@ -46,8 +46,7 @@ $(MESADRVI830BUILDDIR)i830_tex.c \ $(MESADRVI830BUILDDIR)i830_texmem.c \ $(MESADRVI830BUILDDIR)i830_texstate.c \ - $(MESADRVI830BUILDDIR)i830_tris.c \ - $(MESADRVI830BUILDDIR)i830_vb.c + $(MESADRVI830BUILDDIR)i830_tris.c I830OBJS = $(MESADRVI830BUILDDIR)i830_context.o \ $(MESADRVI830BUILDDIR)i830_debug.o \ @@ -59,8 +58,7 @@ $(MESADRVI830BUILDDIR)i830_tex.o \ $(MESADRVI830BUILDDIR)i830_texmem.o \ $(MESADRVI830BUILDDIR)i830_texstate.o \ - $(MESADRVI830BUILDDIR)i830_tris.o \ - $(MESADRVI830BUILDDIR)i830_vb.o + $(MESADRVI830BUILDDIR)i830_tris.o I830UOBJS = $(MESADRVI830BUILDDIR)unshared/i830_context.o \ $(MESADRVI830BUILDDIR)unshared/i830_debug.o \ @@ -72,8 +70,7 @@ $(MESADRVI830BUILDDIR)unshared/i830_tex.o \ $(MESADRVI830BUILDDIR)unshared/i830_texmem.o \ $(MESADRVI830BUILDDIR)unshared/i830_texstate.o \ - $(MESADRVI830BUILDDIR)unshared/i830_tris.o \ - $(MESADRVI830BUILDDIR)unshared/i830_vb.o + $(MESADRVI830BUILDDIR)unshared/i830_tris.o I830DOBJS = $(MESADRVI830BUILDDIR)debugger/i830_context.o \ $(MESADRVI830BUILDDIR)debugger/i830_debug.o \ @@ -85,8 +82,7 @@ $(MESADRVI830BUILDDIR)debugger/i830_tex.o \ $(MESADRVI830BUILDDIR)debugger/i830_texmem.o \ $(MESADRVI830BUILDDIR)debugger/i830_texstate.o \ - $(MESADRVI830BUILDDIR)debugger/i830_tris.o \ - $(MESADRVI830BUILDDIR)debugger/i830_vb.o + $(MESADRVI830BUILDDIR)debugger/i830_tris.o I830POBJS = $(MESADRVI830BUILDDIR)profiled/i830_context.o \ $(MESADRVI830BUILDDIR)profiled/i830_debug.o \ @@ -98,8 +94,7 @@ $(MESADRVI830BUILDDIR)profiled/i830_tex.o \ $(MESADRVI830BUILDDIR)profiled/i830_texmem.o \ $(MESADRVI830BUILDDIR)profiled/i830_texstate.o \ - $(MESADRVI830BUILDDIR)profiled/i830_tris.o \ - $(MESADRVI830BUILDDIR)profiled/i830_vb.o + $(MESADRVI830BUILDDIR)profiled/i830_tris.o #ifdef NeedToLinkMesaSrc LinkSourceFile(i830_3d_reg.h, $(MESADRVSRCDIR)/i830) @@ -122,6 +117,4 @@ LinkSourceFile(i830_texstate.c, $(MESADRVSRCDIR)/i830) LinkSourceFile(i830_tris.c, $(MESADRVSRCDIR)/i830) LinkSourceFile(i830_tris.h, $(MESADRVSRCDIR)/i830) -LinkSourceFile(i830_vb.c, $(MESADRVSRCDIR)/i830) -LinkSourceFile(i830_vb.h, $(MESADRVSRCDIR)/i830) #endif
Re: [Dri-devel] Strange lockups with DRI on Radeon 8500LE
On Sun, 2003-12-21 at 14:55, Konstantin Lepikhov wrote: > Hi! > > After upgrading my box to latest trunk DRI, I got strange problem - > XServer did not start correctly, e.g. it hangs after init dri stuff. But I > can ssh to this box, and SysRq keys are working and I can > sync/umount/reboot. If I comment Load "dri"/remove radeon.o module - all > works fine except DRI =) So what it can be? Problems with build/my hands > or is a problem with videocard? FYI, fglrx drivers works fine. > > PS Seeking archives of this list, I don't find anything related my problem, > and this looks strange because my videocard isn't very exotic :-/ > Try disabling AGPFastWrite, this option work fine on some systems and not at all on others. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] 2.6.0 problems.
On Thu, 2003-12-18 at 15:12, Adam K Kirchhoff wrote: > So I decided to give 2.6.0 a shot this morning :-) > > My Radeon 8500 (which previous worked with 2.4.22) refuses to enable > direct rendering: > > (WW) RADEON(0): [agp] AGP not available > (II) RADEON(0): [drm] removed 1 reserved context for kernel > (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xe0882000 at 0x48267000 > (WW) RADEON(0): DRI forced on with virtual screen of greater than 2048. > > (II) RADEON(0): Direct rendering disabled > > agpgart *is* loaded (though unused). > > $ dmesg | grep agpgart > Linux agpgart interface v0.100 (c) Dave Jones > > Is this definately an AGP issue that I should e-mail Dave Jones about? > Under 2.6 you need to load both agpgart and the chipset specific agp module (like via-agp, intel-agp, amd64-agp and others) -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Build fails
On Tue, 2003-12-09 at 23:26, Felix KÃhling wrote: > Hi, > > I tried to compile the new dri trunk on freedesktop.org now. I checked > out Mesa-newtree and set the MesaSrcDir correctly in host.def and ran > make World. These are the last few lines of make output: > I don't have time to look into it now. I'll get back to it tomorrow and > look into it myself if it isn't fixed by then. > I checked out and compiled dri trunk + Mesa-newtree successfully a couple of hours ago. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] What's up with dri.freedesktop.org? "Connection timed out"
On Fri, 2003-11-28 at 18:44, Keith Whitwell wrote: > Dieter NÃtzel wrote: > > for several hours, now. > > > > ri-trunk/xc> cvs update > > cvs [update aborted]: connect to dri.freedesktop.org(131.252.208.82):2401 > > failed: Connection timed out > > dri-trunk/xc> ping dri.freedesktop.org > > PING dri.freedesktop.org (131.252.208.82) 56(84) bytes of data. > > > > Seems down from here too. Being thanksgiving, I don't know when it will come > back up... I'm also not sure exactly who's responsible for the box, hence the > shotgun cc list... > > Keith > From: Keith Packard <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Keith Packard <[EMAIL PROTECTED]> Subject: Freedesktop server will be unavailable 0600-0800 PST Nov 27 Date: Fri, 28 Nov 2003 00:33:02 -0800 PSU (our fine hosting provider) is replacing the giant UPS serving the machine room where the freedesktop.org server is mounted. This will cause the machine to be off-line for a few hours tomorrow morning, and then again for a few hours on Saturday evening. I recommend a few hours visit to the big room with the wet gray ceiling during this period; we shouldn't have another opportunity like this for several years if all goes well :-) -keith -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AMD 64 AGP Patch (Was Re: [Dri-devel] r200 in cvs broken?)
On Wed, 2003-11-19 at 20:46, Dave Jones wrote:
> On Wed, Nov 19, 2003 at 11:44:42AM -0800, James Jones wrote:
> > >
> > >
> > > hammers[i++] = loop_dev;
> > > nr_garts = i;
> > >#ifdef CONFIG_SMP
> > > if (i == MAX_HAMMER_GARTS) {
> > > printk(KERN_INFO PFX "Too many northbridges for AGP\n");
> > > return -1;
> > > }
> > >
> >
> > Seems wrong to me... wouldn't this return -1 if say, MAX_HAMMER_GARTS ==
> > 1 and 1 gart was found ( nr_garts == i == 1 when the comparison is made
> > ). It would need to be:
>
> MAX_HAMMER_GARTS can only be 1 if CONFIG_SMP=n, so the above code
> is skipped, and we fall through, and return 0.
>
> > This would also be wrong, as the test would be too late, and hammer[]
> > would be overflowed by the time the test is performed. This is why the
> > test was moved before the assignment in our patches. The way we did it
> > would handle the SMP and non-smp cases I believe, the code you quoted
> > would only work right in the uniproc case.
>
> That's how it should be.
>
> If we have a UP system, with UP kernel, we just return 0 after
> finding the first GART
>
> If we have a UP system with an SMP kernel, we find the first GART,
> and eventually end up returning 0 after finding no further garts.
>
> If we have an SMP system with UP kernel, we exit early after
> finding the first GART. The 2nd (And above) GARTs are irrelevant
> when not running in SMP.
Agreed.
>
> If we have an SMP system with an SMP kernel, we add however many
> GARTs to the table, up to a limit of MAX_HAMMER_GARTS.
>
It looks like you'll add GARTS up to MAX_HAMMER_GARTS-1 then bomb if
there is an MAX_HAMMER_GARTS'th GART.
--
Ronny V. Vindenes <[EMAIL PROTECTED]>
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Tue, 2003-11-18 at 18:55, Dave Jones wrote:
> On Fri, Oct 31, 2003 at 11:46:54AM -0800, James Jones wrote:
> > test8 had broken detection for this agp chipset. You have to edit a
> > file in the x86_64 arch directory to get it to allow more than 0
> > (assuming you configed for uniprocessor) bridges to be used, as it
> > checks a variable after incrementing rather than before. I also found
> > the check wasn't even getting compiled in as the CONFIG_ define had a
> > different name in the arch file than in amd64-agp.c, and only one of
> > these matched the actual config define name.
> >
> > Haven't tried test9 yet, I sent a patch to dave jones after I noticed
> > this in test7, but I received no response.
>
> I don't recall seeing this mail. Bounce me another copy?
Don't know about the CONFIG_ define problem on x86-64, but this fixes it
for x86.
--
Ronny V. Vindenes <[EMAIL PROTECTED]>
--- linux-2.6.0-test8/drivers/char/agp/amd64-agp.c.orig 2003-11-18 22:09:13.0 +0100
+++ linux-2.6.0-test8/drivers/char/agp/amd64-agp.c 2003-11-18 22:14:23.0 +0100
@@ -355,12 +355,12 @@
#endif
return -1;
}
- hammers[i++] = loop_dev;
- nr_garts = i;
if (i == MAX_HAMMER_GARTS) {
printk(KERN_INFO PFX "Too many northbridges for AGP\n");
return -1;
}
+ hammers[i++] = loop_dev;
+ nr_garts = i;
}
return i == 0 ? -1 : 0;
}
Re: [Dri-devel] Problems with the radeon 1.9.0 driver in 2.6.0-test9-mm2
On Wed, 2003-11-05 at 23:44, Michel DÃnzer wrote:
> > > > There's a patch in -mm2 that does something with drm/agp (haven't looked
> > > > at it yet):
> > > >
> > > > +drm-agp-module-dependency-fix.patch
> > > >
> > > > Maybe fix DRM<->AGP module dependencies so things autoload nicely.
>
> BTW, I believe this is Andrew's description of what the patch is
> supposed to do, not a suggestion of Ronny's.
>
> -#define DRM_AGP_GET (drm_agp_t *)inter_module_get("drm_agp")
> -#define DRM_AGP_PUT inter_module_put("drm_agp")
> +#define DRM_AGP_GET symbol_get(agp_drm)
> +#define DRM_AGP_PUT symbol_put(agp_drm)
>
> I wonder if 'drm_agp' was intentionally changed to 'agp_drm'... is there
> an accompanying agpgart patch? If not, can you try with
> symbol_{get,put}(drm_agp) ?
you can see the full patch at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.0-test9/2.6.0-test9-mm2/broken-out/drm-agp-module-dependency-fix.patch
and it does appear to be a typo/misc silliness.
Here's a patch against -mm2 that makes dri work again.
http://www.lstud.ii.uib.no/~s864/kernel/drm-agp-module-dependency-fix2.patch
--
Ronny V. Vindenes <[EMAIL PROTECTED]>
diff -bBpur fix/drivers/char/drm/drm_agpsupport.h linux-2.6.0-test9-mm2/drivers/char/drm/drm_agpsupport.h
--- fix/drivers/char/drm/drm_agpsupport.h 2003-11-06 00:49:53.299160210 +0100
+++ linux-2.6.0-test9-mm2/drivers/char/drm/drm_agpsupport.h 2003-11-06 00:27:43.0 +0100
@@ -37,8 +37,8 @@
#if __REALLY_HAVE_AGP
-#define DRM_AGP_GET symbol_get(agp_drm)
-#define DRM_AGP_PUT symbol_put(agp_drm)
+#define DRM_AGP_GET symbol_get(drm_agp)
+#define DRM_AGP_PUT symbol_put(drm_agp)
/**
* Pointer to the drm_agp_t structure made available by the agpgart module.
diff -bBpur fix/include/linux/agp_backend.h linux-2.6.0-test9-mm2/include/linux/agp_backend.h
--- fix/include/linux/agp_backend.h 2003-11-06 00:50:03.247046605 +0100
+++ linux-2.6.0-test9-mm2/include/linux/agp_backend.h 2003-11-06 00:42:38.936727765 +0100
@@ -108,8 +108,7 @@ typedef struct {
int (*copy_info)(struct agp_kern_info *);
} drm_agp_t;
-/* Used by drm. */
-extern const drm_agp_t agp_drm;
+extern const drm_agp_t *drm_agp_p;
#endif/* __KERNEL__ */
#endif/* _AGP_BACKEND_H */
Re: [Dri-devel] Problems with the radeon 1.9.0 driver in 2.6.0-test9-mm2
On Wed, 2003-11-05 at 10:33, Bradley Chapman wrote: > I'm having problems using te DRI radeon driver in the 2.6.0-test9-mm2 > kernel tree. When X is started, the kernel outputs these messages: > > [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held > [drm:radeon_unlock] *ERROR* Process 1083 using kernel context 0 > > The driver did not do this under 2.6.0-test9-mm1. I see the same thing using dri cvs (both with 1.9.0 radeon (kernel) and 1.10.0 (dri cvs)) with 2.6.9-test9-mm2, plain -test9 works. [drm] Initialized radeon 1.10.0 20020828 on minor 0: ATI Radeon If R250 9000 [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held [drm:radeon_unlock] *ERROR* Process 2073 using kernel context 0 There's a patch in -mm2 that does something with drm/agp (haven't looked at it yet): +drm-agp-module-dependency-fix.patch Maybe fix DRM<->AGP module dependencies so things autoload nicely. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Tue, 2003-11-04 at 03:28, Michel DÃnzer wrote: > On Thu, 2003-10-30 at 11:43, Ronny V. Vindenes wrote: > > > > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > > (EE) RADEON(0): GetBuffer timed out, resetting engine... > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > > This particular problem should be fixed in current CVS. > > Funny that the rest started working again for you though (right?), I > didn't notice any related changes... Only thing I can think of was that I added the BusType AGP option (which had no effect on the non-cvs version). -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
FIXED [was: Re: [Dri-devel] r200 in cvs broken?]
On Fri, 2003-10-31 at 01:54, Ronny V. Vindenes wrote: > On Fri, 2003-10-31 at 00:43, Roland Scheidegger wrote: > > Ronny V. Vindenes wrote: > > > Something in the last week or two broke the r200 driver. After I cvs > > > update'ed and recompiled yesterday, I get this error: > > > > > > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > > > (EE) RADEON(0): GetBuffer timed out, resetting engine... > > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > > > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > > > > > > and it gets stuck there repeating the error over and over (the first > > > time it happened the log grew to almost 800mb before I noticed that > > > something was wrong). > > > > > > Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything > > > works as normal, and if I then reinstall cvs version it works until the > > > next cold boot. I'm guessing something isn't being initialized correctly > > > in current cvs. > > > > > > Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure > > > 32bit mode) with an lcd connected to dvi. > > > > > > The (cut down) log is here: > > > http://www.lstud.ii.uib.no/~s864/XFree86.0.log > > > > From the log, the card gets detected as a PCI card, but from the bus id > > I'd say it's a AGP card, is that true? In that case, it looks like the > > test for AGP/PCI doesn't work correctly. > > It is an AGP card, but the amd64-agp module in 2.6.0-test9 doesn't > detect the VIA K8T800 chipset [1] (agpgart in 2.4.23-pre9 does detect > it, but XFree86 still defaults to pcigart [2]). > > > In radeon_driver.c, it says "Following detection method works for all > > cards tested so far." Guess your card is the first it doesn't :-( > > If that's the case, you can try to get it to work with "BusType" "AGP" > > in the XF86Config file. > > Though I'd have assumed that a AGP card detected as PCI should still work. > > Setting "BusType" "AGP" makes no difference. > > Just to clarify, it is detected as PCI when using older working also. > > [1] I can get it to load by some hand tweaking of some of the tests in > the module, but it still works no better than 2.4.23-pre9. > > [2] Someone with the same motherboard is seeing the same problem with agp > not working: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107805 Yesterday's patches in cvs not only fixed the CP errors, they also fixed my AGP issues. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Fri, 2003-10-31 at 00:43, Roland Scheidegger wrote: > Ronny V. Vindenes wrote: > > Something in the last week or two broke the r200 driver. After I cvs > > update'ed and recompiled yesterday, I get this error: > > > > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > > (EE) RADEON(0): GetBuffer timed out, resetting engine... > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > > > > and it gets stuck there repeating the error over and over (the first > > time it happened the log grew to almost 800mb before I noticed that > > something was wrong). > > > > Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything > > works as normal, and if I then reinstall cvs version it works until the > > next cold boot. I'm guessing something isn't being initialized correctly > > in current cvs. > > > > Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure > > 32bit mode) with an lcd connected to dvi. > > > > The (cut down) log is here: > > http://www.lstud.ii.uib.no/~s864/XFree86.0.log > > From the log, the card gets detected as a PCI card, but from the bus id > I'd say it's a AGP card, is that true? In that case, it looks like the > test for AGP/PCI doesn't work correctly. It is an AGP card, but the amd64-agp module in 2.6.0-test9 doesn't detect the VIA K8T800 chipset [1] (agpgart in 2.4.23-pre9 does detect it, but XFree86 still defaults to pcigart [2]). > In radeon_driver.c, it says "Following detection method works for all > cards tested so far." Guess your card is the first it doesn't :-( > If that's the case, you can try to get it to work with "BusType" "AGP" > in the XF86Config file. > Though I'd have assumed that a AGP card detected as PCI should still work. Setting "BusType" "AGP" makes no difference. Just to clarify, it is detected as PCI when using older working also. [1] I can get it to load by some hand tweaking of some of the tests in the module, but it still works no better than 2.4.23-pre9. [2] Someone with the same motherboard is seeing the same problem with agp not working: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107805 -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] r200 in cvs broken?
On Thu, 2003-10-30 at 12:03, Keith Whitwell wrote: > Ronny V. Vindenes wrote: > > Something in the last week or two broke the r200 driver. After I cvs > > update'ed and recompiled yesterday, I get this error: > > > > (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 > > (EE) RADEON(0): GetBuffer timed out, resetting engine... > > (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 > > (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 > > > > and it gets stuck there repeating the error over and over (the first > > time it happened the log grew to almost 800mb before I noticed that > > something was wrong). > > > > > > The (cut down) log is here: > > http://www.lstud.ii.uib.no/~s864/XFree86.0.log > > If you can track this down to an individual change, it will help a lot in > terms of getting it resolved. OK, I'll take a closer look during the weekend. -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] r200 in cvs broken?
Something in the last week or two broke the r200 driver. After I cvs update'ed and recompiled yesterday, I get this error: (EE) RADEON(0): RADEONCPGetBuffer: CP GetBuffer -1020 (EE) RADEON(0): GetBuffer timed out, resetting engine... (EE) RADEON(0): RADEONCPGetBuffer: CP reset -1020 (EE) RADEON(0): RADEONCPGetBuffer: CP start -1020 and it gets stuck there repeating the error over and over (the first time it happened the log grew to almost 800mb before I noticed that something was wrong). Reverting to XFree86 Version 4.3.0 (Fedora Core 1: 4.3.0-42), everything works as normal, and if I then reinstall cvs version it works until the next cold boot. I'm guessing something isn't being initialized correctly in current cvs. Card is 9000/128mb under linux 2.6.0-test9 (athlon64 running in pure 32bit mode) with an lcd connected to dvi. The (cut down) log is here: http://www.lstud.ii.uib.no/~s864/XFree86.0.log -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] UT2k3 again
On Tue, 2003-09-16 at 06:42, Daniel Vogel wrote: > FWIW, a G450 is below minimum system requirements and I'm curious to hear > how well cards like the Radeon 8500, which currently is the fastest DRI > accelerated card out there if I'm not mistaken, handle running the game. I've tried the demo (ut2003demo-lnx-2206.sh.bin) with a radeon 9000 using XFree86-4.3.0-24 (redhat rawhide from a week ago or so) without much luck. Graphics was severly corrupted and the game crashed after a few seconds. Setting R200_NO_TCL gave slightly different corruptions, but the game still crashed. I then tried dri cvs from freedesktop.org, and it worked 100%, no corruptions and didn't crash, it was however slightly slower than in win98. I didn't try to tweak any of the settings so it's possible it can run even better. Except for NWN, which didn't work at all good (lighting was all screwed up), all the games & opengl programs I tried with cvs had noticable performance improvements (in particular Enemy Territory went from barely playable to on-par with win98). Test system was duron 1.3ghz 512mb ram running 2.6.0-test4-mm5. I just have to say that 2.6.0-test + mm patches is an amazing desktop kernel. I compiled dri from cvs and a new kernel at the same time, while also using tvtime to watch tv and emacs (gnus) to read news, and evolution, epiphany, x-chat & rhythmbox was running in the background, and the box remained as responsive as it was without the load! -- Ronny V. Vindenes <[EMAIL PROTECTED]> --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
