Re: IGP320M HyperZ Texture bugs
Hmmm that could be the difference with Rv100 and 200 cards :) Ah well,
I'll try the patch tonight
On Wed, 1 Dec 2004, Dieter [iso-8859-1] Nützel wrote:
> Am Mittwoch, 1. Dezember 2004 19:09 schrieb Dieter Nützel:
> > Am Mittwoch, 1. Dezember 2004 17:13 schrieb Rogier Stam:
> > > Dieter Nützel wrote:
> > > >Am Mittwoch, 1. Dezember 2004 02:48 schrieb
> >
> > [EMAIL PROTECTED]:
> > > >>Hi Roland,
> > > >>
> > > >>If you move glxgears down below about half of the screen you won't see
> > > >>anything anymore. Within the top half it looks about the same, although
> > > >>moving it from left to right can cause parts to appear or disappear.
> > > >>I'll check the offsets tonight.
> > > >
> > > >Soo, you are at 'my' r200 observation;-)
> > > >But at the bottom there are some pixels not all vanished.
> > > >Moving left to right or the like show sometimes some parts.
> > > >
> > > >Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life.
> > > >
> > > >/* if (rmesa->r200Screen->chipset & R200_CHIPSET_REAL_R200)
> > > > rmesa->hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |=
> > > >RADEON_Z_HIERARCHY_ENABLE; */
> > > >
> > > >I'm in preparation of a new Mesa/DRI CVS copy with
> > > >hyperz-dri-7.patch
> > > >hyperz-drm-15.patch
> > > >r100-readpixels-3.patch
> > > >r200_pntparam_1.diff
> > > >because all went well (with the above change), but quake3 (quake3-smp)
> > > > start with only black window. Maybe this is TLS related, which I have
> > > > in for several months, now.
> > > >
> > > >-Dieter
> > > >
> > > >PS Roland, do you need current r200 'pictures'?
> > >
> > > Actually, Roland had a suggestion regarding seting the tileoffset from
> > > *16 to *32. This helps a bit in my case. I suggest you also try this
> > > one. Maybe it will help for you too. It doesn't fix the entire problem,
> > > but it does make it better. Note that I also tried *24, *40, *48, *64
> > > and *128. *32 gives the most stable and also in picture the best result.
> > > The others definetly don't improve things...
> >
> > I'm playing with it, but all other then 16 (as far as i am ;-) give your
> > described results.
> >
> > Could you try this (from Roland, too) in the meantime.
> > I running my r200 with it since drm-15 came out.
> >
> > --- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
> > +++ radeon_state.c.aktuell 2004-11-13 14:08:32.0 +0100
> > @@ -894,7 +894,8 @@
> > }
> > else {
> > /* FIXME : reverse engineer that for Rx00 cards */
> > - clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f;
> > + /* clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f; */
> > + clearmask = 0x0;
>
> Now,
>
> I've tested with the above and
>
>OUT_RING( tileoffset * 16 );
>
> 8-17 (all steps), even 32 do NOT work.
>
> ONLY 16 works.
>
> -Dieter
>
---
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 hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[r200] Latest Mesa CVS brake quake3 (-smp)
Only empty/black window. Not r100-readpixels-3.patch or hyperz related. When I find time (tomorrow) I'll go back and see when it changed. -Dieter --- 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 hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP320M HyperZ Texture bugs
Dieter Nützel wrote:
Actually, Roland had a suggestion regarding seting the tileoffset from
*16 to *32. This helps a bit in my case. I suggest you also try this
one. Maybe it will help for you too. It doesn't fix the entire problem,
but it does make it better. Note that I also tried *24, *40, *48, *64
and *128. *32 gives the most stable and also in picture the best result.
The others definetly don't improve things...
I'm playing with it, but all other then 16 (as far as i am ;-) give your
described results.
Could you try this (from Roland, too) in the meantime.
I running my r200 with it since drm-15 came out.
--- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
+++ radeon_state.c.aktuell 2004-11-13 14:08:32.0 +0100
@@ -894,7 +894,8 @@
}
else {
/* FIXME : reverse engineer that for Rx00 cards */
- clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f;
+ /* clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f; */
+ clearmask = 0x0;
Now,
I've tested with the above and
OUT_RING( tileoffset * 16 );
8-17 (all steps), even 32 do NOT work.
ONLY 16 works.
That's not surprising. hyperz on r100, rv100, r200, rv250 REALLY works a
bit differently.
That said, I'll try to update the patch with a version which will work
on r100, rv250, and hopefully I get rv100 and r200 right. I'll ditch
hierarchical-z for now completely (even though it _mostly_ worked right
on the r100, there are too many unsolved issues about it).
Roland
---
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 hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP320M HyperZ Texture bugs
Am Mittwoch, 1. Dezember 2004 19:09 schrieb Dieter Nützel:
> Am Mittwoch, 1. Dezember 2004 17:13 schrieb Rogier Stam:
> > Dieter Nützel wrote:
> > >Am Mittwoch, 1. Dezember 2004 02:48 schrieb
>
> [EMAIL PROTECTED]:
> > >>Hi Roland,
> > >>
> > >>If you move glxgears down below about half of the screen you won't see
> > >>anything anymore. Within the top half it looks about the same, although
> > >>moving it from left to right can cause parts to appear or disappear.
> > >>I'll check the offsets tonight.
> > >
> > >Soo, you are at 'my' r200 observation;-)
> > >But at the bottom there are some pixels not all vanished.
> > >Moving left to right or the like show sometimes some parts.
> > >
> > >Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life.
> > >
> > >/* if (rmesa->r200Screen->chipset & R200_CHIPSET_REAL_R200)
> > > rmesa->hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |=
> > >RADEON_Z_HIERARCHY_ENABLE; */
> > >
> > >I'm in preparation of a new Mesa/DRI CVS copy with
> > >hyperz-dri-7.patch
> > >hyperz-drm-15.patch
> > >r100-readpixels-3.patch
> > >r200_pntparam_1.diff
> > >because all went well (with the above change), but quake3 (quake3-smp)
> > > start with only black window. Maybe this is TLS related, which I have
> > > in for several months, now.
> > >
> > >-Dieter
> > >
> > >PS Roland, do you need current r200 'pictures'?
> >
> > Actually, Roland had a suggestion regarding seting the tileoffset from
> > *16 to *32. This helps a bit in my case. I suggest you also try this
> > one. Maybe it will help for you too. It doesn't fix the entire problem,
> > but it does make it better. Note that I also tried *24, *40, *48, *64
> > and *128. *32 gives the most stable and also in picture the best result.
> > The others definetly don't improve things...
>
> I'm playing with it, but all other then 16 (as far as i am ;-) give your
> described results.
>
> Could you try this (from Roland, too) in the meantime.
> I running my r200 with it since drm-15 came out.
>
> --- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
> +++ radeon_state.c.aktuell 2004-11-13 14:08:32.0 +0100
> @@ -894,7 +894,8 @@
> }
> else {
> /* FIXME : reverse engineer that for Rx00 cards */
> - clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f;
> + /* clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f; */
> + clearmask = 0x0;
Now,
I've tested with the above and
OUT_RING( tileoffset * 16 );
8-17 (all steps), even 32 do NOT work.
ONLY 16 works.
-Dieter
---
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 hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP320M HyperZ Texture bugs
Am Mittwoch, 1. Dezember 2004 17:13 schrieb Rogier Stam:
> Dieter Nützel wrote:
> >Am Mittwoch, 1. Dezember 2004 02:48 schrieb
[EMAIL PROTECTED]:
> >>Hi Roland,
> >>
> >>If you move glxgears down below about half of the screen you won't see
> >>anything anymore. Within the top half it looks about the same, although
> >>moving it from left to right can cause parts to appear or disappear.
> >>I'll check the offsets tonight.
> >
> >Soo, you are at 'my' r200 observation;-)
> >But at the bottom there are some pixels not all vanished.
> >Moving left to right or the like show sometimes some parts.
> >
> >Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life.
> >
> >/* if (rmesa->r200Screen->chipset & R200_CHIPSET_REAL_R200)
> > rmesa->hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |=
> >RADEON_Z_HIERARCHY_ENABLE; */
> >
> >I'm in preparation of a new Mesa/DRI CVS copy with
> >hyperz-dri-7.patch
> >hyperz-drm-15.patch
> >r100-readpixels-3.patch
> >r200_pntparam_1.diff
> >because all went well (with the above change), but quake3 (quake3-smp)
> > start with only black window. Maybe this is TLS related, which I have in
> > for several months, now.
> >
> >-Dieter
> >
> >PS Roland, do you need current r200 'pictures'?
>
> Actually, Roland had a suggestion regarding seting the tileoffset from
> *16 to *32. This helps a bit in my case. I suggest you also try this
> one. Maybe it will help for you too. It doesn't fix the entire problem,
> but it does make it better. Note that I also tried *24, *40, *48, *64
> and *128. *32 gives the most stable and also in picture the best result.
> The others definetly don't improve things...
I'm playing with it, but all other then 16 (as far as i am ;-) give your
described results.
Could you try this (from Roland, too) in the meantime.
I running my r200 with it since drm-15 came out.
--- radeon_state.c.orig 2004-11-11 22:08:37.0 +0100
+++ radeon_state.c.aktuell 2004-11-13 14:08:32.0 +0100
@@ -894,7 +894,8 @@
}
else {
/* FIXME : reverse engineer that for Rx00 cards */
- clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f;
+ /* clearmask = (0xff<<22)|(0xff<<6)| 0x003f003f; */
+ clearmask = 0x0;
-Dieter
---
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 hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R100 readpixels acceleration
Am Mittwoch, 1. Dezember 2004 16:55 schrieb Brian Paul:
> Stephane Marchesin wrote:
> > Ok, here is a new patch.
>
> Looks OK. Someone with a Radeon card should test this with the
> Mesa/progs/demos/readpix.c demo. Drag the readpix window off the
> left/right/bottom/top edges of the screen and make sure things look
> OK. Be sure to test both the front and back color buffers ('f' key).
r200 (but with HyperZ):
Move it to the left...
progs/demos> ./readpix
GL_VERSION = 1.3 Mesa 6.3
GL_RENDERER = Mesa DRI R200 20041007 AGP 4x x86/MMX+/3DNow!+/SSE TCL
GL_OES_read_format supported. Using type / format = 0x1401 / 0x1908
Loaded 194 by 188 image
Speicherschutzverletzung
progs/demos>
progs/demos> ./readpix
GL_VERSION = 1.3 Mesa 6.3
GL_RENDERER = Mesa DRI R200 20041007 AGP 4x x86/MMX+/3DNow!+/SSE TCL
GL_OES_read_format supported. Using type / format = 0x1401 / 0x1908
Loaded 194 by 188 image
Speicherschutzverletzung
And redraw is sometimes broken or missing.
I've tried with r100-readpixels-2.patch and r100-readpixels-3.patch, now.
'gloss' is fine even if it was NOT related ;-)
But quake3 (quake3-smp) start with only black window.
-Dieter
---
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 hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VIA command verifier.
On Mer, 2004-12-01 at 12:19, Thomas HellstrÃm wrote: > Actually, I've been running with a 512Kb userspace / kernel buffer, and > I've not seen any noticable drop in performance, but I'm not sure that the > submissions actually will be that large with the programs I've tested. Might be worth finding the size needed - remembering a 512K buffer can be verified and copied in 32K chunks anyway. > If the perfomance drop I experience with running the verifier on AGP > memory is due to the fact that none of it is previously cached or that the > processor cannot cache WC memory lines while reading? If it is due to the > latter then we should be OK with large cacheable buffers. Otherwise we > will run into trouble when the buffer does not fit in the cache. AGP space is uncached. We could pull the pages out of AGP, write to them and put them back but we don't really support that right now. As a result all I/O to AGP pages is strictly synchronous. Pulling stuff from cachable memory and verifying it will prefetch lines from memory on the later processors (and you can also hint this with the prefetch(address) call in the kernel (prefetch about 320 bytes ahead is normally right). I'd expect the user pages are already in L2 cache anyway from when Mesa wrote the bits. --- 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 hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: IGP320M HyperZ Texture bugs
Dieter Nützel wrote: Am Mittwoch, 1. Dezember 2004 02:48 schrieb [EMAIL PROTECTED]: Hi Roland, If you move glxgears down below about half of the screen you won't see anything anymore. Within the top half it looks about the same, although moving it from left to right can cause parts to appear or disappear. I'll check the offsets tonight. Soo, you are at 'my' r200 observation;-) But at the bottom there are some pixels not all vanished. Moving left to right or the like show sometimes some parts. Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life. /* if (rmesa->r200Screen->chipset & R200_CHIPSET_REAL_R200) rmesa->hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |= RADEON_Z_HIERARCHY_ENABLE; */ I'm in preparation of a new Mesa/DRI CVS copy with hyperz-dri-7.patch hyperz-drm-15.patch r100-readpixels-3.patch r200_pntparam_1.diff because all went well (with the above change), but quake3 (quake3-smp) start with only black window. Maybe this is TLS related, which I have in for several months, now. -Dieter PS Roland, do you need current r200 'pictures'? Actually, Roland had a suggestion regarding seting the tileoffset from *16 to *32. This helps a bit in my case. I suggest you also try this one. Maybe it will help for you too. It doesn't fix the entire problem, but it does make it better. Note that I also tried *24, *40, *48, *64 and *128. *32 gives the most stable and also in picture the best result. The others definetly don't improve things... --- 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 hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R100 readpixels acceleration
Am Sonntag, 28. November 2004 16:47 schrieb Stephane Marchesin: > Dieter Nützel wrote: > > I've tested with r200 + r200_pntparam_1.diff (Roland's 'r200 large point > > sizes, ARB_point_parameters') patch. > > > > Get texture bug in 'gloss'. > > But only with 'cylinder' NOT with 'teapot'. > Ok, here is a new patch. > r100-readpixels-3.patch 'gloss' is fixed. Thanks, Dieter --- 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 hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R100 readpixels acceleration
Stephane Marchesin wrote:
Ok, here is a new patch.
Looks OK. Someone with a Radeon card should test this with the
Mesa/progs/demos/readpix.c demo. Drag the readpix window off the
left/right/bottom/top edges of the screen and make sure things look
OK. Be sure to test both the front and back color buffers ('f' key).
-Brian
---
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 hype. Start reading now.
http://productguide.itmanagersjournal.com/
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
On Wednesday 01 December 2004 07:11, Felix Kühling wrote: > Am Mi, den 01.12.2004 schrieb Adam Jackson um 5:27: > > I wasn't reading, sorry, I was blissfully afk over the holiday. > > > > The moinmoin version on fd.o is a good one, so we should be able to just > > copy our old wiki over. I'll see if I can't hit this before I skip town > > again. > > What about José's modifications? How important are they and how > difficult would it be to port them to the new version? I don't know what his mods were, but I would guess "not very". - ajax pgppZ3yTy2NxD.pgp Description: PGP signature
Re: IGP320M HyperZ Texture bugs
Am Mittwoch, 1. Dezember 2004 02:48 schrieb [EMAIL PROTECTED]: > Hi Roland, > > If you move glxgears down below about half of the screen you won't see > anything anymore. Within the top half it looks about the same, although > moving it from left to right can cause parts to appear or disappear. > I'll check the offsets tonight. Soo, you are at 'my' r200 observation;-) But at the bottom there are some pixels not all vanished. Moving left to right or the like show sometimes some parts. Disabling RADEON_Z_HIERARCHY_ENABLE bring all lines to life. /* if (rmesa->r200Screen->chipset & R200_CHIPSET_REAL_R200) rmesa->hw.ctx.cmd[CTX_RB3D_ZSTENCILCNTL] |= RADEON_Z_HIERARCHY_ENABLE; */ I'm in preparation of a new Mesa/DRI CVS copy with hyperz-dri-7.patch hyperz-drm-15.patch r100-readpixels-3.patch r200_pntparam_1.diff because all went well (with the above change), but quake3 (quake3-smp) start with only black window. Maybe this is TLS related, which I have in for several months, now. -Dieter PS Roland, do you need current r200 'pictures'? --- 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 hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: VIA command verifier.
> On Maw, 2004-11-30 at 20:09, Thomas Hellström wrote: >> Textures in AGP memory is currently not allowed, but they are disabled >> in the Mesa driver as well, for some reason. If they are allowed in the >> future, Texture address checks probably have to be implemented but that >> should be a minor task. > > I certainly turned them off because they were crashing my box in the > original "hey it sort of works" codebase. I don't know if its that or if > someone did more work on it later. > Nope, doesn't look like that from a quick glance. But there are obvious bugs in the texture memory allocation since the code fails to check properly that the allocation succeeded. >> The verifier is reasonably fast. It lowers the glxgears frame-rate a >> percent or two. However if it operates directly on AGP memory, it's a >> _real_ performance killer. So the userspace command buffer should be >> copied to kernel (static) system memory, checked and then copied again >> to the AGP ring-buffer. > > That should be fine if the command buffers are not too large (< 64K or > so) because they will be cached for the two passes. > Actually, I've been running with a 512Kb userspace / kernel buffer, and I've not seen any noticable drop in performance, but I'm not sure that the submissions actually will be that large with the programs I've tested. If the perfomance drop I experience with running the verifier on AGP memory is due to the fact that none of it is previously cached or that the processor cannot cache WC memory lines while reading? If it is due to the latter then we should be OK with large cacheable buffers. Otherwise we will run into trouble when the buffer does not fit in the cache. >> Comments are appreciated, particularly on the security assumptions and >> whether something doesn't fit well into the DRM coding style. > > Only real comment is that it would be better if the tables were > pre-initialized. gcc has some extensions for just specifying bits of an > array that might do this. Thats really it. > I planned to have the tables initialized as part of the module initialization, so it will never depend on an external master process initializing them, and there will be no chance of someone doing anything nasty before the verifier is initialized. I believe it's good for readability to have the command index right beside the intended action, and it will also be easier to extend / modify the code in this way. Thanks for the comments. /Thomas. --- 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 hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI web site at fd.o (was: Re: [Dri-users] snapshots status)
Am Mi, den 01.12.2004 schrieb Adam Jackson um 5:27: > On Monday 29 November 2004 17:03, Felix Kühling wrote: > > There is no dri.freedesktop.org yet. I think there is no need for a > > redirect. The current place is already different from where it was > > before the break-in (used to be in ~dri/snapshots now it's in > > dri/snapshots). If you could setup a dri.freedesktop.org that would be > > great. Maybe we could move our Wiki from sourceforge to the new > > location. Ajax, are you reading this? What do you think about upgrading > > to a newer MoinMoin version with ACLs while we're at it. > > I wasn't reading, sorry, I was blissfully afk over the holiday. > > The moinmoin version on fd.o is a good one, so we should be able to just copy > our old wiki over. I'll see if I can't hit this before I skip town again. What about José's modifications? How important are they and how difficult would it be to port them to the new version? > > - ajax -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- 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 hype. Start reading now. http://productguide.itmanagersjournal.com/ -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
