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 coordinat
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: re
> 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.
>
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 le
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,
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 gre
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 f
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 sta
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
re
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
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 hard
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 les
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
13 matches
Mail list logo
