On 25 Sep 2002 22:32:32 -0400
Andy Dustman <[EMAIL PROTECTED]> wrote:
> On Tue, 2002-09-24 at 09:25, José Fonseca wrote:
>
> > I've updated my workstation to the RedHat Linux 7.3.94 beta, which has
> > gcc 3.2. So now forward the snapshots will be built with this version.
> > AFAIK this shouldn'
Ian Romanick wrote:
> Here is a patch that will enable the 3rd texture unit in the Radeon
> R100/RV200 driver. I have tested it using multiarb on a Radeon "classic"
> DDR and a Radeon M6 (AGP developer board). There are a few issues that I
> came across that should be resolved before applying.
>
On Tue, 2002-09-24 at 09:25, José Fonseca wrote:
> I've updated my workstation to the RedHat Linux 7.3.94 beta, which has
> gcc 3.2. So now forward the snapshots will be built with this version.
> AFAIK this shouldn't pose any problem to the users since the key issue
> is that the kernel modules
I've been wondering for some time why at least the Quake 2 engine is
very slow with multitexturing enabled, i.e. with
set gl_ext_multitexture "1"
in ~/.quake2/baseq2/config.cfg, it crawls on stuff like explosions.
Change that to 0 and it's snappy.
Do people see this effect on non-Radeon cards
Am Donnerstag, 26. September 2002 01:46 schrieb Linus Torvalds:
> On Thu, 26 Sep 2002, Dieter Nützel wrote:
> > Can we please change the IRQ code to not share the same IRQ with another
> > device?
>
> Not up to us. It depends on the physical routing of the interrupt line on
> the motherboard (ofte
On Thu, Aug 22, 2002 at 11:19:49AM -0700, Ian Romanick wrote:
> Unless somebody knows another way, I believe that we need a sw fallback if
> texUnit->CombineModeRGB == GL_DOT3_RGB_ARB &&
> texUnit->CombineScaleShiftRGB != 1. My guess is that radeonUpdateTextureEnv
> should be modified to return
Here is a patch that will enable the 3rd texture unit in the Radeon
R100/RV200 driver. I have tested it using multiarb on a Radeon "classic"
DDR and a Radeon M6 (AGP developer board). There are a few issues that I
came across that should be resolved before applying.
- How should we calculate th
On Thu, 26 Sep 2002, Dieter Nützel wrote:
>
> Can we please change the IRQ code to not share the same IRQ with another
> device?
Not up to us. It depends on the physical routing of the interrupt line on
the motherboard (often together with some amount programmability, but
Linux already tries t
Am Donnerstag, 26. September 2002 00:17 schrieb Michel Dänzer:
> On Mit, 2002-09-25 at 23:33, n001 wrote:
> > On 25 Sep 2002 19:33:48 +0200
> >
> > Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2002-09-23 at 19:48, n001 wrote:
> > > > Small bug report of the latest r200-02-2 branch
> > >
On Mit, 2002-09-25 at 23:33, n001 wrote:
> On 25 Sep 2002 19:33:48 +0200
> Michel Dänzer <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2002-09-23 at 19:48, n001 wrote:
> > > Small bug report of the latest r200-02-2 branch
> > > (cvs checkout just before the merge in trunk)
> > >
> > > With a lot of l
On 25 Sep 2002 19:33:48 +0200
Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Mon, 2002-09-23 at 19:48, n001 wrote:
> > Small bug report of the latest r200-02-2 branch
> > (cvs checkout just before the merge in trunk)
> >
> > With a lot of loki demos, i have this error:
> >
> > r200WaitForFrameCo
On Mit, 2002-09-25 at 21:08, n001 wrote:
> Hello, i can't build the last CVS trunk (head):
>
> radeon_ioctl.c: In function `radeonGetAllParams':
> radeon_ioctl.c:1054: `RADEON_PARAM_IRQ_NR' undeclared (first use in this function)
>
>
> # grep -r RADEON_PARAM_IRQ_NR .
> ./lib/GL/mesa/src/drv/rad
Hello, i can't build the last CVS trunk (head):
radeon_ioctl.c: In function `radeonGetAllParams':
radeon_ioctl.c:1054: `RADEON_PARAM_IRQ_NR' undeclared (first use in this function)
# grep -r RADEON_PARAM_IRQ_NR .
./lib/GL/mesa/src/drv/radeon/radeon_ioctl.c: gp.param = RADEON_PARAM_IRQ_NR;
On Mit, 2002-09-25 at 19:34, Keith Whitwell wrote:
> Michel Dänzer wrote:
> > On Mit, 2002-09-25 at 04:17, Michel Dänzer wrote:
> >
> >>On Mit, 2002-09-25 at 03:52, Eric Anholt wrote:
> >>
> >>>On Tue, 2002-09-24 at 17:08, Michel Dänzer wrote:
> >>>
> BTW I'm just experiencing IRQ timeouts as
On Mon, 2002-09-23 at 19:48, n001 wrote:
> Small bug report of the latest r200-02-2 branch
> (cvs checkout just before the merge in trunk)
>
> With a lot of loki demos, i have this error:
>
> r200WaitForFrameCompletion: drmRadeonIrqWait: -16
If that happened after a VT switch, it should be fixe
On Mit, 2002-09-25 at 04:17, Michel Dänzer wrote:
> On Mit, 2002-09-25 at 03:52, Eric Anholt wrote:
> > On Tue, 2002-09-24 at 17:08, Michel Dänzer wrote:
> > >
> > > BTW I'm just experiencing IRQ timeouts as well. In fact, no interrupts
> > > occur at all, and the RADEON_GEN_INT_STATUS register s
Michel Dänzer wrote:
> On Mit, 2002-09-25 at 04:17, Michel Dänzer wrote:
>
>>On Mit, 2002-09-25 at 03:52, Eric Anholt wrote:
>>
>>>On Tue, 2002-09-24 at 17:08, Michel Dänzer wrote:
>>>
BTW I'm just experiencing IRQ timeouts as well. In fact, no interrupts
occur at all, and the RADEON_GEN_
Michel Daenzer wrote:
> CVSROOT: /cvsroot/dri
> Module name: xc
> Repository: xc/xc/programs/Xserver/hw/xfree86/drivers/ati/
> Changes by: mdaenzer@usw-pr-cvs1. 02/09/25 10:17:37
>
> Log message:
> IRQ related fixes
>
> Modified files:
> xc/xc/programs/Xserver/hw/xfree86/driv
Vikberg, Gunnar wrote:
> I am new to this list, but I would like to help with the development of the R200 and
> the new R300 series of GPU/VPU from ATI. I am already a registered developer with
> ATI, and my question is where I can get the source code for the R200 drivers (and
> R300 if available)
I am new to this list, but I would like to help with the development of the R200 and
the new R300 series of GPU/VPU from ATI. I am already a registered developer with
ATI, and my question is where I can get the source code for the R200 drivers (and
R300 if available) so that I can start helping ou
Karl Rasche wrote:
>>Do you mean a generic extension (ie separate out the allocator bits of
>>GL_NV_vertex_array_range), or a generic implementation?
>>
>
> A generic implementation.
Yes, I think this is worthwhile. There's very little that isn't generic in
radeon_mem.c as it stands.
Keith
> Do you mean a generic extension (ie separate out the allocator bits of
> GL_NV_vertex_array_range), or a generic implementation?
A generic implementation.
Karl
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http:
Karl Rasche wrote:
>>The r200 driver has the allocator parts of GL_NV_vertex_array_range, and can
>>
>
> Keith,
>
> I'd be interested in trying to get this working with the mga driver. Would
> it be worth to try and move things to a generic allocator?
Do you mean a generic extension (ie sepa
> The r200 driver has the allocator parts of GL_NV_vertex_array_range, and can
Keith,
I'd be interested in trying to get this working with the mga driver. Would
it be worth to try and move things to a generic allocator?
It could be quite fun without having a r200 though.. :)
Thanks.
Karl
24 matches
Mail list logo
