Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualnoizex

Posted 20 March 2013 - 03:25 AM

Don't agree to all of that.

 

Both options calculate a combined modelview / projection matrix once per frame.

I assume Danicco simply forgot to post the 2nd projection setup, and matrix setup does not affect performance because he uses lots of vertices (?)

 

And both should do a single matrix mult per vertex.

 

Option 1 does it in shader and option 2 too, because OGL will add the necessary instructions automatically (If it doesn't know it should not), right?

Thus my assumption that this accidently happens to option 1 too.

Maybe there's even a driver bug forcing this to happen all the time - who knows?

 

Also, pure FPS should be accurate enough to measure a 25% difference, if there are enough vertices in the test.

 

To be honest I haven't addressed his performance issues because we know nothing about how he measured this and how everything else works. There are so many things that can affect the results that its IMO pointless with such little information about that particular case. 

 

What is relevant is that he shouldn't be using deprecated functionality (glRotate, glEnableClientState when using glVertexAttribPointer). 

 

Also, I have no idea what vertices number has anything to do with FPS vs ms/frame measurment. Lets assume (because he never wrote what are his numbers even) that he measures FPS and don't have any v-sync and anything that would limit how many frames are drawn, so he draws as many as possible in a single frame. I also assume that he doesn't do anything else in his test case so we can say that faster method is around 3000 FPS probably:

 

2 option (deprecated, potentially faster):

3000 FPS = 0.33 ms/frame

1 option (using glm matrices, said to be 25% slower)

2250 FPS = 0.44 ms/frame
(3000*0.75)

 

So this gives you difference of 0.11ms per frame in "slow" case. This means that your insanely big 25% difference in FPS in this case is merely 0.11ms difference, which is not that much anymore? From here you can start measuring what exactly happens that causes this slowdown. 

 

Of course his FPS count can be different, as wintertime mentioned, measuring with FPS makes a bit more sense below 60FPS level, but its still better to use ms/frame there. 


#2noizex

Posted 20 March 2013 - 03:24 AM

Don't agree to all of that.

 

Both options calculate a combined modelview / projection matrix once per frame.

I assume Danicco simply forgot to post the 2nd projection setup, and matrix setup does not affect performance because he uses lots of vertices (?)

 

And both should do a single matrix mult per vertex.

 

Option 1 does it in shader and option 2 too, because OGL will add the necessary instructions automatically (If it doesn't know it should not), right?

Thus my assumption that this accidently happens to option 1 too.

Maybe there's even a driver bug forcing this to happen all the time - who knows?

 

Also, pure FPS should be accurate enough to measure a 25% difference, if there are enough vertices in the test.

 

To be honest I haven't addressed his performance issues because we know nothing about how he measured this and how everything else works. There are so many things that can affect the results that its IMO pointless with such little information about that particular case. 

 

What is relevant is that he shouldn't be using deprecated functionality (glRotate, glEnableClientState when using glVertexAttribPointer). 

 

Also, I have no idea what vertices number has anything to do with FPS vs ms/frame measurment. Lets assume (because he never wrote what are his numbers even) that he measures FPS and don't have any v-sync and anything that would limit how many frames are drawn, so he draws as many as possible in a single frame. I also assume that he doesn't do anything else in his test case so we can say that faster method is around 3000 FPS probably:

 

2 option (deprecated, potentially faster):

3000 FPS = 0.33 ms/frame

1 option (using glm matrices, said to be 25% slower)

2250 FPS = 0.44 ms/frame
(3000*0.75)

 

So this gives you difference of 0.11ms per frame in "slow" case. This means that your insanely big 25% difference in FPS in this case is merely 0.11ms difference, which is not that much anymore? From here you can start measuring what exactly happens that causes this slowdown. 


#1noizex

Posted 20 March 2013 - 03:19 AM

Don't agree to all of that.

 

Both options calculate a combined modelview / projection matrix once per frame.

I assume Danicco simply forgot to post the 2nd projection setup, and matrix setup does not affect performance because he uses lots of vertices (?)

 

And both should do a single matrix mult per vertex.

 

Option 1 does it in shader and option 2 too, because OGL will add the necessary instructions automatically (If it doesn't know it should not), right?

Thus my assumption that this accidently happens to option 1 too.

Maybe there's even a driver bug forcing this to happen all the time - who knows?

 

Also, pure FPS should be accurate enough to measure a 25% difference, if there are enough vertices in the test.

 

To be honest I haven't addressed his performance issues because we know nothing about how he measured this and how everything else works. There are so many things that can affect the results that its IMO pointless with such little information about that particular case. 

 

What is relevant is that he shouldn't be using deprecated functionality (glRotate, glEnableClientState when using glVertexAttribPointer). 

 

Also, I have no idea what vertices number has anything to do with FPS vs ms/frame measurment. Lets assume (because he never wrote what are his numbers even) that he measures FPS and don't have any v-sync and anything that would limit how many frames are drawn, so he draws as many as possible in a single frame:

 

2 option (deprecated, potentially faster):

3000 FPS = 0.33 ms/frame

1 option (using glm matrices, said to be 25% slower)

2250 FPS = 0.44 ms/frame
(3000*0.75)

 

So this gives you difference of 0.11ms per frame in "slow" case. This means that your insanely big 25% difference in FPS in this case is merely 0.11ms difference, which is not that much anymore? From here you can start measuring what exactly happens that causes this slowdown. 


PARTNERS