rendering importance
Moderator: Moderators
-
monohouse
rendering importance
I would like to know to what extent video card's programmability capabilities are used and how important are they compared to other so called standard opengl rendering techniques
-
monohouse
The bottlenecks in spring performance have been known for a longtime.
Pathfinding
unit.cpp
However the pathfinder hasnt been touched since k-man left and its a mess and needs rewritting.
The general acceptance is that the cunit class is badly coded and suffers from a lack of design, but we're reluctant to redesign it because of the workload and instead append to the end of it.
I can take it you'll be putting together an action plan to correct this? Preferably for completion within our lifetimes and not involving large rewrites of code or other compiled languages such as assembly? Involvement of the things in the previous sentence have totally derailed any efforts you've made in the past, and I believe you'll be able to regain a large chunk of respect and credibility by taking smaller more feasable chunks of engine optimization.
Pathfinding
unit.cpp
However the pathfinder hasnt been touched since k-man left and its a mess and needs rewritting.
The general acceptance is that the cunit class is badly coded and suffers from a lack of design, but we're reluctant to redesign it because of the workload and instead append to the end of it.
I can take it you'll be putting together an action plan to correct this? Preferably for completion within our lifetimes and not involving large rewrites of code or other compiled languages such as assembly? Involvement of the things in the previous sentence have totally derailed any efforts you've made in the past, and I believe you'll be able to regain a large chunk of respect and credibility by taking smaller more feasable chunks of engine optimization.
1) Shaders are typically slow on low- and midend video cards because the vertex and pixel processors on those cards are comparatively nerfed in power to bring their price down.why are these things slow ? because the video card's speed is slow ? could these things be done without video card programming ? would it be faster ? would it require significantly more programming ?
2) No, they cannot be done anywhere but on the GPU (not strictly true, see 4) because shaders have a specific fixed place in the rendering pipeline.
3) No, it would in fact be roughly 10 billion times slower.
4) The only other way to do them would involve rerouting the entire OGL/GLSL pipeline through the CPU, so in one word: yes.
-
monohouse
you know there are lots of people with non-programmable video cards, such as the Geforce 2 GTS 2, Geforce 3, Geforce 4 Ti 4600, pre-Radeon 9700's and the like, there is no chance that shader effects can be done without shaders ?
the problem is that these cards are fast but do not have shaders, and some people (like me) would prefer to use older fast cards than newer lame cards which are slow and full of features which they cannot handle, so this could allow people to run these higher quality stuff without having programmability in the video card.
also after significant testing, I found that taspring does not use most of the video card's space, i have radeon 9800pro with 256MB of video memory, and spring only loads less than 100 at all times, can't the maps be loaded into video memory ?
the problem is that these cards are fast but do not have shaders, and some people (like me) would prefer to use older fast cards than newer lame cards which are slow and full of features which they cannot handle, so this could allow people to run these higher quality stuff without having programmability in the video card.
also after significant testing, I found that taspring does not use most of the video card's space, i have radeon 9800pro with 256MB of video memory, and spring only loads less than 100 at all times, can't the maps be loaded into video memory ?
Erhm, the whole point of shaders is so programmers/artists can do stuff that otherwise can NOT be done due to limitations in traditional graphics hardware. Shader effects without shaders aren't possible without building a whole software renderer from scratch, that's why programmable units were added to cards ITFP. If you have an older one, then either turn them off or get a cheap 6600GT for $100, but don't ask for something you know can't and won't happen.
-
monohouse
didn't ASK for anything, I only ASK if it was possible, thanks, damn everyone got this reading problem.
what about the videomemory underutilization ? im not the only one with large amount of videomemory and there are 500 mb videocards already, spring *could* load more stuff into video memory could it not ?
what about the videomemory underutilization ? im not the only one with large amount of videomemory and there are 500 mb videocards already, spring *could* load more stuff into video memory could it not ?
More use of videomemory comes with more textures, right now spring is relatively low on textures. 3DO is using textures very optimal (one;) ), and s3o isnt used much.
The SMF renderer uploads textures "Just in Time", and the SM3 uploads its vertex buffers "Just in Time".
There is really nothing to gain with spilling video memory...
The SMF renderer uploads textures "Just in Time", and the SM3 uploads its vertex buffers "Just in Time".
There is really nothing to gain with spilling video memory...
-
monohouse
"just in time" ?
actually I was thinking there was a lote to gain from "spilling" video memory, you could load the entire map into video memory, you could load all the units and all their textures into video memory, which would prevent the need to load them later, thus increasing speed, pre-loading to the amount that the video card can hold thus reduce sending textures to video memory because they are already present.
btw I have not seen any SM3 in spring yet.
actually I was thinking there was a lote to gain from "spilling" video memory, you could load the entire map into video memory, you could load all the units and all their textures into video memory, which would prevent the need to load them later, thus increasing speed, pre-loading to the amount that the video card can hold thus reduce sending textures to video memory because they are already present.
btw I have not seen any SM3 in spring yet.
Just-In-Time, ie: send them on-demand, just before they have to be used. Similar to Just-In-Time compiling like in Java or .NET
Changing this improves maybe 1% of total render time, not to mention that rendering isnt springs bottleneck (simulation is)
There is no point in storing unit data in video memory, its the cpu that handles it.
Total 3DO unit texture data = 2048 * 2048 * 3 = 12 mb
start learning about graphics rendering, or stop questioning the code
Changing this improves maybe 1% of total render time, not to mention that rendering isnt springs bottleneck (simulation is)
There is no point in storing unit data in video memory, its the cpu that handles it.
Total 3DO unit texture data = 2048 * 2048 * 3 = 12 mb
start learning about graphics rendering, or stop questioning the code
-
monohouse
I missed the part that it creates the bottleneck, how does storing the maps into video memory causes bottleneck ? I thought actually quite the opposite, because the maps are in the video memory, they might be rendered faster, and reduce memory load on from the system's memory, and maps are a significant amount of memory as you have mentioned.
looks like I am suck at that stuff and it's obvious that you are all far ahead of me, and it also looks like it is something you have considered before, still if you feel like explaining to me why I would very mutch like to know.
besides, I thought rendering was a very big bottleneck when the heavy rendering stuff are used.
looks like I am suck at that stuff and it's obvious that you are all far ahead of me, and it also looks like it is something you have considered before, still if you feel like explaining to me why I would very mutch like to know.
besides, I thought rendering was a very big bottleneck when the heavy rendering stuff are used.
Last edited by monohouse on 09 Jan 2007, 00:43, edited 1 time in total.
-
monohouse
There is an annoying decal bug left, and it needs some promoting. I see a lot of maps that are suitable for SM3, but so far the mappers that tried sm3 have made really complex textured maps that where quite heavy on hardware.
Maps like comet catcher or altored divide should be really fast on the SM3 system, both would just need 2 texture layers I think
Maps like comet catcher or altored divide should be really fast on the SM3 system, both would just need 2 texture layers I think