Vladimir Dergachev wrote:
3) I can enable more pipes for r420 cards, but am unable to test it
on 420 cards with fewer pipes.
Do I just add this and wait for someone to complain?
A better way would be to read carefully specs of R4xx cards on ATI
website to find out how many actual pipes are
Vladimir Dergachev wrote:
The old initialization looks like yours, just with the radeon
version being 1.12.1 20041216
This would imply that, somehow, you are loading old radeon code.
Which command are you using to load it ?
Well, I ran make in the linux-core directory, and than copied drm.ko
Roland Scheidegger wrote:
here's a patch which mainly does 3 things:
- convert sis, mach64, and radeon to spantmp2.
The sis and mach64 drivers got a slight change, previously you could not
read back alpha values (always 0xff) and I don't think there was a good
reason for that?
IIRC, the mach64
On Thu, 3 Mar 2005, Rune Petersen wrote:
With the latest changes to drm in r300_driver I was reminded of a few
problems with R420 cards and the r300 driver.
1) the Xorg driver defaults to R200 for R420 cards.
RADEONDRIKernelInit() in radeon_dri.c
Could you test that your patch works with
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting the
module I get :
[drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory!
[drm:radeon_do_cleanup_cp] *ERROR* failed to cleanup PCI GART!
That's
Vladimir Dergachev writes:
You can just run gdb on the problem. I have seen these segfaults before -
they appear to be due to the fact that despite the name we do not
implement vertex buffer extension properly..
It turns out bzflag doesn't always segfault, only if I try to turn the
Blending
On Thu, Mar 03, 2005 at 06:49:26PM +0100, Roland Scheidegger wrote:
Ville Syrjälä wrote:
On Thu, Mar 03, 2005 at 05:45:15PM +0100, Roland Scheidegger wrote:
Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to
Hi,
I gave q3demo a try and to my surprise there was no artifacts.
This must have been fixed by one of the many changes.
Does this only work for me? Or is it time to update the status page?
Rune Petersen
---
SF email is sponsored by - The IT
Rune Petersen wrote:
Hi,
I gave q3demo a try and to my surprise there was no artifacts.
This must have been fixed by one of the many changes.
Does this only work for me? Or is it time to update the status page?
I can't actually run q3 anymore to test it (no ioctl32), but I no longer
get artifacts
Vladimir Dergachev writes:
The new call is an attempt to get multitexturing working, at least partly.
Does your program use multitexturing ? (Also where can I download it for
testing ? ) Thank you !
The screenshots I posted were from Emilia pinball from the Debian
pinball package. The
Oh, but I was not suggesting that. I just meant that interrupt handling
code is self-contained and can easily serve several consumers.
I'm with you here. And the same should IMHO hold for DMA handling. And for
memory management of course.
DMA handling is the main piece of what the DRM
Dieter Nützel wrote:
Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger:
Roland Scheidegger wrote: here's a patch which mainly does 3
things: - convert sis, mach64, and radeon to spantmp2. The sis and
mach64 drivers got a slight change, previously you could not read
back alpha values
This extension can't be easily/cleanly added to Mesa without rewriting
and changing some existing code. But ultimately, the changes will be
for the better, much in the way that GL_NV/ARB_vertex_program improved
the TNL code.
I'll assume people are familiar with GL_EXT_framebuffer_object. If
Michel Dnzer wrote:
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI drivers dated 25 february 2005
On Fri, 4 Mar 2005, Paul Mackerras wrote:
Vladimir Dergachev writes:
Does everything work with vb mode ? (you can switch to it in the end of
r300_driver/r300/r300_render.c, search for #else)
Most things seem to work, except bzflag segfaults. I could try to
track down where tonight if that would
Adam K Kirchhoff wrote:
Any idea why the PCI IDs for the radeon 9800 were removed from the DRM?
AFIK most/all IDs added were lost when the DRM was updated.
No special reason.
Rune Petersen
---
SF email is sponsored by - The IT Product Guide
Read
Could you test that your patch works with regular freedesktop.org DRM
driver as far as 2d is concerned ? It should print a message in the log
that DRI is enabled, though, of course, you would not be able to use R300
Mesa driver.
I gave it a try, no problem.
patch: r420_drm-microcode-fix.patch
I
Stephane Marchesin wrote:
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting
the module I get :
[drm:radeon_ati_pcigart_cleanup] *ERROR* no scatter/gather memory!
[drm:radeon_do_cleanup_cp] *ERROR* failed to
On Sat, 5 Mar 2005, Ben Skeggs wrote:
Rune Petersen wrote:
Hi,
I gave q3demo a try and to my surprise there was no artifacts.
This must have been fixed by one of the many changes.
Does this only work for me? Or is it time to update the status page?
I can't actually run q3 anymore to test it (no
Also I believe we are still not doing correct things in many cases,
especially as pixel shaders are concerned (no Gourad, multitexturing messed
up).
I believe I now have a good understanding of how to implement multitexturing
properly,
I could be wrong. But I'll find out very shortly.
I'm
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
Vladimir Dergachev wrote:
Also I believe we are still not doing correct things in many cases,
especially as pixel shaders are concerned (no Gourad, multitexturing
messed up).
I believe I now have a good understanding of how to implement
multitexturing properly,
I could be wrong. But I'll find
Vladimir Dergachev wrote:
Why do you the value is 7 ? According to my docs the number of pipes
is a magic value that should be architecture dependent. Of course, my
documentation is for R300 2d only..
I would expect that there is no easy formula.
The 7 came from fglrx using radeon_dump.
Ahh !
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,
On Fri, 4 Mar 2005, Paul Mackerras wrote:
Vladimir Dergachev writes:
You can just run gdb on the problem. I have seen these segfaults before -
they appear to be due to the fact that despite the name we do not
implement vertex buffer extension properly..
It turns out bzflag doesn't always
Why do you the value is 7 ? According to my docs the number of pipes is a
magic value that should be architecture dependent. Of course, my
documentation is for R300 2d only..
I would expect that there is no easy formula.
The 7 came from fglrx using radeon_dump.
Ahh ! In this case it should be
On Thu, 3 Mar 2005, Paul Mackerras wrote:
Jerome Glisse writes:
If you find the guilty commit let me know :)
It appears to be this code in r300_state.c (line 1625):
#if 0
/* textures enabled ? */
if(rmesa-state.texture.tc_count0){
Vladimir Dergachev wrote:
On Sat, 5 Mar 2005, Ben Skeggs wrote:
Rune Petersen wrote:
Hi,
I gave q3demo a try and to my surprise there was no artifacts.
This must have been fixed by one of the many changes.
Does this only work for me? Or is it time to update the status page?
I can't actually run
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
With which part ? ;)
On having a small stub module that does just IRQs ... I think the base
module should be the fbdev (mode setting etc...)
Oh, but I was not suggesting that. I just meant that interrupt handling
code is self-contained and can easily serve several consumers.
I'm with you here. And
On Sat, 5 Mar 2005, Ben Skeggs wrote:
Vladimir Dergachev wrote:
It is easier to get the format right when you are adding it (and know which
entry you are messing is), rather than add it blindly and then find out
that a couple of components are in the wrong order.
I'm not entirely sure of how
On Thu, Mar 03, 2005 at 08:10:33PM +0100, Roland Scheidegger wrote:
Ville Syrjälä wrote:
Like I said before only the RGB components are blended. You can
choose to write 0, 1, As, 1-As, Ad or 1-Ad to the destination
alpha ([EMAIL PROTECTED] register). Currently the
driver seems to write 0. It
Brian Paul wrote:
Roland Scheidegger wrote:
here's a patch which mainly does 3 things: - convert sis, mach64,
and radeon to spantmp2. The sis and mach64 drivers got a slight
change, previously you could not read back alpha values (always
0xff) and I don't think there was a good reason for that?
On Thu, 2005-03-03 at 20:22 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
On Wed, 2005-03-02 at 16:11 +0100, Marcello Maggioni wrote:
When using HW TCL in Tuxracer or PPRacer (that is essentially the same
game) with my Radeon 8500 with DRI drivers dated 25 february 2005 you
can see
Ian Romanick wrote:
Brian Paul wrote:
I'll assume people are familiar with GL_EXT_framebuffer_object. If
not, read the spec.
If you still have questions after reading the spec, you can ask me on
#dri-devel on freenode. I try to be on there as often as I can.
The gl_renderbuffer's BaseFormat
Am Dienstag, 1. März 2005 19:46 schrieb Roland Scheidegger:
Dieter Nützel wrote:
Looking a bit at this, this seems to be caused because the number of
pixels to read can be less than zero after CLIPSPAN (don't know if
that's a bug in itself or not).
That was my first thought, too (moving
Am Donnerstag, 3. März 2005 20:36 schrieb Roland Scheidegger:
Dieter Nützel wrote:
Am Donnerstag, 3. März 2005 4:48 schrieb Roland Scheidegger:
Roland Scheidegger wrote: here's a patch which mainly does 3
things: - convert sis, mach64, and radeon to spantmp2. The sis and
mach64 drivers
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 == CHIP_FAMILY_RV350) ||
+ (info-ChipFamily ==
On Friday, March 4, 2005 6:20 am, Stephane Marchesin wrote:
Stephane Marchesin wrote:
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting
the module I get :
[drm:radeon_ati_pcigart_cleanup] *ERROR* no
Jesse Barnes wrote:
On Friday, March 4, 2005 6:20 am, Stephane Marchesin wrote:
Stephane Marchesin wrote:
Hi,
I upgraded drm (non core) to current cvs (previous one was from
2004-07-15) on an ia64 with a radeon 7000 (pci) and now on inserting
the module I get :
[drm:radeon_ati_pcigart_cleanup]
On Fri, 4 Mar 2005, Michel [ISO-8859-1] Dänzer 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 ==
Some ia64 platforms may not support write combining on all type of memory, so
we need to consult the EFI memory map before we try to set the write combine
attribute of a page. This patch will try to map a page write combined if
it's not an AGP page and the EFI memory map says it's ok,
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 ==
On Friday, March 4, 2005 10:31 am, Jesse Barnes wrote:
Seems like we need something like this instead?
Index: linux-core/drm_dma.c
===
RCS file: /cvs/dri/drm/linux-core/drm_dma.c,v
retrieving revision 1.39
diff -u -r1.39
On Fri, 2005-03-04 at 13:53 -0500, 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) ||
-
This simple patch makes it a little easier to build against arbitrary drm
trees. It'll pull in DRM_SOURCE_PATH from the environment if set, otherwise
it'll default to it's current value.
Jesse
Index: configs/default
===
RCS file:
I got this error when I tried to build linux-solo-ia64:
gcc -c -I. -I../../../include -I../../../src/mesa -I../../../src/mesa/main
-I../../../src/mesa/glapi -I../../../src/mesa/math
-I../../../src/mesa/transform -I../../../src/mesa/swrast
-I../../../src/mesa/swrast_setup
there will be any chips in the future for which neither of the current
choices work, the DRI will likely have to be disabled for them anyway.
As for DRIScreenInit - I looked at the code again and its logic appears
correct to me, could you elaborate a bit where you would like the R300
check to
On Fri, 2005-03-04 at 15:18 +0200, Ville Syrjälä wrote:
On Fri, Mar 04, 2005 at 09:08:27AM +1100, Benjamin Herrenschmidt wrote:
Oh, but I was not suggesting that. I just meant that interrupt handling
code is self-contained and can easily serve several consumers.
I'm with you
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2516
--- Additional Comments From [EMAIL PROTECTED] 2005-03-04 16:48 ---
Some
Stephane Marchesin writes:
Ok, it looks like drm cvs (core and non core) has been broken on ia64
since august. Patch attached.
Stephane
Index: linux/drm_bufs.h
===
RCS file: /cvs/dri/drm/linux/drm_bufs.h,v
retrieving
Vladimir Dergachev writes:
We should probably have analogous code for r300.
Do you mean we should have swtcl code for r300, or something else?
Paul.
---
SF email is sponsored by - The IT Product Guide
Read honest candid reviews on hundreds
On Sat, 5 Mar 2005, Paul Mackerras wrote:
Vladimir Dergachev writes:
We should probably have analogous code for r300.
Do you mean we should have swtcl code for r300, or something else?
There are two issues:
1. As was explained to me we need to have swtcl code in case we need
to do
Paul Mackerras wrote:
Note that that check is also wrong for ppc64. I think it is going to
be wrong for most 64-bit platforms, since it is assuming that you can
never have ram at a higher physical address than any I/O devices. On
64-bit platforms it is quite common to have some ram and some I/O
Jesse Barnes wrote:
Ok, so I've got everything built and the sample server starts (after applying
the attached patch):
[EMAIL PROTECTED] miniglx]# ./sample_server
[miniglx] probed chipset 0x4e4b
got MMIOAddress 0x20001090 offset 268435456
[drm] added 65536 byte SAREA at
You also have to add the file, memops.h, to src/mesa/drivers/dri/comon
I've added powerpc ia64 for now. Let me now if other archs need this too.
committed...
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
Linux kernel - DRI, VAX / pam_smb /
radeon.ko to /lib/modules.../char/drm. This time I even did a reboot
afterwards, to check that everything will work. After the reboot I ran
`modprobe radeon`.
Try using insmod with explicit path specification - this is what I do.
You must have leftover radeon.ko someplace.
It seems I did have
57 matches
Mail list logo
