Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Vladimir Dergachev wrote:
In the past I found useful not to turn drm debugging on, but, rather,
insert printk statements in various place in radeon code. This should
also provide more information about what is actually going on.
I
Jerome Glisse wrote:
I was doing some heavy debugging of all things that might be send
(allmost every debug flag + self print) unfortunetly the overload of
writting all this infos into a file cause the lock to disapear. No lock in
10min of quake3 while i get a lock in less 1 minutes without
Vladimir Dergachev wrote:
few more minutes before it locked up, but it still locked up
rather quickly.
I think I remember that there's some way to increase debugging
output from the drm module, but can't remember how. I have a
serial console, and these lockups rarely take down the whole
Nicolai Haehnle wrote:
It is easy to blame the DDX, but the truth is, we just don't know. The
people seeing lockups should try to figure out whether there is a direct
causal connection between e.g. mouse movements and lockups. If you are in a
fullscreen OpenGL applications, not moving the
On Sun, 2005-05-22 at 21:00 +0200, Jerome Glisse wrote:
Hi,
I setup a x86 with radeon 9800 pro or xt, trying to find
why it locks. I see little improvement with option no silken
mouse can you test and tell me if it dones anythings for
you (X -nosilk).
Sorry, that didn't do any good.
Vladimir Dergachev wrote:
Hi all,
I tagged yesterday the_perfect_frag snapshot of R300 driver.
The code is in CVS at http://r300.sf.net
As the name suggests I cannot find visible faults with rendering
Quake3 levels. Also, PPRacer shows no artifacts either, at least in
the first
Vladimir Dergachev wrote:
So I can confirm the occaisional lockup with the 9800 still.
neverputt played fine for half a round. Q3A played fine for about 8
minutes before locking up my machine. UT played fine for maybe 3-4
minutes before locking up. UT2004 locked up almost immediately in
I'm getting segfaults from a number of GL xscreensaver hacks on two
different FreeBSD machines using the dri-devel port:
[ [EMAIL PROTECTED] - ~ ]: gdb /usr/X11R6/bin/xscreensaver-hacks/glforestfire
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software,
FYI, -CURRENT crashes for me now if I enable the DRI:
login: info: [drm] Loading R200 Microcode
panic: vm_thread_new: kstack allocation failed
cpuid = 1
Uptime: 1m4s
Cannot dump. No dump device defined.
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
cpu_reset:
So I've started playing around with blender... The dri r200 drivers
work well with it, so I thought I'd give it a shot with the r300
drivers. It launches, and everything is fine till I go to select an
object... It crashes. The backtrace is:
[ [EMAIL PROTECTED] - ~ ]: glxgears -info
libGL: XF86DRIGetClientDriverName: 4.0.1 r200 (screen 0)
libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/r200_dri.so
libGL error: dlopen /usr/X11R6/lib/modules/dri/r200_dri.so failed
(/usr/X11R6/lib/modules/dri/r200_dri.so: undefined symbol:
Jung-uk Kim wrote:
On Sunday 20 March 2005 10:29 am, Adam K Kirchhoff wrote:
So I can't seem to get direct rendering enabled with 6.8.2 on my
freebsd installation at the moment.
This is what I'm seeing in the Xorg log file:
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI
So I can't seem to get direct rendering enabled with 6.8.2 on my freebsd
installation at the moment.
This is what I'm seeing in the Xorg log file:
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II) RADEON(0): [drm] Added 32 65536 byte
Vladimir Dergachev wrote:
Well, I thought I'd also point out that this solves the lockups I
was experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened
with the r300 driver in
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we
should not be reading from registers with engine busy.
Something may be needed
Vladimir Dergachev wrote:
Well, I thought I'd also point out that this solves the lockups I
was experiecing with the r300 driver, too :-)
Really ? And you can move cursor freely on r300 without lockups ?
I played almost a full game of neverputt... That hasn't happened with
the r300 driver in
Johannes Hofmann wrote:
After reading all the promising success stories about the r300 project, I am
wondering whether anybody successfully tried it on a *BSD.
Some time ago I tried on DragonFly BSD and in Xorg.0.log I found a message
that DRI was enabled, but glxinfo said direct rendering: No.
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are
locking up as well... Which is odd since I never had any of these
problem till this weekend. I'll start rolling back changes to the
Mesa dri driver... Perhaps this isn't directly related to the drm.
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Alright... So drm from both February 14th and January 1st are
locking up as well... Which is odd since I never had any of these
problem till this weekend. I'll start rolling back changes
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused by the RADEONWaitForIdleMMIO() call Vladimir
added to RADEONChooseCursorCRTC() on February 18th. I think
Michel Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I suspect this is caused
Vladimir Dergachev wrote:
On Mon, 14 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Mon, 2005-03-14 at 11:45 -0500, Adam K Kirchhoff wrote:
Michel Dnzer wrote:
On Mon, 2005-03-14 at 07:34 -0500, Adam K Kirchhoff wrote:
glxgears usually runs fine till I move the mouse... The mouse will
stutter.
I
Michel Dnzer wrote:
On Mon, 2005-03-14 at 18:05 -0500, Vladimir Dergachev wrote:
I am unsure of how to fix it though, as the call *is* needed, we should
not be reading from registers with engine busy.
Something may be needed, but probably not a wait for idle (which may
never succeed on an
Nicolai Haehnle wrote:
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e-mail, that glxgears wouldn't cause the
lockups. That's not true
On Sun, 2005-03-13 at 07:43 -0500, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
On Sunday 13 March 2005 03:10, Adam K Kirchhoff wrote:
Was it always shared with the USB controller? Can you try changing that?
Some more info for both of you...
I remarked, in an earlier e
Jan Gukelberger wrote:
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote:
[snip]
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0 owner ec8fce80 f7669180
[drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held,
held -2147483648 owner
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the week
before. Hmmm... I think my
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
don't recall ever seeing message from the kernel about nobody caring
about irq 16, or about radeon_cp_reset... With my 9800, I was getting
radeon_cp_dispatch_swap errors.
I do know, however, that my 9200 was working just last week or the
week
Jerome Glisse wrote:
Maybe the lockup you experiment is linked with the lockup
Adam gets. Adam have you upgraded you kernel recently ?
Maybe a 2.6.10 or even previous one could fix this. Thus
telling that the lockup may be due to some usb change or
some others things in the kernel.
Just trying to
On Friday I finally decided to reinstall debian on my box.. I started
with a fresh install, and then upgraded to Xorg cvs... I grabbed the
latest Mesa from cvs, as well as the latest drm.
[drm] Initialized drm 1.0.0 20040925
[drm] Initialized radeon 1.15.0 20050208 on minor 0: ATI Technologies
Odd. This is now happening, as well, with the drm from the 2.6.11
kernel. The card works fine with the drivers from XiG, however, so it
doesn't appear to be a hardware problem.
Adam
Adam K Kirchhoff wrote:
On Friday I finally decided to reinstall debian on my box.. I started
with a fresh
Michel Dnzer wrote:
On Sat, 2005-03-12 at 14:30 -0500, Adam K Kirchhoff wrote:
When trying neverputt:
[drm] Loading R200 Microcode
[drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held,
held 0
owner da0fcd80 d2809b80
Weird, does this only happen when running a 3D client
Dave Airlie wrote:
Odd. This is now happening, as well, with the drm from the 2.6.11 kernel.
The card works fine with the drivers from XiG, however, so it doesn't appear
to be a hardware problem.
wierd.. can you boot without X, and modprobe drm debug=1 then modprobe
radeon then start X? and
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
Hi Adam,
Could you remind me what video card you have ? And also any other
details that might be relevant (like resolution, refresh rate,
motherboard chipset, AGP mode, etc).
thank you
Vladimir Dergachev wrote:
I have a Radeon 9800 Pro (R350). I use a mergedfb desktop at
2560x1024... I don't know the refresh rate offhand. It's a dual
xeon machine. I'm running AGP at 4x.
Generally speaking, at that resolution, I'm able to play a couple
holes of neverputt before my
Vladimir Dergachev wrote:
Hi Adam,
Could you remind me what video card you have ? And also any other
details that might be relevant (like resolution, refresh rate,
motherboard chipset, AGP mode, etc).
thank you !
Vladimir
Vladimir Dergachev wrote:
I just tagged gliding_penguin snapshot of r300_driver.
We have not had snapshot in a long time and it seemed appropriate
to make one.
You can get the code by checking out r300_driver module with tag
gliding_penguin from CVS at http://r300.sf.net/ . Use a command
Nicolai Haehnle wrote:
On Sunday 06 March 2005 14:15, Adam K Kirchhoff wrote:
Unfortunately, I'm still getting pretty constant lockups that seem to be
related to high framerates. From ppcracer with RADEON_DEBUG set to all:
http://68.44.156.246/ppracer.txt.gz
On the plus side, the texture
FYI, something has happened to the driver in the past week :-)
http://68.44.156.246/neverputt.png
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products
Nicolai Haehnle wrote:
On Tuesday 22 February 2005 21:57, Adam K Kirchhoff wrote:
No luck. I setup my xorg.conf file to limit X to 640x480, and used
xrandr to drop the refresh rate to 60... Launched neverputt at 640x480,
fullscreen. Lockup was nearly instantaneous... The music continues
Any idea why the PCI IDs for the radeon 9800 were removed from the DRM?
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the
Vladimir Dergachev wrote:
On Fri, 4 Mar 2005, Michel [ISO-8859-1] Dnzer wrote:
On Fri, 2005-03-04 at 01:50 +0100, Rune Petersen wrote:
if ( (info-ChipFamily == CHIP_FAMILY_R300) ||
(info-ChipFamily == CHIP_FAMILY_R350) ||
- (info-ChipFamily == CHIP_FAMILY_RV350) )
+ (info-ChipFamily ==
Vladimir Dergachev wrote:
On Mon, 21 Feb 2005, Adam K Kirchhoff wrote:
FYI, I've now tried neverputt in a window, instead of fullscreen, and
I'm getting the same lockups as I was previously getting (full
lockups, including mouse, requiring me to ssh in a reboot). It
finally occurred to me
FYI, I've now tried neverputt in a window, instead of fullscreen, and
I'm getting the same lockups as I was previously getting (full lockups,
including mouse, requiring me to ssh in a reboot).
It finally occurred to me to check dmesg:
[drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out
Nicolai Haehnle wrote:
On Saturday 19 February 2005 01:05, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
Please, everybody, get the latest CVS (anonymous will take some time to
catch up...) and test vertex buffer mode with it (go to r300_run_render()
in r300_render.c and change
Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
On Saturday 19 February 2005 01:05, Adam K Kirchhoff wrote:
Nicolai Haehnle wrote:
Please, everybody, get the latest CVS (anonymous will take some
time to catch up...) and test vertex buffer mode with it (go to
r300_run_render
Vladimir Dergachev wrote:
Adam
Same lockups with tuxracer, but it happened much quicker. You can
view the full debug output from tuxracer at:
http://go.visualtech.com/adam/tuxracer.txt
It's about 6 megs in size.
I suggest you gzip it next time - this should work exceedingly well
with log
Nicolai Haehnle wrote:
Hi everybody,
As reported earlier, I had a perfectly repeatable lockup in VB mode that
always happened after the exact same number of frames in glxgears. I can't
explain everything about the lockup, mostly because I still don't know what
the two registers in the
Nicolai Haehnle wrote:
Please, everybody, get the latest CVS (anonymous will take some time to
catch up...) and test vertex buffer mode with it (go to r300_run_render()
in r300_render.c and change the #if so that r300_vb_run_render() is
called). I want to be really sure that this fixes it for
Vladimir Dergachev wrote:
On Fri, 18 Feb 2005, Vladimir Dergachev wrote:
I think I found the cause of lockups in VB mode - they were due to
cursor updating function in radeon_mergedfb.c calling OUTREGP() which
in turn called INREG.
Forgot to add:
1. the fix is in X.org CVS, if you are
Vladimir Dergachev wrote:
If so, this would suck majorly, especially if there is no
temperature sensor to tell how loaded the card is.
best
Vladimir Dergachev
Well, it seems unlikely that it was/is temperature related (my most
recent test
Vladimir Dergachev wrote:
On Wed, 16 Feb 2005, Aapo Tahkola wrote:
On Tue, 15 Feb 2005, Adam K Kirchhoff wrote:
I updated to the latest r300 code in cvs tonight in an effort to do
some
testing and noticed an immediate regression. glxgears locked up
almost
immediately, and neverputt locked up
Peter Zubaj wrote:
For me looks like:
If you uncoment r300 support in
int radeon_do_cp_idle(drm_radeon_private_t * dev_priv)
and in
static void radeon_cp_dispatch_swap(drm_device_t * dev)
x will work ok (no more locks or crash), but no 3d.
Peter Zubaj
Vsetko
I updated to the latest r300 code in cvs tonight in an effort to do some
testing and noticed an immediate regression. glxgears locked up almost
immediately, and neverputt locked up within a few minutes.
I wanted to test each change, step-by-step, from jump_and_click to
today but,
Ben Skeggs wrote:
Hello,
These are the games I've tried with the latest CVS from this afternoon:
Neverputt and neverball play, but some debug output gets displayed:
--snip-- :p
You can get neverball working much more smootly by switching everything
to low in the menu screen. Ignore the warn once
Vladimir Dergachev wrote:
UT, Marbleblast, and Orbz) die with:
r300_check_render: fallback:ctx-Texture.Unit[i].Enabled
Could you disable multitexturing in these games ?
I see an option for MarbleBlast called disableARBMultitexture. I'll try
enabling that when I get home this evening and give it
Ben Skeggs wrote:
Hello Adam,
You need to disable compiled vertex arrays, and multitexturing in
your q3config.cfg
file. Q3 should be very playable, with a couple of glitches.
Hmmm... I made those changes. The game started up and loaded a
level without problems. Unfortunately, within a few
Adam K Kirchhoff wrote:
Ben Skeggs wrote:
Hello Adam,
You need to disable compiled vertex arrays, and multitexturing in
your q3config.cfg
file. Q3 should be very playable, with a couple of glitches.
Hmmm... I made those changes. The game started up and loaded a
level without problems
These are the games I've tried with the latest CVS from this afternoon:
Neverputt and neverball play, but some debug output gets displayed:
*WARN_ONCE*
File r300_state.c function r300GenerateTexturePixelShader line 1600
Roland Scheidegger wrote:
Geller Sandor wrote:
I just removed the AGPFastWrite and DynamicClocks options. The crashes
still happen though.
Looks like not only I have problems with the radeon driver. I update the
X.org, drm, Mesa CVS once a week, but haven't found a working
combination
since 4-5
This is on a Radeon 9800 Pro, on a dual xeon rig.
Lessons 1 through 12 work...
Lesson 13 give me a black screen... I tried using indirect rendering to
see what it should look like, but that gave me an X Error Bad
Font... I've even modified the source file to use a font that I know
exists on
At one point someone posted to the dri-devel list an idea on how to
overcome the 2048x2048 limitation on 3D rendering (for r200
hardware)... I'm curious if it could be explained again and if anyone
has already begun work on this?
Adam
---
Jacek Rosik wrote:
Hi,
Dnia 28-01-2005, pi o godzinie 16:27 +0100, Roland Scheidegger
napisa(a):
Jacek Rosik wrote:
Hi,
I have some questions about r200 depth tiling. Generally I'm also
interested in r100 tiling too, but currently i work on r200.
First of all in functions
This morning the radeon DRM won't build for me:
CC [M] /usr/home/adamk/saved/source/drm/linux-core/ati_pcigart.o
CC [M] /usr/home/adamk/saved/source/drm/linux-core/radeon_drv.o
/usr/home/adamk/saved/source/drm/linux-core/radeon_drv.c:80: error:
`radeon_postinit' undeclared here (not in a
Vladimir Dergachev wrote:
On Wed, 12 Jan 2005, Adam K Kirchhoff wrote:
So I've finally tested the r300_driver on my 9800. Specifically it's a:
ATI Technologies Inc Radeon R350 [Radeon 9800]
Direct Rendering is enabled when X starts up. I'll attach the output
from glxinfo. glxgears -info gives
I can't get r300_demo to compile. Something with getgetopt:
ld -r xf86drm.o xf86drmRandom.o xf86drmSL.o xf86drmHash.o -o libdrm.o
make[1]: Leaving directory `/home/adamk/r300_demo/libdrm'
gengetopt r300_demo.ggo
gengetopt:9: parse error group
gengetopt:9: defgroup chip type groupdesc=
Vladimir Dergachev wrote:
r200_context.h:98:1: warning: this is the location of the previous
definition
r300_ioctl.c: In function `r300ClearBuffer':
r300_ioctl.c:67: error: `drm_r300_cmd_header_t' undeclared (first use
in this function)
^^
Know
Jerome Glisse wrote:
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
r200_context.h:98:1: warning: this is the location of the previous
definition
r300_ioctl.c: In function `r300ClearBuffer':
r300_ioctl.c:67: error: `drm_r300_cmd_header_t' undeclared (first
use in this function
Adam K Kirchhoff wrote:
Jerome Glisse wrote:
Adam K Kirchhoff wrote:
Vladimir Dergachev wrote:
r200_context.h:98:1: warning: this is the location of the previous
definition
r300_ioctl.c: In function `r300ClearBuffer':
r300_ioctl.c:67: error: `drm_r300_cmd_header_t' undeclared (first
use
FYI,
Apparently, even though the DRM_SOURCE_PATH variable is set, it's
not getting checked. If I copy the r300_driver/drm directory to the
same directory as the Mesa source tree, the r300_dri.so library gets
built fine.
Now to test it :-)
Adam
Well, when I went to load the kernel
I've seen so much activity on the r300_driver recently, I thought it'd
be good time to test it out on my 9800 and give as much feedback as
possible.
Unfortunately, I'm not even able to get it to compile. I think I've
followed the instructions correctly. I actually copied the
So I'm trying to get the DRI working on DragonFlyBSD. Someone has
created a series of patches for Xorg 6.8.1 which get it to compile and
run on DragonFly. Direct Rendering gets enabled:
(II) RADEON(0): [drm] installed DRM signal handler
(II) RADEON(0): [DRI] installation complete
(II)
Philipp Klaus Krause wrote:
Thank you for doing this work. We really need to get the open-source
ATI driver on par with the propretary driver (both feature-wise and
performance-wise).
But sadly we will NEVER match it.
NO SmoothVision, HyperZ docu ever
The nonfree xig driver has been
Mike Mestnik wrote:
--- Philipp Klaus Krause [EMAIL PROTECTED] wrote:
Thank you for doing this work. We really need to get the open-source
ATI driver on par with the propretary driver (both feature-wise and
performance-wise).
But sadly we will NEVER match it.
NO SmoothVision, HyperZ
Mike Mestnik wrote:
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
Mike Mestnik wrote:
--- Philipp Klaus Krause [EMAIL PROTECTED] wrote:
Thank you for doing this work. We really need to get the
open-source
ATI driver on par with the propretary driver (both feature
I just heard that ATI has released r300 specs to Xi Graphics. While I'm
sure it's under an NDA, at least is shows a little more flexibility from
ATI in terms of releasing those specs. Might it be worth approaching
them now in releasing those specs to the DRI developers under the same
rules
I'm having problems with my laptop after doing an apt-get upgrade.
I have done a make install since the upgrade.
The mach64 kernel driver is getting loaded, but direct rendering is
never enabled. Instead, I get various drmOpenDevice failures for
/dev/dri/card0 through /dev/dri/card254:
Dave Airlie wrote:
Mind you, I haven't updated my copy of the DRI cvs tree in a very long time.
Certainly not since I last did a make install. Any ideas?
The only thing I'm noticing now that I don't remember seeing before is this:
mach64: Ignoring new-style parameters in presence of obsolete ones
Dave Airlie wrote:
That's very possible, but I did reinstall from my local copy of the DRI/Mesa
cvs tree.
where did the drm come from?
The drm branch of the DRI cvs. From back in September. What's the current
state of the cvs tree? I don't mind upgrading to the most recent code, but
Vladimir Dergachev wrote:
I have just committed code into r300_demo that will autodetect
chip type and display width.
I would ask everyone who tried out (or tried to try out) patches
from r300.sourceforge.net to let me know whether they could run it
successfully or not.
The most recent source
Eric, I believe, is studying abroad. As of April 22nd, he was still
away... His livejournal suggests Cuba:
http://www.livejournal.com/users/anholt/
Adam
On Tue, 4 May 2004, Felix [ISO-8859-1] Kühling wrote:
Hi,
does anyone know how to contact Eric Anholt? I just wrote a mail to him
Oh, you could also try his FreeBSD mail address: [EMAIL PROTECTED]
He seems to have some net access, but I'm not sure how easy it is for him
to get his e-mail.
Adam
On Tue, 4 May 2004, Adam K Kirchhoff wrote:
Eric, I believe, is studying abroad. As of April 22nd, he was still
away... His
I don't think there's much chance of ATI giving out those docs now.
Matthew Tippet at ATI, who I have exchanged some e-mail with, said It is
unlikely (for a number of reasons) that we will be releasing any R300
specifications any time soon. This was back on March 4th.
When I pressed a little
I'm glad to see someone working on this. I know it's going to be a huge
hassle to get up and running (assuming it works at all) but it'll be worth
it just to show ATI linux users that it is possible to create stable,
fast, 2D/3D drivers for their R300 cards for XFree86 (since ATI seems
quite
I can't get a current version of the DRI cvs to build on FreeBSD any more:
cd ./config/makedepend make -f Makefile.proto bootstrap
Makefile.proto, line 30: Need an operator
Makefile.proto, line 81: Need an operator
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in
Never mind Stupid mistake on my part.
Adam
On Sat, 17 Apr 2004, Adam K Kirchhoff wrote:
I can't get a current version of the DRI cvs to build on FreeBSD any more:
cd ./config/makedepend make -f Makefile.proto bootstrap
Makefile.proto, line 30: Need an operator
Makefile.proto, line
There's a discussion currently on the rage3d.com linux forum as to whether
or not the DRI is good enough for 3D gaming. One particular individual
has claimed that the reason why the FireGL drivers (which use the DRI)
have worse performance than the nVidia drivrs are because the FireGL
drivers
Was the DRI tree ever synced with the XFree86 tree prior to 4.4.0? I
downloaded and installed 4.4.0 on a NetBSD system, thinking that MergedFB
would just work but, unfortunately, it doesn't.
Adam
---
This SF.Net email is sponsored by: IBM
So I geuss the question should be:
What's the schedule for merging the DRI tree with the XFree86 tree and is
there any reason why this wasn't done before the release of 4.4.0?
Adam
On Sat, 6 Mar 2004, Alex Deucher wrote:
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
Was the DRI tree
On Sat, 6 Mar 2004, Alex Deucher wrote:
--- Adam K Kirchhoff [EMAIL PROTECTED] wrote:
So I geuss the question should be:
What's the schedule for merging the DRI tree with the XFree86 tree
and is
there any reason why this wasn't done before the release of 4.4.0?
The trees were
On Mon, 1 Mar 2004, Alan Swanson wrote:
On Mon, 2004-03-01 at 13:37, Dieter Nützel wrote:
Someone preparing a merge?
To which release?
The official 4.4 release that Red Hat, SUSE, Debian, Mandrake, Gentoo
and most other distributions are not touching with a barge pole?
The client
Since I have access to both a 9200SE and an 8500 (but not a 9000 or 9200,
unfortunately), I decided to run a quick benchmark with the cards using
ut2003. With the Inferno Flyby, I got the following results with the
9200:
5.294707 / 14.600776 / 133.766464 fps rand[1951333785]
Score =
2004, Adam K Kirchhoff wrote:
Since I have access to both a 9200SE and an 8500 (but not a 9000 or 9200,
unfortunately), I decided to run a quick benchmark with the cards using
ut2003. With the Inferno Flyby, I got the following results with the
9200:
5.294707 / 14.600776 / 133.766464 fps
On Mon, 29 Dec 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
Now that there are patches available to support S3TC compressed textures
on Radeon cards, are there any plans to integrate those patches into the
DRI source tree?
Until an agreement can be reached between the open-source
.
Perhaps you'd like to wait till we hear back from the legal people Alan
Cox has asked to take a look at the issue before you jump to your
decision.
Adam
On Mon, 29 Dec 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
Now that there are patches available to support S3TC compressed textures
On Mon, 29 Dec 2003, Ian Romanick wrote:
I am not a lawyer. None of what follows is legal advice. Furthermore,
I am speaking for myself alone, NOT my employer.
Adam K Kirchhoff wrote:
On Mon, 29 Dec 2003, Ian Romanick wrote:
Adam K Kirchhoff wrote:
Now that there are patches
Now that there are patches available to support S3TC compressed textures
on Radeon cards, are there any plans to integrate those patches into the
DRI source tree?
Adam
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an
On Sun, 28 Dec 2003, Jacek [iso-8859-2] Popawski wrote:
On Sun, Dec 28, 2003 at 10:23:17AM -0500, Adam K Kirchhoff wrote:
Now that there are patches available to support S3TC compressed textures
on Radeon cards, are there any plans to integrate those patches into the
DRI source tree?
I
On Sun, 28 Dec 2003, Jacek [iso-8859-2] Popawski wrote:
On Sun, Dec 28, 2003 at 11:08:26AM -0500, Adam K Kirchhoff wrote:
Why not just leave it up to RedHat, then, to either leave the code in or
pull it out?
RedHat was just example. Point is that patent holder may sue anyone who
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
101 - 200 of 327 matches
Mail list logo
