Re: Doom3 benchmarks.

2006-09-18 Thread Rune Petersen
Aapo Tahkola wrote:
 On Sun, 13 Aug 2006 02:17:40 +0200
 Rune Petersen [EMAIL PROTECTED] wrote:
 
 Roland Scheidegger wrote:
 Rune Petersen wrote:
 Roland Scheidegger wrote:
 fragment.position input is not implemented yet. fglrx driver parses
 it from VP to FP via a texcoord route. I've been hitting my head on
 this for some time. Only got as far as only getting a soft lockup
 which isn't very useful.
 That kinda makes sense. On r200 you could already pass vertex data
 to the fragment registers (but you couldn't use position as input),
 so the data was interpolated by the texcoord interpolator but
 texture lookup was disabled (see the ATI_fs spec / r200 dri
 implementation). At first sight looks like a similar mechanism
 might be used by r300 I guess, interpolating position or texcoords
 isn't too different is it?

 I've had been looking into this, and the vertex shader is supplying
 the position to the fragment shader as a texcoord, the only apparent
 difference in shader setup between a position and a real texcoord, is
 a real texcoord is supplied as input for the vertex shader.


 I would really like to capture the vertex program of
 program/fp/tri-depth and the fglrx driver.

 But I'm betting the vertex shader is capable of writing to a texcoord.
 All I need is a safe way for the vertex shader code to know if the
 fragment shader needs the position.

 Any help with this would be great.
 
 Bug #8056 patch can do this. Take a look at r300_select_vertex_shader().
 

Thank you.

Getting wpos to the fragment shader is not too reliable atm, but
something strange:

Only x  y are valid for hpos in the vertex shader..
z = 0  w = 1 as you would expect if they weren't set...


Am I missing something obvious?


Rune Petersen

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Doom3 benchmarks.

2006-08-31 Thread Aapo Tahkola
On Wed, 30 Aug 2006 20:50:16 +0200
Rune Petersen [EMAIL PROTECTED] wrote:

 Aapo Tahkola wrote:
  On Sun, 13 Aug 2006 02:17:40 +0200
  Rune Petersen [EMAIL PROTECTED] wrote:
  
  Roland Scheidegger wrote:
  Rune Petersen wrote:
  Roland Scheidegger wrote:
  Adam K Kirchhoff wrote:
  Just thought I'd post some updated benchmarks of Doom3.  These
  were all run with the first timedemo at 640x480, and (for the
  open source drivers) with ColorTiling turned on in the
  xorg.conf file.  I'll list all tests with the open source
  drivers first:
 
  x700 + r300 (with arb renderer) - 5.5 FPS (There's not much
  point in testing it with the r200 or arb2 renderers at the
  moment.)
  What's the problem with arb2?
  fragment.position input is not implemented yet. fglrx driver
  parses it from VP to FP via a texcoord route. I've been hitting
  my head on this for some time. Only got as far as only getting a
  soft lockup which isn't very useful.
  That kinda makes sense. On r200 you could already pass vertex data
  to the fragment registers (but you couldn't use position as
  input), so the data was interpolated by the texcoord interpolator
  but texture lookup was disabled (see the ATI_fs spec / r200 dri
  implementation). At first sight looks like a similar mechanism
  might be used by r300 I guess, interpolating position or texcoords
  isn't too different is it?
 
  I've had been looking into this, and the vertex shader is supplying
  the position to the fragment shader as a texcoord, the only
  apparent difference in shader setup between a position and a real
  texcoord, is a real texcoord is supplied as input for the vertex
  shader.
 
 
  I would really like to capture the vertex program of
  program/fp/tri-depth and the fglrx driver.
 
  But I'm betting the vertex shader is capable of writing to a
  texcoord. All I need is a safe way for the vertex shader code to
  know if the fragment shader needs the position.
 
  Any help with this would be great.
  
  Bug #8056 patch can do this. Take a look at
  r300_select_vertex_shader().
 
 Thank you.
 
 
 About your patch:
 
 Can't reproduce your result with gearbox
 [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range
 check (reg=4e28 sz=1)
 [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed

It should be same as t-offset when the cube is drawn.

 
 
 subtexrate:
 The result is not too reliable with this, but at least it doesn't
 crash =) There looks to be a mess up of src  dest. sometimes the src
 is the teapot other times the root window.

doSubRect cases will definitely fail.

It would seem as if the clip rects would be relative to something
else. Odd that it never crashes with default clip rects...

-- 
Aapo Tahkola

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Doom3 benchmarks.

2006-08-30 Thread Aapo Tahkola
On Sun, 13 Aug 2006 02:17:40 +0200
Rune Petersen [EMAIL PROTECTED] wrote:

 Roland Scheidegger wrote:
  Rune Petersen wrote:
  Roland Scheidegger wrote:
  Adam K Kirchhoff wrote:
  Just thought I'd post some updated benchmarks of Doom3.  These
  were all run with the first timedemo at 640x480, and (for the
  open source drivers) with ColorTiling turned on in the xorg.conf
  file.  I'll list all tests with the open source drivers first:
 
  x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point
  in testing it with the r200 or arb2 renderers at the moment.)
  What's the problem with arb2?
 
  fragment.position input is not implemented yet. fglrx driver parses
  it from VP to FP via a texcoord route. I've been hitting my head on
  this for some time. Only got as far as only getting a soft lockup
  which isn't very useful.
  That kinda makes sense. On r200 you could already pass vertex data
  to the fragment registers (but you couldn't use position as input),
  so the data was interpolated by the texcoord interpolator but
  texture lookup was disabled (see the ATI_fs spec / r200 dri
  implementation). At first sight looks like a similar mechanism
  might be used by r300 I guess, interpolating position or texcoords
  isn't too different is it?
  
 
 I've had been looking into this, and the vertex shader is supplying
 the position to the fragment shader as a texcoord, the only apparent
 difference in shader setup between a position and a real texcoord, is
 a real texcoord is supplied as input for the vertex shader.
 
 
 I would really like to capture the vertex program of
 program/fp/tri-depth and the fglrx driver.
 
 But I'm betting the vertex shader is capable of writing to a texcoord.
 All I need is a safe way for the vertex shader code to know if the
 fragment shader needs the position.
 
 Any help with this would be great.

Bug #8056 patch can do this. Take a look at r300_select_vertex_shader().

-- 
Aapo Tahkola

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Doom3 benchmarks.

2006-08-12 Thread Rune Petersen
Roland Scheidegger wrote:
 Rune Petersen wrote:
 Roland Scheidegger wrote:
 Adam K Kirchhoff wrote:
 Just thought I'd post some updated benchmarks of Doom3.  These
 were all run with the first timedemo at 640x480, and (for the
 open source drivers) with ColorTiling turned on in the xorg.conf
 file.  I'll list all tests with the open source drivers first:

 x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point
 in testing it with the r200 or arb2 renderers at the moment.)
 What's the problem with arb2?

 fragment.position input is not implemented yet. fglrx driver parses
 it from VP to FP via a texcoord route. I've been hitting my head on
 this for some time. Only got as far as only getting a soft lockup
 which isn't very useful.
 That kinda makes sense. On r200 you could already pass vertex data to
 the fragment registers (but you couldn't use position as input), so the
 data was interpolated by the texcoord interpolator but texture lookup
 was disabled (see the ATI_fs spec / r200 dri implementation). At first
 sight looks like a similar mechanism might be used by r300 I guess,
 interpolating position or texcoords isn't too different is it?
 

I've had been looking into this, and the vertex shader is supplying the
position to the fragment shader as a texcoord, the only apparent
difference in shader setup between a position and a real texcoord, is a
real texcoord is supplied as input for the vertex shader.


I would really like to capture the vertex program of
program/fp/tri-depth and the fglrx driver.

But I'm betting the vertex shader is capable of writing to a texcoord.
All I need is a safe way for the vertex shader code to know if the
fragment shader needs the position.

Any help with this would be great.


Rune Petsen

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Doom3 benchmarks.

2006-08-06 Thread Adam K Kirchhoff

Just thought I'd post some updated benchmarks of Doom3.  These were all
run with the first timedemo at 640x480, and (for the open source
drivers) with ColorTiling turned on in the xorg.conf file.  I'll list
all tests with the open source drivers first:

x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point in
testing it with the r200 or arb2 renderers at the moment.)

9000 (with arb renderer) - 15.9
9000 (with r200 renderer) - 15.4

The huge performance increase I get by using an r200 card is pretty
consistent with what I see in other games.

WIth the fglrx driver:

x700 + fglrx (with arb renderer) - 4.4
x700 + fglrx (with r200 renderer) - 28.7

9000 + fglrx (with arb renderer) - 3.9
9000 + fglrx (with r200 renderer) - 16.4

Adam



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Doom3 benchmarks.

2006-08-06 Thread Roland Scheidegger
Adam K Kirchhoff wrote:
 Just thought I'd post some updated benchmarks of Doom3.  These were 
 all run with the first timedemo at 640x480, and (for the open source
  drivers) with ColorTiling turned on in the xorg.conf file.  I'll
 list all tests with the open source drivers first:
 
 x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point in
  testing it with the r200 or arb2 renderers at the moment.)
What's the problem with arb2? The r300 driver does not
currently support the r200 render path (and I doubt it will in the
future - there's just not enough interest in supporting ATI_fs on r300
which is not widely used).

 9000 (with arb renderer) - 15.9 9000 (with r200 renderer) - 15.4
 
 The huge performance increase I get by using an r200 card is pretty 
 consistent with what I see in other games.
There seems to be some performance problems with the r300 driver. I
don't think anyone knows what's going on but I could be wrong...

 WIth the fglrx driver:
 
 x700 + fglrx (with arb renderer) - 4.4 x700 + fglrx (with r200 
 renderer) - 28.7
 
 9000 + fglrx (with arb renderer) - 3.9 9000 + fglrx (with r200 
 renderer) - 16.4
Looks like fglrx has some performance problems too... I can't remember 
it being that slow with the arb path, what driver version is this? arb 
path should always be faster quite a bit as the scene complexity is 
lower (no bump maps etc. though you can switch them off for the other 
render paths too).

Roland

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Doom3 benchmarks.

2006-08-06 Thread Rune Petersen
Roland Scheidegger wrote:
 Adam K Kirchhoff wrote:
 Just thought I'd post some updated benchmarks of Doom3.  These were 
 all run with the first timedemo at 640x480, and (for the open source
  drivers) with ColorTiling turned on in the xorg.conf file.  I'll
 list all tests with the open source drivers first:

 x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point in
  testing it with the r200 or arb2 renderers at the moment.)
 What's the problem with arb2?

fragment.position input is not implemented yet. fglrx driver parses it
from VP to FP via a texcoord route. I've been hitting my head on this
for some time. Only got as far as only getting a soft lockup which isn't
very useful.

 The r300 driver does not
 currently support the r200 render path (and I doubt it will in the
 future - there's just not enough interest in supporting ATI_fs on r300
 which is not widely used).
 
 9000 (with arb renderer) - 15.9 9000 (with r200 renderer) - 15.4

 The huge performance increase I get by using an r200 card is pretty 
 consistent with what I see in other games.
 There seems to be some performance problems with the r300 driver. I
 don't think anyone knows what's going on but I could be wrong...

I have seen some strange slowdowns not caused bu any apparent fallback
(Nexiuz w/bloom) though I could have missed a fallback path.


Rune Petersen


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Doom3 benchmarks.

2006-08-06 Thread Roland Scheidegger
Rune Petersen wrote:
 Roland Scheidegger wrote:
 Adam K Kirchhoff wrote:
 Just thought I'd post some updated benchmarks of Doom3.  These
 were all run with the first timedemo at 640x480, and (for the
 open source drivers) with ColorTiling turned on in the xorg.conf
 file.  I'll list all tests with the open source drivers first:
 
 x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point
 in testing it with the r200 or arb2 renderers at the moment.)
 What's the problem with arb2?
 
 fragment.position input is not implemented yet. fglrx driver parses
 it from VP to FP via a texcoord route. I've been hitting my head on
 this for some time. Only got as far as only getting a soft lockup
 which isn't very useful.
That kinda makes sense. On r200 you could already pass vertex data to 
the fragment registers (but you couldn't use position as input), so the 
data was interpolated by the texcoord interpolator but texture lookup 
was disabled (see the ATI_fs spec / r200 dri implementation). At first 
sight looks like a similar mechanism might be used by r300 I guess, 
interpolating position or texcoords isn't too different is it?

 The r300 driver does not currently support the r200 render path
 (and I doubt it will in the future - there's just not enough
 interest in supporting ATI_fs on r300 which is not widely used).
 
 9000 (with arb renderer) - 15.9 9000 (with r200 renderer) - 15.4
 
 The huge performance increase I get by using an r200 card is
 pretty consistent with what I see in other games.
 There seems to be some performance problems with the r300 driver. I
  don't think anyone knows what's going on but I could be wrong...
 
 I have seen some strange slowdowns not caused bu any apparent
 fallback (Nexiuz w/bloom) though I could have missed a fallback path.
It's strange the (simple) arb path of doom3 is slow.
btw the real reference point would probably be drivers from another 
OS, they are often a lot faster (and I'm really wondering where ati gets 
the additional performance there at least for r200). Those drivers might 
include things which we don't really want to implement but I don't think 
all of the performance difference is caused by that.

Roland

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: Doom3 benchmarks.

2006-08-06 Thread Aapo Tahkola
On Sun, 06 Aug 2006 22:57:21 +0200
Rune Petersen [EMAIL PROTECTED] wrote:

 Roland Scheidegger wrote:
  Adam K Kirchhoff wrote:
  Just thought I'd post some updated benchmarks of Doom3.  These
  were all run with the first timedemo at 640x480, and (for the open
  source drivers) with ColorTiling turned on in the xorg.conf file.
  I'll list all tests with the open source drivers first:
 
  x700 + r300 (with arb renderer) - 5.5 FPS (There's not much point
  in testing it with the r200 or arb2 renderers at the moment.)
  What's the problem with arb2?
 
 fragment.position input is not implemented yet. fglrx driver parses it
 from VP to FP via a texcoord route. I've been hitting my head on this
 for some time. Only got as far as only getting a soft lockup which
 isn't very useful.
 
  The r300 driver does not
  currently support the r200 render path (and I doubt it will in the
  future - there's just not enough interest in supporting ATI_fs on
  r300 which is not widely used).
  
  9000 (with arb renderer) - 15.9 9000 (with r200 renderer) - 15.4
 
  The huge performance increase I get by using an r200 card is
  pretty consistent with what I see in other games.
  There seems to be some performance problems with the r300 driver. I
  don't think anyone knows what's going on but I could be wrong...
 
 I have seen some strange slowdowns not caused bu any apparent fallback
 (Nexiuz w/bloom) though I could have missed a fallback path.

Light bloom usually need render to texture type of functionality which
in turn needs accelerated CopyTexSubImage2D or ReadPixels. These are
implemented using the span functions currently.
CopyTexSubImage2D cannot be accelerated because we need to update copy
of the texture kept in system memory(for raster fallbacks).
Secondly, normal bitblt cannot be used to perform these operations
since it doesn't support necessary pitches and offsets - x/y tricks used
in r300_texmem.c will not work as r300 tends to think that micro tile
starts at given offset. dxtn happens to be broken because we cant do
micro tiling on normal textures.
I tried implementing blits using 3d engine and textures but I ran into
trouble with clip rects so I had to give up. Buffer swaps
work fine with it though.

-- 
Aapo Tahkola

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel