Hi,
So with the patch attached r300 dri work on PPC :)
The vertex buffer co still not work (at least do not seems)
Putting anything to 0x2140 do no seems to change anythings
but as my own copy became a mess i will retry this.
Anyway i wanted to ask mesa folks how to make a real
proper patch. The
Currently, dri drivers don't have a version number, and the server-side
dri code thus cannot refuse to load a driver if the respective ddx code
needs a new dri driver. So, would it be helpful to implement version
numbers in dri and introduce a a new dri function (Michel Dänzer
suggested
On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
Anyway i wanted to ask mesa folks how to make a real
proper patch. The fact is that INREG OUTREG in
server/radeon_macros.h have to do endian swapping.
Moreover the swapping is only needed for r300, isn't it ?
So do
Roland Scheidegger wrote:
Currently, dri drivers don't have a version number, and the server-side
dri code thus cannot refuse to load a driver if the respective ddx code
needs a new dri driver. So, would it be helpful to implement version
numbers in dri and introduce a a new dri function
[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
On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
Anyway i wanted to ask mesa folks how to make a real
proper patch. The fact is that INREG OUTREG in
server/radeon_macros.h have to do endian swapping.
Moreover the swapping is only needed for r300, isn't it ?
So do we need to have our
tor, 13,.01.2005 kl. 19.17 -0800, skrev Steve P. Shack:
This is an interesting bug I've come across. When using the Radeon
graphics driver doing full screen 3d on a DVI port. Output is only
displayed at 1280x1024 (native) resolution for the display.
Plug the display into the D-sub connector,
Roland Scheidegger wrote:
2b) same as above, but tweak the client-side ddx version check to allow
for ranges of ddx major versions instead of a single ddx major version
(so new dri drivers can work with both old and new ddx, but new ddx will
still require new dri driver).
2c) same as above, but
On Fri, 2005-01-14 at 18:48 +0100, Jerome Glisse wrote:
On Fri, 14 Jan 2005 12:23:50 -0500, Michel Dnzer [EMAIL PROTECTED] wrote:
On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
Anyway i wanted to ask mesa folks how to make a real
proper patch. The fact is that INREG OUTREG in
On Fri, 2005-01-14 at 19:51 +0100, Jerome Glisse wrote:
I will try your patch but i bet it works.
I am agree too that this should not be in driver specifique but how to
handle the r300 case properly on ppc ?
There's no 'r300 case'. This will be the same for all Radeons and
On Fri, 2005-01-14 at 16:47 +0100, Roland Scheidegger wrote:
1) ignore the problem. This might be ok if the ddx is only incompatible
when a certain option is enabled, as long as it stays off by default
maybe (i.e. user has enabled the option, so assume he knows what he's
doing and he can
Hi all,
A hopefully easy question:
Is there a simple way to find out which vectors I need to upload to
the hardware ? I am hoping for some flags that, when set, indicate I need
to upload color[1], color[2], normals, etc.
thank you !
Alex Deucher wrote:
On Thu, 13 Jan 2005 15:25:46 +0100, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Ok, here's a new version. It also contains a supposed patch for
mergedfb-pageflip (untested, but I need that for color tiling, otherwise
I'd need to redo the crtc address calculation in the drm).
Vladimir Dergachev wrote:
On Wed, 12 Jan 2005, Adam K Kirchhoff wrote:
So I've finally tested the r300_driver on my 9800. Specifically it's a:
ATI Technologies Inc Radeon R350 [Radeon 9800]
Direct Rendering is enabled when X starts up. I'll attach the output
from glxinfo. glxgears -info gives
I can't get r300_demo to compile. Something with getgetopt:
ld -r xf86drm.o xf86drmRandom.o xf86drmSL.o xf86drmHash.o -o libdrm.o
make[1]: Leaving directory `/home/adamk/r300_demo/libdrm'
gengetopt r300_demo.ggo
gengetopt:9: parse error group
gengetopt:9: defgroup chip type groupdesc=
I took the time to compile the r300 driver and give it a whirl.
The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility
9600 M10. It has a device ID of 0x4e50.
glxgears runs with a 370-380 FPS.
r300_demo --triangles and --tex-triangles does not give me the same view
as the
On Fri, 14 Jan 2005, Adam K Kirchhoff wrote:
I can't get r300_demo to compile. Something with getgetopt:
ld -r xf86drm.o xf86drmRandom.o xf86drmSL.o xf86drmHash.o -o libdrm.o
make[1]: Leaving directory `/home/adamk/r300_demo/libdrm'
gengetopt r300_demo.ggo
gengetopt:9: parse error group
On Fri, 14 Jan 2005, D. Hageman wrote:
I took the time to compile the r300 driver and give it a whirl.
The machine is a Dell Laptop (Inspiron 9100) with a ATI Radeon Mobility 9600
M10. It has a device ID of 0x4e50.
glxgears runs with a 370-380 FPS.
Hmm.. There are two possibilities:
1. I
On Fri, 14 Jan 2005, Jerome Glisse wrote:
On Fri, 2005-01-14 at 16:34 +0100, Jerome Glisse wrote:
Anyway i wanted to ask mesa folks how to make a real
proper patch. The fact is that INREG OUTREG in
server/radeon_macros.h have to do endian swapping.
Moreover the swapping is only needed for r300,
On Thu, 13 Jan 2005 15:25:46 +0100, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Ok, here's a new version. It also contains a supposed patch for
mergedfb-pageflip (untested, but I need that for color tiling, otherwise
I'd need to redo the crtc address calculation in the drm).
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
21 matches
Mail list logo
