Jerome Glisse wrote:
Hi,
My Machine
Powerbook G4
ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] 64MB
Ubuntu Hoary (kernel 2.6.10)
The drm module doesn't seem to work any longer for me. Drm loads without
error but I don't get the normal microcode message. r300_demo now seg
faults when it
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
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
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
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
[EMAIL PROTECTED] wrote:
Thank you for the advice. The problem I had before with the DRM
modules (drm.ko and radeon.ko) from the r300 CVS was that drm.ko would
load fine but loading radeon.ko was causing my computer to lock up
after a kernel panic. I had tried it rebuilding both it and the
Roland Scheidegger wrote:
Wasn't the limit 2560x2560 with the r300 based chips? That's at least
what fglrx will do on r300.
The limit seems to be 2560 on r300 (high end) cards, but 2048 on rv300
cards (these cards really look like they have exactly the same tiling
regs as r200).
Stephane
Vladimir Dergachev wrote:
fglrx will do on r300. I'm wondering about that though a bit, that
would be 11.3 bit for coords or so ;-). It would also mean the tiling
regs need to be different a bit on r300 compared to r100/r200.
I looked through the register manual for Radeons and it looks like
Roland Scheidegger wrote:
Since people have asked for it, I decided I'd give it a try...
So here it is, a unified radeon driver (no not r300, only r100 and r200).
http://homepage.hispeed.ch/rscheidegger/dri_experimental/ati_radeon.tar.bz2
exectuable generated will be called radeon_dri.so, for
Dario Laera wrote:
Ben Skeggs wrote:
Hello,
I've attached a patch with a port of the r200 vertex buffer code for
the r300 driver.
The performance of the vertex buffer codepath is now roughly the same
as the
immediate path, and tuxracer now seems to be rendered almost correctly.
I've tried it on
Dieter Ntzel wrote:
r100-readpixels-3.patch (Stephane)
r200_pntparam_1.diff (Roland)
I'm ran with both.
Should they merged?
I surely hope to get my readpixels patch merged. However, I found a
serious flaw in it (not related to the readpixe segfault) which I have
to fix before this happens.
Hi,
I suspace zcache flushing before fast zclears is not needed on r100 (and
removing it adds a couple of q3 frames :).
This patch removes it for these chips. It works fine on rv100, but I
wonder if it does on r100/rv200 too.
So, testing is welcome !
Stephane
Index: shared/radeon_state.c
Hi,
Attached is a straight port of Eric's fix for the drm race to non-core drm.
Stephane
Index: shared/radeon_drv.h
===
RCS file: /cvs/dri/drm/shared/radeon_drv.h,v
retrieving revision 1.40
diff -u -r1.40 radeon_drv.h
---
Roland Scheidegger wrote:
Ok, I was FINALLY able to come up with something for texture tiling
which seems to work - this was very very annoying, it _almost_ worked
literally within minutes, but I needed a lot of time until it finally
did really work.
I needed to convert back the drivers to use
Roland Scheidegger wrote:
I suspect that quite the contrary, almost noone has crashes. This is
probably part of the problem, if they happen only for few people with
very specific configurations, none of the developers can reproduce it
and it will just remain unfixed.
For reference, I never get
Jacek Rosik wrote:
Dnia 29-01-2005, sob o godzinie 21:38 +0100, Stephane Marchesin
napisa(a):
Jacek Rosik wrote:
Would 7000 PCI be a rv100? I think I have one somewhere. Without depth
tiling my Idea should be simpler to implement.
Yes. But, I'd like to have hyperz enabled by default soon, so
Jesse Barnes wrote:
On Saturday, January 29, 2005 4:38 pm, [EMAIL PROTECTED] wrote:
When I use solo on ia64, it sometimes causes an MCA upon startup. That's
because a memset is done on the framebuffer memory during init.
Please refer to this message from Jesse Barnes to know why this is bad :
Jesse Barnes wrote:
On Monday, January 31, 2005 12:00 pm, Stephane Marchesin wrote:
Yes, other drivers suffer from that too (at least r128, i810 and mga as
far as I can see). However, as I said previously I don't understand them
enough to touch them.
Oh, I must have missed that message, sorry
Jacek Rosik wrote:
Hi
Dnia 29-01-2005, sob o godzinie 02:29 +0100, Stephane Marchesin
napisa(a):
Roland Scheidegger wrote:
I don't quite follow third line before last? Can someone enlighten me?
You mean the pitch 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each
Roland Scheidegger wrote:
I don't quite follow third line before last? Can someone enlighten me?
You mean the pitch 0x20 stuff? Yeah, looks strange.
Looking at it, it seems like it ensures that each block line starts
with alternating 2KB addresses (i.e. that 11th-bit). So y 0-15 will
have set
Michel Dnzer wrote:
fixed a copy paste error in the non-core drm version, and it actually
auto-refreshes the screen when switching between a tiled and untiled resolution...
Nice.
What happened to Stephane's surface allocator, BTW? If you just whack
the surface registers directly from the X
Jesse Barnes wrote:
I figured other projects might have similar problems, thanks for checking dri.
Please note that I didn't actually check the dri. I just happened to get
an MCA from time to time at mesa solo startup and your post on the SDL
list showed a possible reason to me.
I already
[from the SDL maling list]
Jesse Barnes wrote:
I noticed that on my ia64 machine when SDL_Quit was called, the machine would
hang in weird ways. It turned out to be caused by a machine check in the
memset() call near the top of FB_VideoQuit. Generally memset shouldn't be
used on I/O regions
Hi,
When fixing depth reads on rv100, I found that my zbuffer wasn't tiled
by default.
Is this a known fact ? Is there a way to enable/disable depth tiling on
this card ?
Stephane
---
The SF.Net email is sponsored by: Beat the post-holiday
Hi,
In the drm, I found that the memory allocator can handle both gart
(RADEON_MEM_REGION_GART) and fb (RADEON_MEM_REGION_FB) memory.
However, the second type is never used. Is there a reason for that ?
Stephane
---
The SF.Net email is
Dave Airlie wrote:
Okay some people have commented on the DRM CVS of late, and are unsure of
what is happening with it,
I'm very willing to drop the shared and linux directories into an archived
area but that will stop all support for Linux 2.4,
Are some changes underway that might make 2.4 hard
Michel Dnzer wrote:
+ // allocate the surface
+ for(i=0;i8;i++)
+ if (!(dev_priv-surfaces(1i)))
+ break;
+
+ if (i=8)
+ return DRM_ERR(ENOMEM);
+ else
+ dev_priv-surfaces=(1i);
+
+ if ( DRM_COPY_TO_USER( alloc.surface, i,
+ sizeof(int) ) ) {
+ DRM_ERROR( copy_to_user\n );
+
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted feedback
(both on the idea and the implementation) before I build anything upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a better idea with some card
Keith Whitwell wrote:
Dave Airlie wrote:
Any comments ? I'ts untested, but that's my first ioctl, so I wanted
feedback
(both on the idea and the implementation) before I build anything
upon it.
I'm thinking this could be applicable to a number of devices, so maybe a
generic ioctl might be a
Hi,
The small attached patch adds a new drm ioctl to do surface
allocation/deallocation on the radeon.
The reason to add a new ioctl is the following : since there are only 8
surfaces someone has to arbitrate between allocations by the ddx (color
buffers) and from the dri (depth buffers).
Hi,
Attached is a patch that adds pci init code for mesa solo on radeon.
It's been tested on an itanium 2 with a radeon 7000 and it works here.
The patch adds a new field in the miniglx.conf config file, to choose
between pci and agp.
Stephane
Index: src/glx/mini/driver.h
Stephane Marchesin wrote:
Fully? Was HyperZ only missing feature?
There are at least 2 other features :
- pixel shaders (ATI_fragment_shader). It's R200 only.
- occlusion culling (ARB_occlusion_query and friends). Same on R100
and R200. I started working on this one and know the registers numbers
Jacek Popawski wrote:
On Thu, Dec 02, 2004 at 08:49:56AM -0500, Alex Deucher wrote:
Radeon 9000 PCI
Radeon 9200se AGP
these two chips are already fully supported by xorg and the DRI.
Fully? Was HyperZ only missing feature?
There are at least 2 other features :
- pixel shaders
Brian Paul wrote:
We probably need Mesa driver hooks for BeginQuery() and EndQuery(). I
could implement that pretty quickly. Let me know.
Well, I have that done already. My current problems are :
- fix the XXX revisit when we have a hardware implementation!. i.e.
how to get the query status
Dieter Ntzel wrote:
Hmmm. It works, but there is a bit that we'll probably leave aside on
the R200 (hierarchical Z) because neither Roland nor me have an R200.
What do you need (apart from the hardware, at the moment ;-)?
Basically, the problem is that hierarchical z stores z values using 8
bits.
Rogier Stam wrote:
Hi guys,
I tried testing the HyperZ patch, but I ran into some problems. First
of all, my configuration is Xorg 6.8.0 pulled out of CVS on
20/10/2004, with the HyperZ patch installed (found at the following
links :
Ok, here is a new patch.
Stephane
diff -x CVS -Naur ../../../../../Mesa.orig/src/mesa/drivers/dri/common/clip.h
./common/clip.h
--- ../../../../../Mesa.orig/src/mesa/drivers/dri/common/clip.h 1970-01-01
01:00:00.0 +0100
+++ ./common/clip.h 2004-11-16 01:01:55.0 +0100
@@ -0,0
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
Brian Paul wrote:
I guess I'd like to see the clipping issues resolved before checking
in the patch.
Ok, I'm not sure I understood what you expect, but here is what I did :
I used the mesa window space clipping routines and then added a
dri/common/clip.h file that does the screen clipping.
Brian Paul wrote:
I guess I'd like to see the clipping issues resolved before checking
in the patch.
Ok, I'm not sure I understood what you expect, but here is what I did :
I used the mesa window space clipping routines and then added a
dri/common/clip.h file that does the screen clipping.
Brian Paul wrote:
I'll be checking in a fix for this soon.
I've replaced the _swrast_clip_pixelrect() functions with two new
functions: _mesa_clip_readpixels() and _mesa_clip_drawpixels(). The
main difference is the later one obeys the scissor rectangle.
The DRI drivers might use
Hi,
The attached patch adds readpixel acceleration to the r100 based on
what's done for the r200.
This speeds-up readpix by a factor of 2 on x86, and much more on non-x86
systems which don't benefit from Ian's patch (like 8 times on itanium 2).
Stephane
diff -Naur radeon.old/Makefile
Dieter Nützel wrote:
Am Donnerstag, 4. November 2004 23:09 schrieb Roland Scheidegger:
(sorry for sending this first to the wrong list. replies should be in
dri-devel, not mesa3d-dev.)
Here's an updated version of the patch, which should work on more cards.
Specifically, it works on my rv250,
Michel Dnzer wrote:
Can this really be a per-context option, considering that the depth
buffer is shared by all contexts?
No. Where do you put global options ?
Stephane
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition -
Dieter Nützel wrote:
Am Dienstag, 2. November 2004 02:11 schrieb Stephane Marchesin:
Hi,
The attached patches enable HyperZ on radeon (RV100 only for now).
People always ask me for an HyperZ benchmark, so :
HyperZ gets me 45% more fps (48 fps - 70 fps) in Quake3 four.dm68
(Radeon 7000, athlon XP
Keith Whitwell wrote:
Stephane,
Very impressive! I take it this has been derived from
reverse-engineering the ati driver?
How stable is this code now how much testing has it had?
I've been using it for one month with different OpenGL apps (mostly
Quake 3 friends, also tried most things in
Dave Airlie wrote:
I've quickly patched this into my devel tree for an in-house app, and it
don't look to work so well... the card is a mobility M7 7500 so it should
work..
Radeon 7500 is RV200, and I have a RV100. Maybe we've found one
difference between RV200 and R100 after all :)
I see a lot
Hi,
The attached patches enable HyperZ on radeon (RV100 only for now).
People always ask me for an HyperZ benchmark, so :
HyperZ gets me 45% more fps (48 fps - 70 fps) in Quake3 four.dm68
(Radeon 7000, athlon XP 2600).
It also speeds up glxgears from 450 fps to 1300 fps, which shows how
useless
Hi,
It seems this change breaks the build (at least removing it makes it
compile again for me) :
http://freedesktop.org/cgi-bin/viewcvs.cgi/mesa/Mesa/src/mesa/tnl_dd/t_dd_vbtmp.h?r1=1.3r2=1.4
While making linux-dri-x86 :
gcc -c -I. -I../../../../../src/mesa/drivers/dri/common -Iserver
Eric Anholt wrote:
Same thing as for r200, but for r100. Effects are even better,
according to ipers. Anyone want to do some testing before I commit?
It breaks the textures for me under quake3 with a radeon 7000. Maybe
that's the culprit for the texture problems on r200, too.
Stephane
Dieter Nützel wrote:
This gets about a 5% speedup for me in ipers (which I wish was more
accurate in its reporting), and doesn't touch glxgears. I didn't have
any interesting apps besides glxgears handy to benchmark with. Any
thoughts on this? If people think it's a good idea, I'll do it for
Hi,
I've enabled color tiling on the radeon. However, since you have to put
the crtc in tiling mode to compensate the effect, this can only be used
in fullscreen (or you're screwing everything around the 3D window).
Thus my question : how can I reliably detect fullscreen operation from
the
Alex Deucher wrote:
On Fri, 27 Aug 2004 01:01:23 +0200, Stephane Marchesin
[EMAIL PROTECTED] wrote:
Hi,
I've enabled color tiling on the radeon. However, since you have to put
the crtc in tiling mode to compensate the effect, this can only be used
in fullscreen (or you're screwing everything
Alex Deucher wrote:
On 23 Aug 2004 18:30:01 -, Ian Romanick [EMAIL PROTECTED] wrote:
This is just a friendly reminder that the weekly dri-devel IRC meeting will
be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or
5:00PM EDT or 2:00PM PDT, if you prefer).
Time zone
Ian Romanick wrote:
Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns
a pointer to a dispatch function. If you request an unknown function,
it will dynamically generate a dispatch for it. Try calling
'glXGetProcAddressARB((const GLubyte*)glThisFunctionDoesntExist);.
Ian Romanick wrote:
So, for whatever reason, size_t is used in drm.h in several structures
that are shared between user and kernel. HOWEVER, xf86drm.h uses int
in those places. Is it safe to assume sizeof(int) == sizeof(size_t)?
Well, on ia64, sizeof(size_t)==8, while sizeof(int)==4
Stephane
Jon Smirl wrote:
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look quit
right. When one is used in context-gl.get_program_iv_arb() it segfaults. I'm
using an R128 which does not have hardware shaders.
Should these calls be returning values as
Dieter Nützel wrote:
I get this with current Mesa CVS and DRI CVS for r200:
[snip errors]
Sorry, a correct patch is attached. Note that to try it, you need :
- to draw less than 64KB of pixels (that is ~16000 RGBA8 pixels)
- to specify glPixelZoom(1.F,-1.F);
- to use the correct pixel format :
Hi,
The attached patch adds pci init code for mesa solo with the radeon
driver thanks to a new configuration option in miniglx.conf.
Stephane
Index: src/glx/mini/driver.h
===
RCS file: /cvs/mesa/Mesa/src/glx/mini/driver.h,v
Stephane Marchesin wrote:
Hi,
The attached patch adds pci init code for mesa solo with the radeon
driver thanks to a new configuration option in miniglx.conf.
And of course, you're not interested in my debugging printf's. A patch
without my printfs is attached.
Sorry for the noise.
Stephane
I think I saw a document on how to build a bare Mesa driver, but I don't
seem to find it anymore - could someone e-mail me a link ?
I vaguely remember it talking about needing a Context function and at
least two functions to read and write pixel.
I think you're talking about this wiki
Hi,
I've been trying to get {read,draw}pixels acceleration for the r100 driver by adapting
existing code from the r200 and adding a temporary dma buffer. So I've made this
little patch to the r200 driver that's supposed to accelerate drawpixels using dma.
However a similar patch doesn't work
101 - 162 of 162 matches
Mail list logo
