Re: [Mesa3d-dev] Re: Dramatic improvement of depth buffer quality
On Sat, Jan 01, 2005 at 10:21:24PM +0100, Felix Kühling wrote: > As to loss of accuracy with near objects, I havn't seen any such > problems yet with the applications I tested. OTOH, the improved > quality of far objects is very noticeable for instance in FlightGear > and TORCS. Off the top of my head, you might want to take a look at armagetron, it tends to have z-fighting problems with some hardware/low resolution z-buffers. Marcelo --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] noisy_cube snapshot
On Sun, 2 Jan 2005, Vladimir Dergachev wrote: Hi all, I just tagged the "noisy_cube" snapshot in R300 CVS. Changes: * includes supports for textures. Actual texture is substituted with random data (most resembling static - i.e. colored noise) Whoops, forgot - you can test this with lesson06 from http://nehe.gamedev.net/ I use Linux-SDL version, it compiles easily. best Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] noisy_cube snapshot
Hi all, I just tagged the "noisy_cube" snapshot in R300 CVS. Changes: * includes supports for textures. Actual texture is substituted with random data (most resembling static - i.e. colored noise) * I believe the lockup problem has been fixed ! Please test it on your hardware and let me know if you can get it to lockup (and how). thank you for testing ! Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Glossary
On Sun, 2 Jan 2005, Peter Karlsson wrote: On Sat, 1 Jan 2005, Vladimir Dergachev wrote: I have added a glossary page to the R300 website: http://r300.sf.net It is somewhat general in nature (not R300 specific) so I would appreciate comments (and corrections !) from everyone who has a chance to look. This is great! I've been looking for something like this. When it comes to dma doesn't the command processor also reside in "memory" (mmio)? The command processor is a part of the graphics chip. You might think of it as a sophisticated DMA engine. However, it is, indeed, accessed via MMIO interface. Also, if you would like me to put anything else there please let me know. Perhaps a simple overview of the dri/drm/mesa/X-relationship (which thing does what and so on)? On the other hand it might be good to put this (incl. the glossary) in the wiki on freedesktop instead? Take a look at http://gatos.sourceforge.net/dri-debug.php . As for wiki feel free to put links there.. best Vladimir Dergachev Best regards Peter K -- We Can Put an End to Word Attachments: http://www.fsf.org/philosophy/no-word-attachments.html --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: About the artifacts with r300_dri. (fwd)
In particular - could you check what kind of AGP speed is being used ? You were on the mark there. I'd neglected to put an AGPMode setting in my xorg.conf. agpgart was reporting that it was putting the bridge into 4x mode, so I assumed it was un-necessary. But, in my renderer string it was reporting AGP 1x. After adding the AGPMode "4" setting, the artifacts only appeared every now and then. From memory, I can't actually use AGP 8x with "radeon" can I? But, if I set AGPMode "8" in my config file, agpgart still says it's putting the bridge into 4x mode, and warns that the bridge doesn't support 8x (forced it to 4x in BIOS). But, now I have no artifacts whatsoever. I find that a little strange. Anyway, it all seems ok at the moment. AFAIK, there was code put in to allow AGP 8x - perhaps this "fixes" something in your card or BIOS. I suggest you try reenabling AGP 8x in BIOS, perhaps it would work better. best Vladimir Dergachev Good day, Ben Skeggs. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm CVS state...
On Fri, 2004-12-31 at 16:02 +0100, Felix Kühling wrote: > I was going to change mesa/src/mesa/drivers/dri/Makefile.template to use > the share-core directory for DRM includes. This will be needed for the > new Savage DRM as it lives in linux-core/shared-core only. With your > assessment of the status of the 2.4 DRM it looks like it will never be > backported to Linux 2.4. with this all applied, just left us checkout drm and mesa cvs and apply http://freedesktop.org/~fxkuehl/savage/savage_xorg_20041229.diff on xorg tree to test it ? I just check-out mesa and drm and compile with make linux-dri-x86 and cp lib/savage_dri.so /usr/X11R6/lib/modules/dri/savage_dri.so and recompile drm for my kernel 2.4.29-pre1, after reboot (to be sure that savage kernel module is loaded again), all works normally. thanks, -- Sérgio M.B. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Dramatic improvement of depth buffer quality
Am Sa, den 01.01.2005 schrieb Roland Scheidegger um 19:00: > Felix Kühling wrote: [snip] > I'm a bit sceptical that this really improves depth buffer quality in > general. With D3D it is (if the hw supports it) possible to use a w > buffer instead of a z buffer, which has the same precision for far and > near objects. However, the loss of precision for near objects was often > considered unacceptable. (Radeon R100 and R200 support this, but R300 > and up no longer do, or at least the driver doesn't expose it, so it > looks like it wasn't that useful after all, and not many applications > afaik requested w buffers). [... following up to my other reply ...] Another problem with W buffers is that linear depth interpolation doesn't give the correct results with intersecting surfaces. This is only achieved by the perspective division which is not applied to W (in fact the perspective division divides x, y and z by W). This makes W-buffers unsuitable for OpenGL. But this is not what I am proposing, just in case I was misunderstood. Reversing the depth range and using floating point numbers just changes the encoding of depth values in the depth buffer, it does not change the semantics, like a W-buffer would do. > > Roland -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Glossary
On Sat, 1 Jan 2005, Vladimir Dergachev wrote: > I have added a glossary page to the R300 website: > > http://r300.sf.net > >It is somewhat general in nature (not R300 specific) so I would > appreciate comments (and corrections !) from everyone who has a chance to > look. This is great! I've been looking for something like this. When it comes to dma doesn't the command processor also reside in "memory" (mmio)? >Also, if you would like me to put anything else there please let me > know. Perhaps a simple overview of the dri/drm/mesa/X-relationship (which thing does what and so on)? On the other hand it might be good to put this (incl. the glossary) in the wiki on freedesktop instead? Best regards Peter K -- We Can Put an End to Word Attachments: http://www.fsf.org/philosophy/no-word-attachments.html --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Dramatic improvement of depth buffer quality
Am Sa, den 01.01.2005 schrieb Albert Vilella um 23:03: > > The Savage hardware can handle W buffers too. In fact I experimented > > with that and the quality looks good. But it doesn't work under all > > circumstances. If the viewing transformation is changed in the middle of > > rendering a frame, the meaning of W changes and depth ordering is messed > > up. > > > > As to loss of accuracy with near objects, I havn't seen any such > > problems yet with the applications I tested. OTOH, the improved quality > > of far objects is very noticeable for instance in FlightGear and TORCS. > > As Vladimir pointed out, it might be a problem for CAD applications > > though. Making float depth a configuration option would be a good idea. > > And I will have to support both in the driver anyway, since > > Savage3D-based hardware doesn't support floating point depth buffers. > > Are this changes already on savage snapshots? If you mean binary snapshots, they are currently not being built. Eric Anholt is going to set up a new host for building them ASAP. If you're talking about CVS, the floating point z-buffer stuff is not committed yet. I'm still working on it. OT: I just committed my work of the last two months to X.Org CVS, DRM CVS and Mesa CVS, which makes the Savage driver secure, adds support for DMA vertex transfers and should improve stability for some people who couldn't use the 3D driver so far, by using shadow status in the DRM driver. > > Thanks in advance, > > Albert. -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] Glossary
Hi all, I have added a glossary page to the R300 website: http://r300.sf.net It is somewhat general in nature (not R300 specific) so I would appreciate comments (and corrections !) from everyone who has a chance to look. Also, if you would like me to put anything else there please let me know. best Vladimir Dergachev --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Dramatic improvement of depth buffer quality
> The Savage hardware can handle W buffers too. In fact I experimented > with that and the quality looks good. But it doesn't work under all > circumstances. If the viewing transformation is changed in the middle of > rendering a frame, the meaning of W changes and depth ordering is messed > up. > > As to loss of accuracy with near objects, I havn't seen any such > problems yet with the applications I tested. OTOH, the improved quality > of far objects is very noticeable for instance in FlightGear and TORCS. > As Vladimir pointed out, it might be a problem for CAD applications > though. Making float depth a configuration option would be a good idea. > And I will have to support both in the driver anyway, since > Savage3D-based hardware doesn't support floating point depth buffers. Are this changes already on savage snapshots? Thanks in advance, Albert. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Dramatic improvement of depth buffer quality
Am Sa, den 01.01.2005 schrieb Roland Scheidegger um 19:00: > Felix Kühling wrote: > > Hi, > > > > I want to share an idea that I had, which drastically improves the depth > > buffer quality on Savage4 hardware. Maybe the same can be applied to > > different hardware too. > > > > Short version: reverse the depth range (z' = 1 - z) such that far > > coordinates map to z'=0 and near coordinates to z'=1. Then use a > > floating point format to store depth values in the depth buffer. Of > > course the hardware needs to support a floating point depth buffer. > > I'm a bit sceptical that this really improves depth buffer quality in > general. With D3D it is (if the hw supports it) possible to use a w > buffer instead of a z buffer, which has the same precision for far and > near objects. However, the loss of precision for near objects was often > considered unacceptable. (Radeon R100 and R200 support this, but R300 > and up no longer do, or at least the driver doesn't expose it, so it > looks like it wasn't that useful after all, and not many applications > afaik requested w buffers). The Savage hardware can handle W buffers too. In fact I experimented with that and the quality looks good. But it doesn't work under all circumstances. If the viewing transformation is changed in the middle of rendering a frame, the meaning of W changes and depth ordering is messed up. As to loss of accuracy with near objects, I havn't seen any such problems yet with the applications I tested. OTOH, the improved quality of far objects is very noticeable for instance in FlightGear and TORCS. As Vladimir pointed out, it might be a problem for CAD applications though. Making float depth a configuration option would be a good idea. And I will have to support both in the driver anyway, since Savage3D-based hardware doesn't support floating point depth buffers. > > Roland -- | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Dramatic improvement of depth buffer quality
Felix Kühling wrote: Hi, I want to share an idea that I had, which drastically improves the depth buffer quality on Savage4 hardware. Maybe the same can be applied to different hardware too. Short version: reverse the depth range (z' = 1 - z) such that far coordinates map to z'=0 and near coordinates to z'=1. Then use a floating point format to store depth values in the depth buffer. Of course the hardware needs to support a floating point depth buffer. I'm a bit sceptical that this really improves depth buffer quality in general. With D3D it is (if the hw supports it) possible to use a w buffer instead of a z buffer, which has the same precision for far and near objects. However, the loss of precision for near objects was often considered unacceptable. (Radeon R100 and R200 support this, but R300 and up no longer do, or at least the driver doesn't expose it, so it looks like it wasn't that useful after all, and not many applications afaik requested w buffers). Roland --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
