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 bl
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).
>
> http://hom
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 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 have
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
gengeto
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 scree
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=""
gen
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
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).
h
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 !
Vl
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
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
On Fri, 2005-01-14 at 18:48 +0100, Jerome Glisse wrote:
> On Fri, 14 Jan 2005 12:23:50 -0500, Michel DÃnzer <[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 IN
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
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 connec
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 ha
On Thu, 2005-01-13 at 19:17 -0800, Steve P. Shack wrote:
> 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 conne
On Friday, January 14, 2005 11:43 am, Stephane Marchesin wrote:
> [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
[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 li
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 (Michel
> > > 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 r30
Hi Jerome,
I tried glxgears, nehe lessons (5,6,7), and a couple screen savers. They
all drew inside the window, only thing a noticed was on lessons 6 & 7
textures were red, not sure if thats how the current driver was
displaying them to begin with, since I was just getting "static" looking
texture
>Hi Jerome,
>
>I tried glxgears, nehe lessons (5,6,7), and a couple screen savers. They
>all drew inside the window, only thing a noticed was on lessons 6 & 7
>textures were red, not sure if thats how the current driver was
>displaying them to begin with, since I was just getting "static" looking
>
On Fri, 14 Jan 2005 12:23:50 -0500, Michel Dänzer <[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
> > server/radeon_macros.h have to do endian swapp
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 XF86DRI
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
26 matches
Mail list logo