Am Mittwoch, 8. Dezember 2004 00:27 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> >>> True for DoomIII, but who can switch the lights ON, finally...?
> >>> ;-)
> >>
> >> That is some weird texcoord problem. (I actually have a one-line
> >> workaround for that, which breaks submitting texgen
Hi,
Now, on FC3 testing lastest cvs I got:
radeon: Unknown symbol i2c_bit_add_bus
radeon: Unknown symbol i2c_bit_del_bus
when I try to load radeon ko .
thanks,
On Mon, 2004-12-13 at 00:11 +0100, Roland Scheidegger wrote:
> Sergio Monteiro Basto wrote:
> > Hi Roland,
> > So , for hyperz patch
>
> radeon: Unknown symbol i2c_bit_add_bus
> radeon: Unknown symbol i2c_bit_del_bus
>
you need i2c support modules loaded.. modprobe the radeon driver it should
all work then...
> when I try to load radeon ko .
>
> thanks,
>
>
> On Mon, 2004-12-13 at 00:11 +0100, Roland Scheidegger wrote:
> > Ser
thanks,
Now I can load radeon.ko
after modprobe i2c_via.ko
thanks,
On Mon, 2004-12-13 at 17:27 -0500, Adam Jackson wrote:
> On Monday 13 December 2004 17:15, Dave Airlie wrote:
> > > radeon: Unknown symbol i2c_bit_add_bus
> > > radeon: Unknown symbol i2c_bit_del_bus
> >
> > you need i2c suppo
>
> Shouldn't radeon.ko build without i2c hooks if CONFIG_I2C == NO ?
it does but all stock Fedora kernels have I2c configured you just have to
use modprobe to load kernel modules not insmod..
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
pam_smb
On Monday 13 December 2004 17:15, Dave Airlie wrote:
> > radeon: Unknown symbol i2c_bit_add_bus
> > radeon: Unknown symbol i2c_bit_del_bus
>
> you need i2c support modules loaded.. modprobe the radeon driver it should
> all work then...
Shouldn't radeon.ko build without i2c hooks if CONFIG_I2C ==
Sergio Monteiro Basto wrote:
How do you compile your radeon dri ?
with make linux-x86 on last mesa cvs ?
linux-dri-x86. linux-dri would also work.
Roland
---
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds
Sergio Monteiro Basto wrote:
I forget ask the most important
where do you commit dri/radeon changes or
or once updated dri you compile radeon has standalone ?
or did you don't need update mesa/drivers/dri/radeon ?
I don't quite understand the question, but
>>radeon_ioctl.c: In function `radeonCl
Am Donnerstag, 9. Dezember 2004 00:30 schrieb Dieter Nützel:
> Am Mittwoch, 8. Dezember 2004 00:27 schrieb Roland Scheidegger:
> > Dieter Nützel wrote:
> > >>> 'Zooming' a 3D VTK prog from the upper left corner into a bigger
> > >>> window in the desktop middle show missing z/buffer
> > >>> cleari
Am Mittwoch, 8. Dezember 2004 00:27 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> >>> True for DoomIII, but who can switch the lights ON, finally...?
> >>> ;-)
> >>
> >> That is some weird texcoord problem. (I actually have a one-line
> >> workaround for that, which breaks submitting texgen
Dieter Nützel wrote:
True for DoomIII, but who can switch the lights ON, finally...?
;-)
That is some weird texcoord problem. (I actually have a one-line
workaround for that, which breaks submitting texgen and non-texgen
coordinates at the same time more or less completely).
Let me test.
Attach
Am Montag, 6. Dezember 2004 22:32 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> > Am Samstag, 4. Dezember 2004 00:47 schrieb Roland Scheidegger:
> >> Here's the new patch version (finally...).
> >
> > Works so far on r200 here, too;-)
> >
> >> - when only stencil (or only z) buffer is cleare
Dieter Nützel wrote:
Am Samstag, 4. Dezember 2004 00:47 schrieb Roland Scheidegger:
Here's the new patch version (finally...).
Works so far on r200 here, too;-)
- when only stencil (or only z) buffer is cleared in a visual which
supports stencil and z, now a proper fallback clear is used (still
Am Samstag, 4. Dezember 2004 00:47 schrieb Roland Scheidegger:
> Here's the new patch version (finally...).
Works so far on r200 here, too;-)
> - when only stencil (or only z) buffer is cleared in a visual which
> supports stencil and z, now a proper fallback clear is used (still with
> z-buffer
On Sat, 4 Dec 2004 17:22:32 -0500
Garry Reisky <[EMAIL PROTECTED]> wrote:
> On (04/12/04 00:47), Roland Scheidegger wrote:
> > From: Roland Scheidegger <[EMAIL PROTECTED]>
> > To: "DRI developer's list" <[EMAIL PROTECTED]>
> > Subject: new
On (04/12/04 00:47), Roland Scheidegger wrote:
> From: Roland Scheidegger <[EMAIL PROTECTED]>
> To: "DRI developer's list" <[EMAIL PROTECTED]>
> Subject: new hyperz patch
> Date: Sat, 04 Dec 2004 00:47:48 +0100
>
> Here's the new patch version (
Here's the new patch version (finally...).
There are quite a few changes in it:
- works with r100, rv250, hopefully r200 and rv100... still unsure
though especially about rv100, but based on feedback (thanks Rogier)
I've tried to come up with some different offset formula.
- hierarchical-z is gon
> Am Freitag, 12. November 2004 00:06 schrieb Dieter Nützel:
> > Am Donnerstag, 11. November 2004 22:30 schrieb Roland Scheidegger:
> > > Dieter Nützel wrote:
> > > > Let me try on r200 ;-)
> > > >
> > > > Some feedback for Roland's hyperz-dri-7.patch and
> > > > hyperz-drm-14.patch. => rv path on
Am Donnerstag, 11. November 2004 22:30 schrieb Roland Scheidegger:
> Dieter Nützel wrote:
> > Let me try on r200 ;-)
> >
> > Some feedback for Roland's hyperz-dri-7.patch and
> > hyperz-drm-14.patch. => rv path on my r200.
Now with hyperz-drm-15.patch.
> > First I've change only drm. -0x1002 0x51
Dieter Nützel wrote:
Let me try on r200 ;-)
Some feedback for Roland's hyperz-dri-7.patch and
hyperz-drm-14.patch. => rv path on my r200.
First I've change only drm. -0x1002 0x514C CHIP_R200 "ATI Radeon QL
R200 8500 LE" +0x1002 0x514C CHIP_R200|CHIP_IS_RV "ATI Radeon QL R200
8500 LE"
ok.
-
Am Donnerstag, 11. November 2004 21:39 schrieb Stephane Marchesin:
> Roland Scheidegger wrote:
> > Roland Scheidegger wrote:
> >> In fact, that was already discussed briefly at irc. For now it just
> >> seemed more important to get it working on more cards and fix the
> >> rendering problems than t
Roland Scheidegger wrote:
Roland Scheidegger wrote:
In fact, that was already discussed briefly at irc. For now it just
seemed more important to get it working on more cards and fix the
rendering problems than to worry about "minor" issues like multiple
rendering apps :). I did get clearing only
Roland Scheidegger wrote:
In fact, that was already discussed briefly at irc. For now it just
seemed more important to get it working on more cards and fix the
rendering problems than to worry about "minor" issues like multiple
rendering apps :). I did get clearing only the needed tiles working
Keith Whitwell wrote:
Roland Scheidegger wrote:
This is a new version of the hyperz patch. It should have a better
chance of running on all cards.
I get the feeling that hyperz was designed with a private z-buffer in
mind. It would be interesting to see if the X server can dynamically
un-hyperz
Roland Scheidegger wrote:
This is a new version of the hyperz patch. It should have a better
chance of running on all cards.
I get the feeling that hyperz was designed with a private z-buffer in mind.
It would be interesting to see if the X server can dynamically un-hyperz the
backbuffer when it
This is a new version of the hyperz patch. It should have a better
chance of running on all cards.
Also, Stephane has corrected the clearing problems if other windows were
moved on top of a rendering window. However, for now clearing will clear
all tiles up to the end of the window completely, s
26 matches
Mail list logo
