I failed to rid of this myself and I am pretty sure this is causing fps loss on my machine (especially "Pointing at: <coords>" messages), so could you make possible to disable it (and make disabled by default) in config settings?
This is serious, since outputting thing (especially to file, which would be debug.txt, I believe) take away CPU cycles which can be used for something else like calculating world, or so and directs to low framerate.
Config setting for disabling debug console output
-
darkhog
- Member
- Posts: 73
- Joined: Sat May 28, 2011 13:35
- In-game: darkhog
- Location: /dev/null
- Contact:
Yeah, right. Since my GPU is GeForce9600 GT which can run Crysis on highest details without any problems I doubt it's that. Plus I have newest nVidia closed drivers (don't use any shit like nouveau) so I don't think it is a problem. Also other linux games which have better graphics than this (Nexuiz, openArena, ManiaDrive, VDrift to name few) also run on hihest detail without any fps loss.
So no, I don't think my GPU is a problem.
So no, I don't think my GPU is a problem.
Define "better graphics". Minetest (and any other similar block game) is just a pure torture test for GPU. The frame rate entirely depends on the amount of textured triangles (those cubes consist of quads, which are rendered as two triangles) your GPU can output to the screen. It is something completely different than those games you define to have better graphics do - and they are lightweight for the GPU when compared to what Minetest could take out of it if possible.
Also, I find it really amusing you even think that outputting a few lines of log messages now and then actually need processing power - it does not. The impact is just like peeing to ocean - impossible to notice.
Also, I find it really amusing you even think that outputting a few lines of log messages now and then actually need processing power - it does not. The impact is just like peeing to ocean - impossible to notice.
Where did you pull these numbers from?
If you just look at a wall larger than 16x16 blocks, that already has more than 500 triangles drawn. If we look at, for example, this screenshot, it has easily over 25000 triangles drawn on every single frame. I don't know about Crysis, but I doubt it has as much triangles drawn - where it needs performance is all the post-processing, which is quite constant time.
If you just look at a wall larger than 16x16 blocks, that already has more than 500 triangles drawn. If we look at, for example, this screenshot, it has easily over 25000 triangles drawn on every single frame. I don't know about Crysis, but I doubt it has as much triangles drawn - where it needs performance is all the post-processing, which is quite constant time.
Last edited by Kray on Tue May 31, 2011 09:41, edited 1 time in total.
-
darkhog
- Member
- Posts: 73
- Joined: Sat May 28, 2011 13:35
- In-game: darkhog
- Location: /dev/null
- Contact:
Got rid of this debuginfo business (in really hackish and clumsy way, but got rid of) and guess what? Steady 60FPS, even with fancy trees, smooth light and disabled fog. See for yourself http://dl.dropbox.com/u/210143/celeron5 ... f579bc.zip (zip file with sources and linux executables in bin folder).
I think it was most fault of printing to console where player is ponting at for no apparent reason. As I said, see for yourself, FPS will be bigger than earlier.
I think it was most fault of printing to console where player is ponting at for no apparent reason. As I said, see for yourself, FPS will be bigger than earlier.
I tested your modifications and went to see the exact same view as in that screenshot - and guess what, steady 20 fps instead of your steady 60.
My guess is that you just went ahead and checked that "ok, frame rate 60, good!" with almost no chunks loaded and visible. Guess what, I get steady 60 fps also on the non-modified client when I have almost nothing loaded.
My guess is that you just went ahead and checked that "ok, frame rate 60, good!" with almost no chunks loaded and visible. Guess what, I get steady 60 fps also on the non-modified client when I have almost nothing loaded.
The problem here is that your "yber fast" GPU is not made to support something like Minetest. It has been optimized to render huge amounts of static vertices stored on the GPU with huge amounts of shader stuff going on. That's what Crysis and other similar games are designed to do.
Minetest doesn't store vertex data on the GPU and doesn't use shaders at all. The speed at which minetest runs depends solely on how fast your machine can throw geometry at the GPU. (On very low-end cards like the 945GM the bottleneck might be actually rendering them.)
The performance is somewhat random, only some of the new GPUs seem to be strangely slow, others do just fine. If I had to buy a GPU for running Minetest, I'd go for some lower-mid-range NVidia.
Also, in the case of Minetest, some other "slower" drivers might actually be faster, the only way you can know is to test them. On Windows it sometimes helps to set it to use the direct3d9 backend if the drivers have a shitty OpenGL implementation. (see wiki about the config file.)
Minetest doesn't store vertex data on the GPU and doesn't use shaders at all. The speed at which minetest runs depends solely on how fast your machine can throw geometry at the GPU. (On very low-end cards like the 945GM the bottleneck might be actually rendering them.)
The performance is somewhat random, only some of the new GPUs seem to be strangely slow, others do just fine. If I had to buy a GPU for running Minetest, I'd go for some lower-mid-range NVidia.
Also, in the case of Minetest, some other "slower" drivers might actually be faster, the only way you can know is to test them. On Windows it sometimes helps to set it to use the direct3d9 backend if the drivers have a shitty OpenGL implementation. (see wiki about the config file.)
-
darkhog
- Member
- Posts: 73
- Joined: Sat May 28, 2011 13:35
- In-game: darkhog
- Location: /dev/null
- Contact:
So why you don't store vertices in gpu? I think Manic Digger is doing it and it just run fine? Low performance is only fault on your coding. Few optimization suggestions:
- When several blocks of same type make cuboid like here:
draw them as single quad instead of quad per block.
- Cache terrain geometry in GPU if you're able to. This will allow you to make it run even faster.
- When several blocks of same type make cuboid like here:
draw them as single quad instead of quad per block.
- Cache terrain geometry in GPU if you're able to. This will allow you to make it run even faster.
And about storing stuff on the GPU: Currently stuff is handled separately for each 16x16x16 chunk of blocks (block of nodes, in minetest terms) which is too low to bring any performance benefit from storing on the GPU. They would need to be combined to even larger parts, which I might try some day, but it's not too high on my priority list.
Feel free to implement that, though; just remember the design philosphy and the brand new contribution policy. 8)
Feel free to implement that, though; just remember the design philosphy and the brand new contribution policy. 8)
Who is online
Users browsing this forum: No registered users and 7 guests