[Dri-devel] Re: [Dri-users] Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
On Mon, 8 Mar 2004 15:19:32 -0500 (EST) John H. [EMAIL PROTECTED] wrote: well, your suggestion at least makes the speed ok with 800x600(which isn't that great) however, the rainbow color thing is making it unplayable(I can't distinguish between players). is there any way around that? I just remembered that I saw a similar problem on my Radeon 7500 that seemed to be related to AGP texturing. With a normal radeon the workaround is to disable AGP textures using an environment variable. However, with an IGP chip you don't have that choice. Can anyone look into the AGP texturing issues in the radeon driver? Regards, Felix --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
On Wed, 2004-03-10 at 12:24, Felix Khling wrote: On Mon, 8 Mar 2004 15:19:32 -0500 (EST) John H. [EMAIL PROTECTED] wrote: well, your suggestion at least makes the speed ok with 800x600(which isn't that great) however, the rainbow color thing is making it unplayable(I can't distinguish between players). is there any way around that? I just remembered that I saw a similar problem on my Radeon 7500 that seemed to be related to AGP texturing. With a normal radeon the workaround is to disable AGP textures using an environment variable. Namely RADEON_GARTTEXTURING_FORCE_DISABLE. However, with an IGP chip you don't have that choice. Yes, you do. Framebuffer and GART are still separate, even if both lie in system RAM. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mesa Linux solo and r100..
--- Dave Airlie [EMAIL PROTECTED] wrote: Hi, I've just tried getting a solo Mesa working on 2.4.25, latest DRM from DRI CVS and top of tree Mesa on r100, my framebuffer console comes up, but when I start the server the screen is corrupted, when I run the test app I can see the garbage on screen change so it looks close to working, Does anyone have this working? on any card, I might try porting the i810 or mach64 to Solo over the next couple of days as an additional test but I'd like to see a working one first.. Dave, You might try on the directfb ML's: http://www.directfb.org Alex Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Radeon Snapshots
--- Fritsch [EMAIL PROTECTED] wrote: I am using Radeon Snapshots on an IBM Thinkpad together with the XFree86 binary. All Version from before 20040302 work fine, with later Versions I get faults in glxgears, which refuses running! Does anyone experience same problems? It might be an issue with Ian's new driinterface. I think it was merged into the trunk around then. I'm CCing devel. Alex thx Peter Frühberger __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Mesa3d-dev] Deviation from spec WRT multitex and interleavedarrays
Robert F Merrill wrote: After reading the GL 1.2.1 spec which supposedly contains a verbatim copy of the ARB_multitexture spec, It seems to me as if Mesa's implementation of InterleavedArrays is incorrect. Currently, specifying an interleaved array with a texcoord part assigns the texcoords to TMU 0 and disables GL_TEXTURE_COORD_ARRAY for all others Specifying an interleaved array without a texcoord part disables GL_TEXTURE_COORD_ARRAY for all TMUs Reading the ARB_multitexture / 1.2.1 spec, it appears to me that the correct behavior is: 1) If texcoord is specified in the interleaved array, assign the texcoords to the current client TMU and enable GL_TEXTURE_COORD_ARRAY in same 2) otherwise, disable GL_TEXTURE_COORD_ARRAY in the current client TMU The support for this is given in the interleaved arrays section of the spec, which says that a call to interleaved arrays is equivalent to a given code block. In that code block, there are no calls to ClientActiveTextureARB, and the multitexture spec doesn't change this either. Therefore, we can't touch anything other than the current TMU since the equivalent code doesn't either. Also, current behavior doesn't really make sense Here is a patch that should give correct behavior: I was looking at this a while back myself, but forgot to revisit it. I think you're right. The OpenGL SI is consistant with the spec too so I'll go ahead and apply your patch. Thanks! -Brian --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
so what do i do? --- On Wed 03/10, Michel =?ISO-8859-1?Q?D=E4nzer?= [EMAIL PROTECTED] wrote: From: Michel =?ISO-8859-1?Q?D=E4nzer?= [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 10 Mar 2004 13:18:20 +0100 Subject: Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems) On Wed, 2004-03-10 at 12:24, Felix Kühling wrote:br On Mon, 8 Mar 2004 15:19:32 -0500 (EST)br John H. [EMAIL PROTECTED] wrote:br br well, your suggestion at least makes the speed ok with 800x600(which isn't that great)br br however, the rainbow color thing is making it unplayable(I can't distinguish between players). is there any way around that?br br I just remembered that I saw a similar problem on my Radeon 7500 thatbr seemed to be related to AGP texturing. With a normal radeon thebr workaround is to disable AGP textures using an environment variable.brbrNamely RADEON_GARTTEXTURING_FORCE_DISABLE.brbr However, with an IGP chip you don't have that choice.brbrYes, you do. Framebuffer and GART are still separate, even if both liebrin system RAM.brbrbr-- brEarthling Michel Dänzer | Debian (powerpc), X and DRI developerbrLibre software enthusiast| http://svcs.affero.net/rm.php?r=daenzerbrbr ___ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
My apologies for being horribly slow to respond. The mode switching problem occurs with bpp=24 (bpp=32 didn't work at all for me). Hardware is SuperSavage/IXC SDR (ThinkPad T23). I do get the message: (==) SAVAGE(0): Using video BIOS to set modes But I get this regardless of whether I have the UseBIOS option set or not in XF86Config. At this point the display always seems to be corrupted (bad mode) if I select 24 bpp (before it worked fine until I started tuxracer). The corrupted display shows the right colors, but the pixel arrangement is off. What should be the vertical left/right border of the screen is actually at a 30 degree angle to the horizontal, wrapping around from left to right (goes down and to the right). Moving the mouse down makes the pixels representing the pointer go down and to the right. Moving the mouse to the right makes them go up and to the right. I have also noticed a problem with loading the kernel driver. Even after I added: /sbin/modprobe agpgart /sbin/modprobe savage to /etc/rc.d/rc.local, the X server did not start with DRI enabled. The reason seems to be that some time is needed between the 'modprobe agpgart' and the 'modprobe savage'. Changing rc.local to: /sbin/modprobe agpgart sleep 1 /sbin/modprobe savage sleep 1 Solved the problem and now I get the message kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: SuperSavage IX/C SDR on bootup. HOWEVER, I noticed general system instability (random lockups) when operating in the original case, that is when both agpgart.o and savage.o were loaded, but savage not properly initialized. Thanks, Steve On Fri, 2004-02-27 at 15:21, Alex Deucher wrote: -- Felix Khling [EMAIL PROTECTED] wrote: Forwarding to dri-devel. Some of this (mode switching problem) looks like a 2D issue. Alex? I'll have to double check, but I don't recall having any problems with mode switching in tuxracer last time I played with it. Steve, what chip are you running on? bios or non-bios mode setting? it also might be an issue with the backbuffer overwriting the front buffer. see below. I don't know why drawpix to the backbuffer works for me but not for you. I'll look into this some time. But it's no priority right now. Hmm, I was just wondering if you have enough memory for 3D in 32bpp mode with 1400x1050. Front, back and depth buffers need a bit more than 16 MB in this mode. If your chip uses shared memory you'd have to reserve 32MB of shared memory for it to work. One of these days, maybe this weekend, I'll put a quick check in the buffer allocation code in savage_accel.c to make sure there is enough memory for 3D in the current mode/depth. OT I haven't really been testing the trunk to much lately, as I've been messing around with duoview support. I've just about got it working. I can set up the second controller and dot clock, I just can't get it to produce a signal. it's driving me nuts.../OT Alex Regards, Felix Begin forwarded message: Date: Fri, 27 Feb 2004 11:59:22 -0600 From: Steve Holland [EMAIL PROTECTED] To: Felix Khling [EMAIL PROTECTED] Subject: Re: [Dri-devel] savage-2-0-0 test notes I tested it with a fresh copy from the trunk (effective tuesday), and have the same problems. Here are some PNG's of the results from drawpix: 16 bit display, drawing to back buffer: http://69.5.151.193/~sdh4/drawpix16bit.png drawing to front buffer: http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png 24 bit display drawing to back buffer: http://69.5.151.193/~sdh4/drawpix24bit.png (24 bit display drawing to front buffer was similar to 16-front buffer) I also noticed problems when switching video modes on a 24 bit display. For example, running tuxracer would get the display parameters wrong, leading to an incomprehensible display (even after quitting). Thanks, Steve On Tue, 2004-02-24 at 07:13, Felix Khling wrote: On Mon, 23 Feb 2004 14:18:53 -0600 Steve Holland [EMAIL PROTECTED] wrote: [snip] __ Do you Yahoo!? Get better spam protection with Yahoo! Mail. http://antispam.yahoo.com/tools --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Fw: Re: [Dri-devel] savage-2-0-0 test notes
--- Steve Holland [EMAIL PROTECTED] wrote: My apologies for being horribly slow to respond. The mode switching problem occurs with bpp=24 (bpp=32 didn't work at all for me). Hardware is SuperSavage/IXC SDR (ThinkPad T23). I do get the message: (==) SAVAGE(0): Using video BIOS to set modes But I get this regardless of whether I have the UseBIOS option set or not in XF86Config. At this point the display always seems to be corrupted (bad mode) if I select 24 bpp (before it worked fine until I started tuxracer). The corrupted display shows the right colors, but the pixel arrangement is off. What should be the vertical left/right border of the screen is actually at a 30 degree angle to the horizontal, wrapping around from left to right (goes down and to the right). Moving the mouse down makes the pixels representing the pointer go down and to the right. Moving the mouse to the right makes them go up and to the right. I have also noticed a problem with loading the kernel driver. Even after I added: /sbin/modprobe agpgart /sbin/modprobe savage to /etc/rc.d/rc.local, the X server did not start with DRI enabled. The reason seems to be that some time is needed between the 'modprobe agpgart' and the 'modprobe savage'. Changing rc.local to: /sbin/modprobe agpgart sleep 1 /sbin/modprobe savage sleep 1 Solved the problem and now I get the message kernel: [drm] Initialized savage 1.0.0 20011023 on minor 0: SuperSavage IX/C SDR on bootup. HOWEVER, I noticed general system instability (random lockups) when operating in the original case, that is when both agpgart.o and savage.o were loaded, but savage not properly initialized. Steve, If you haven't already please try again with the DRI/mesa trunks rather than savage-2-0-0-branch. There have been quite a few updates since the branch was merged. Also how much videoram does your card have? You will need almost 17 MB for 1400x1050x24bpp (24bpp is really 32 bpp as far as the driver is concerned). The new driver disables the DRI if there is not enough ram. Before my changes to check available videoram, the front/back/depth buffers would be arbitrarily allocated and if you only have 16MB of video ram, the back buffer would overflow into the front buffer. Alex Thanks, Steve On Fri, 2004-02-27 at 15:21, Alex Deucher wrote: -- Felix Khling [EMAIL PROTECTED] wrote: Forwarding to dri-devel. Some of this (mode switching problem) looks like a 2D issue. Alex? I'll have to double check, but I don't recall having any problems with mode switching in tuxracer last time I played with it. Steve, what chip are you running on? bios or non-bios mode setting? it also might be an issue with the backbuffer overwriting the front buffer. see below. I don't know why drawpix to the backbuffer works for me but not for you. I'll look into this some time. But it's no priority right now. Hmm, I was just wondering if you have enough memory for 3D in 32bpp mode with 1400x1050. Front, back and depth buffers need a bit more than 16 MB in this mode. If your chip uses shared memory you'd have to reserve 32MB of shared memory for it to work. One of these days, maybe this weekend, I'll put a quick check in the buffer allocation code in savage_accel.c to make sure there is enough memory for 3D in the current mode/depth. OT I haven't really been testing the trunk to much lately, as I've been messing around with duoview support. I've just about got it working. I can set up the second controller and dot clock, I just can't get it to produce a signal. it's driving me nuts.../OT Alex Regards, Felix Begin forwarded message: Date: Fri, 27 Feb 2004 11:59:22 -0600 From: Steve Holland [EMAIL PROTECTED] To: Felix Khling [EMAIL PROTECTED] Subject: Re: [Dri-devel] savage-2-0-0 test notes I tested it with a fresh copy from the trunk (effective tuesday), and have the same problems. Here are some PNG's of the results from drawpix: 16 bit display, drawing to back buffer: http://69.5.151.193/~sdh4/drawpix16bit.png drawing to front buffer: http://69.5.151.193/~sdh4/drawpix16bitfrontbuffer.png 24 bit display drawing to back buffer: http://69.5.151.193/~sdh4/drawpix24bit.png (24 bit display drawing to front buffer was similar to 16-front buffer) I also noticed problems when switching video modes on a 24 bit display. For example, running tuxracer would get the display parameters wrong, leading to an incomprehensible display (even after quitting). Thanks, Steve On Tue, 2004-02-24 at 07:13, Felix Khling wrote: On Mon, 23 Feb 2004 14:18:53 -0600 Steve Holland [EMAIL PROTECTED] wrote: [snip] __ Do you Yahoo!? Yahoo! Search - Find what youre looking
[Dri-devel] tdfx breakage (patch included)
The tdfx_dri.so generated by the trunk doesn't include some of the common driver code. It will build, but _mesa_init_driver_functions() is undefined in the resulting library, so the dlopen fails and direct rendering is disabled. The attached patch fixes this. --- lib/GL/mesa/drivers/dri/tdfx/Imakefile.orig 2004-03-10 08:36:00.252328096 -0600 +++ lib/GL/mesa/drivers/dri/tdfx/Imakefile 2004-03-10 08:36:18.930488584 -0600 @@ -48,7 +48,7 @@ SRCS = $(TDFXSRCS) OBJS = $(DRIOBJS) $(DRMOBJS) $(COREMESAOBJS) \ - $(MESA_ASM_OBJS) $(TDFXOBJS) + $(MESA_ASM_OBJS) $(COMMONOBJS) $(TDFXOBJS) REQUIREDLIBS = MathLibrary $(LDPRELIB) $(GLXLIB) $(XONLYLIB) ExpatLibrary
[Dri-devel] Mach64 buffer stuff
I've been reading the state and dma code. I have some questions. 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. So would there be one set of unmapped buffers that are used for everything, and then a set of client, mapped buffers that are just used for state (only in mach64_state.c:mach64_dma_dispatch_vertex()?)? Or is it the other way around, some unmapped buffers just for copying state data to before it is emitted. The second way seems wrong to me, but that was what I thought Leif was describing in his earlier mail. I was going to start modifying the free list routines to allow for two lists per dev_priv structure, one mapped/one unmapped. I would add another freelist structure to drm_mach64_private_t. Would this type of change mean I could remove the placeholders list? Is this the propper way to go? -James --- 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=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
