José Fonseca wrote:
The current mach64 (mesa 4.x) driver doesn't seem to be doing z depth
test. After assuring that the mach64's z control register was being set
properly I realized that the vertex buffers had the z in a [0,1] scale
while the primitive drawing functions expected them in a
Keith,
I'm curious to know how you reminded after so long (7 months)! Did you
actually writed it now or was it stuck in a mail queue all this time?
By now I got to more or less to those answers, but thanks anyway. As saying
goes: it's better late than never!
Regards,
José Fonseca
On Thu,
José Fonseca wrote:
Keith,
I'm curious to know how you reminded after so long (7 months)! Did you
actually writed it now or was it stuck in a mail queue all this time?
By now I got to more or less to those answers, but thanks anyway. As
saying goes: it's better late than never!
Oh.
I've just pulled the current DRI main branch, done the lndir and make
World as per the compilation guide.
However, when I do a make install afterword, I get the following error:
beginning of install snipped
`/usr/src/xc/build/lib/GL/mesa/src/drv/radeon'
installing in
Am Donnerstag, 10. Oktober 2002 01:42 schrieb Fabrice Bellet:
On Thu, Oct 10, 2002 at 12:33:59AM +0200, Michel Dänzer wrote:
What date is the DRM source you're using from?
I got that all the time with my dual Athlon MP 1900+, but nobody found a
solution so far.
Anyone who can fix the
What exactly is drm_radeon_depth_clear_t storing; is it registers on the card having
something to do with the way depth buffers get used???
Tom
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Tom Hosiawa wrote:
What exactly is drm_radeon_depth_clear_t storing; is it registers on the card having
something to do with the way depth buffers get used???
If you look at where it's used, you get a clue that these are register values:
OUT_RING_REG( RADEON_RB3D_ZSTENCILCNTL,
On Mit, 2002-10-09 at 22:53, Pawel Salek wrote:
I have got a following messages on boot with current snapshot
radeon-20021009, running with ATI Radeon Mobility M6 LY rev 0, stock
RH8.0 kernel (2.4.18-14 with a whole lot of patches).
modprobe: modprobe: Can't locate module
On Thu, Oct 10, 2002 at 04:55:34PM +0200, Dieter Nützel wrote:
Am Donnerstag, 10. Oktober 2002 01:42 schrieb Fabrice Bellet:
I updated my dri HEAD cvs tree two hours ago, and I rebuilt
the drm module too.
Which kernel version?
2.4.20-pre9.
Hmm, all the interrupts are routed to the
Am Donnerstag, 10. Oktober 2002 18:25 schrieb Fabrice Bellet:
On Thu, Oct 10, 2002 at 04:55:34PM +0200, Dieter Nützel wrote:
Am Donnerstag, 10. Oktober 2002 01:42 schrieb Fabrice Bellet:
I updated my dri HEAD cvs tree two hours ago, and I rebuilt
the drm module too.
Which kernel
On Thu, Oct 10, 2002 at 06:55:40PM +0200, Dieter Nützel wrote:
Am Donnerstag, 10. Oktober 2002 18:25 schrieb Fabrice Bellet:
After doing some tests again, I noticed that R200_NO_IRQS doesn't
basically resolve the locking problem. But, when enabled,
I no longer have the drmRadeonIrqWait:
Michel Dänzer wrote:
On Don, 2002-10-10 at 02:36, Brian Paul wrote:
Michel Dänzer wrote:
And there are new endianness bugs. :/ The infamous gears pulsate between
the two states seen in
http://penguinppc.org/~daenzer/DRI/gears-thick.png and
http://www.penguinppc.org/~daenzer/DRI/gears-thin.png
On 2002.10.10 18:09 Michel Dänzer wrote:
Do you also see the signal 11 in the X server log? [snip]
That won't help the signal 11 though, which is probably still due to
some kind of incompatibility in the binary snapshots.
Yes, I see signal 11 in the log (attached). Strangely, since the
On Thu, Oct 10, 2002 at 11:58:23PM +0200, Pawel Salek wrote:
On 2002.10.10 18:09 Michel Dänzer wrote:
Do you also see the signal 11 in the X server log? [snip]
That won't help the signal 11 though, which is probably still due to
some kind of incompatibility in the binary snapshots.
Yes, I see
Joe == Joe Mackay [EMAIL PROTECTED] writes:
Joe On Thu, 10 Oct 2002, Frank Van Damme wrote:
www.student.kuleuven.ac.be/~m9917684/r200-20020920-linux.i386.tar.bz2 should
work.
Joe Brilliant... thanks, you're a star!
Joe Working fairly well now, apart from Xv. Just have
Brian Paul wrote:
Michel Dänzer wrote:
On Don, 2002-10-10 at 02:36, Brian Paul wrote:
Michel Dänzer wrote:
And there are new endianness bugs. :/ The infamous gears pulsate
between
the two states seen in
http://penguinppc.org/~daenzer/DRI/gears-thick.png and
On Fre, 2002-10-11 at 00:54, Brian Paul wrote:
Brian Paul wrote:
Michel Dänzer wrote:
OK, I see the problem now (on x86). I'll see what I can do.
I've checked in the fix.
I saw your commit and tried it already. Great work!
--
Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux
On Fre, 2002-10-11 at 00:24, José Fonseca wrote:
On Thu, Oct 10, 2002 at 11:58:23PM +0200, Pawel Salek wrote:
On 2002.10.10 18:09 Michel Dänzer wrote:
Do you also see the signal 11 in the X server log? [snip]
That won't help the signal 11 though, which is probably still due to
some kind of
Christopher == Christopher L Estep [EMAIL PROTECTED] writes:
(==) RADEON(0): Silken mouse enabled
Fatal server error:
Caught signal 11. Server aborting
Christopher There is *still* stuff from GATOS in the nightlies (and in the trunk)
so DRI
Christopher is turned
Brian Paul wrote:
Brian Paul wrote:
I've created a new DRI branch: mesa-4-1-branch
I'm in the process of porting all the DRI drivers to the new Mesa 4.1
code.
I'll be checking in changes soon, but don't expect anything to run or
even
compile. I'll post again when I think it's
On Fre, 2002-10-11 at 01:47, Adam Duck wrote:
Christopher == Christopher L Estep [EMAIL PROTECTED] writes:
(==) RADEON(0): Silken mouse enabled
Fatal server error:
Caught signal 11. Server aborting
Christopher There is *still* stuff from GATOS in the nightlies
Michel Dänzer wrote:
It seems you have defined GlxBuiltInxxx for at least one driver in
config/cf/host.def, which seems to be broken. It's not necessary for
normal operation.
A! I was trying to build in the Radeon driver, so that I could debug
a SIGFPE that I am getting when I set
Lots of updates:
New columns for gamma, ffb, mach64, virge, sis and trident.
New rows for Primary Authors and Operating Sytems.
I put question marks where I wasn't sure of what to put.
-Brian
Summary of DRI driver features:
ATI r200
ATI Radeon
ATI r128
Intel i810/815
Intel
On Fre, 2002-10-11 at 02:58, David D. Hagood wrote:
Michel Dänzer wrote:
It seems you have defined GlxBuiltInxxx for at least one driver in
config/cf/host.def, which seems to be broken. It's not necessary for
normal operation.
A! I was trying to build in the Radeon driver, so that
Michel Dänzer wrote:
No, that option has nothing to do with the 2D driver. You probably want
#define DoLoadableServer NO
OK, that will help.
BTW I think this bug is fixed in XFree86 CVS.
No, it is not. I've called this one out a few times, but it still
persists. I cannot beleive I am
OK, the IRQ stuff seems working currectly on my dual Athlon SMP box.
With and without setenv R200_NO_USLEEPS 1 I get the same numbers for Q3A.
Q3A 1.32, 640x480x24 window on a 1280x1024x24 desktop, demo four:
with sound: 130.3 fps
wthout sound: 138.6 fps
r_smp 1
quake3.x86 block,
I managed to get DRI up and running with this noghtly in RH 8 (Psyche),
but the strange thing was *how*.
Once I got everything compiled and installed, it kept coming back
*indirect*. So, following the troubleshooting guide, I ran lsmod as
root. The *radeon* module loaded fine; however, the
Am Freitag, 11. Oktober 2002 05:35 schrieb Christopher L. Estep:
I managed to get DRI up and running with this noghtly in RH 8 (Psyche),
but the strange thing was *how*.
Once I got everything compiled and installed, it kept coming back
*indirect*. So, following the troubleshooting guide, I
28 matches
Mail list logo
