[icecoldduke]

MetHy, on 10 June 2016 - 01:11 AM, said:

I don't know if this helps.

EDuke32 r5771 played in Polymost 1920*1080
I set visibility very high so it reflects your screenshot (if that even matters)

Went from 110 to 79 FPS (from 50 to 80FPS in classic mode). In comparison In Polymost EDuke32's FPS counter claimed between 2000 and 2800 FPS at the start of the map int he helicopter.

i5-4570 quadcore 3,2GHZ
8GB DDR3 and GTX660 (if that even matters)

Unless were able to speed this up some, I'm going to have to throw visibility off into its own core. This won't speed things up by itself, but it will make it so we can do more things while visibility is calculating(like Physics). This means the min spec for mods that fully utilize PolymerNG, will be a CPU that has at least 4 physical cores. Hyperthreading won't count since I think there would still be contention between the threads. Hyperthreading just toggles a flood gate essentially between the two logical cores on one physical core, based on which one is waiting for the L2/L1 cache to get filled. This basically means hyperthreading works well when two different threads are both memory bound, which is possible Polymost is but I haven't done enough profiling on it to say either way.

Terminx:
How much of a perf boost did you get going from double to float? Could one get away with half of that precision and use half floats?

[Paul B]

icecoldduke, on 10 June 2016 - 05:58 AM, said:

This means the min spec for mods that fully utilize PolymerNG, will be a CPU that has at least 4 physical cores.

This means that people with I3's or slower CPU's won't be able to run Duke Nukem with PolymerNG. That could very well dismiss a good majority of people who run Eduke and 4 Core's is quite a demanding jump in hardware requirements. Again, PoylmerNG may not be for everyone and if a persons CPU can't handle it then they can just stick with classic or a different renderer that suits their PC. I'm okay with the change but it will be interesting to see how others might take it. What about just two cores? I guess I'm not sure why it has to jump to 4.

**Updated** Sorry I missed the part about min specs for Mods and min spec for full use of PolymerNG renderer. Thanks for clarifying, sorry I don't mean to ask redundant questions.

[icecoldduke]

Paul B, on 10 June 2016 - 08:01 AM, said:

This means that people with I3's or slower CPU's won't be able to run Duke Nukem with PolymerNG. That could very well kill off a good majority of people who run Eduke and 4 Core's is quite a demanding jump in hardware requirements. Again, PoylmerNG may not be for everyone and if a persons CPU can't handle it then they can just stick with classic or a different renderer that suits their PC. I'm okay with the change but it will be interesting to see how others might take it.

This will only effect mods that want to use a whole bunch of level complexity like clcoast and want to use physics and such. E1L1 with physics for example should be ok with two cores. Clcoast with physics will require a 4 core processor. The problem is Polymost(since I'm using it for visibility testing) is too slow to maintain 60fps with physics, and not have 4 cores. You can probably get away with 2 cores and 30fps in the scenerio I described above, but we would have to benchmark it.

To maintain 60fps your frame can't exceed 16milliseconds.
Core 1:
Main Thread - Renderer
Core 2:
Game Thread
Core 3:
Physics Worker - probably 6ms
Core 4:
Visibility Worker - 6-10ms or more depending on how fast your CPU is and what your looking at in the map.

The 4 core min spec is for the more demanding maps. I can't see a way around this unless we can speed up Polymost.

[Danukem]

Wait, are you saying that it's going to use a core for visibility if there is one available, or are you saying that in some cases a mod just won't run at all unless you have 4 cores?

[icecoldduke]

Trooper Dan, on 10 June 2016 - 08:18 AM, said:

Wait, are you saying that it's going to use a core for visibility if there is one available, or are you saying that in some cases a mod just won't run at all unless you have 4 cores?

The mod will run no matter how many cores you have. The issue is if there isn't a physical core available, it will try to go on a logical core instead(aka hyperthreading), if a logical core isn't available, it will go on the game thread. If it goes on the game thread then the game thread will inline the visibility worker work AND the physics work. This will cause slow performance. The best option for performance is for it to go on its own physical core, but that isn't required but your performance will scale accordingly.

This is a side effect of supporting all the features of build. I hope we can speed up the visibility job, which would require speeding up Polymost. Maybe there is some code we can remove since Polymost visibility is not actually drawing anything, but as of this writing to get the best performance out of a mod that uses complex level geo, and physics is to have a four core CPU.

There will come a point were your map is too complex, even on a i7 to get 60fps. It won't be slow because it has to draw a bunch of stuff, but because Polymost is too slow, and the CPU can't keep up.

I hope we can speed this up.

[Tea Monster]

What about LODs?

[Hendricks266]

icecoldduke, on 10 June 2016 - 05:58 AM, said:

Terminx:
How much of a perf boost did you get going from double to float? Could one get away with half of that precision and use half floats?

Are half floats supported in CPU hardware? I don't think so.

[icecoldduke]

Tea Monster, on 10 June 2016 - 08:45 AM, said:

What about LODs?

It's not the complexity of the geo that's the issue, its complexity of the level and how many sectors can possibly be visible from any one location. In the above area it takes Polymost a decent amount of time to figure that out. You can't necessarily replace all of that area with a big ass piece of geo either, since occlusion is based on sectors. They way that map is built is the right way to maximize performance, the issue is the algorithm. Right now I'm considering this a math issue and not a content issue.

[icecoldduke]

Hendricks266, on 10 June 2016 - 09:06 AM, said:

Are half floats supported in CPU hardware? I don't think so.

Intel: Performance Benefits of Half Precision Floats

I haven't tried this before but:

Quote

The 3rd generation Intel® Core™ processor family introduced two half-float conversion instructions: vcvtps2ph for converting from 32-bit float to half-float, and vcvtph2ps for converting from half-float to 32-bit float.

Sounds interesting.

Quote

In particular, half-floats may provide better performance than 32-bit floats when the 32-bit float data does not fit into the L1 cache.

I suspect cache misses are also a issue in Polymost, but again I'm not sure I'm hoping TX can shed some light on whats going on.

[TerminX]

Half floats wouldn't provide nearly enough precision.

[icecoldduke]

TerminX, on 10 June 2016 - 10:49 AM, said:

Half floats wouldn't provide nearly enough precision.

Figured as much. Do you have any other ideas for increasing perf?

[Micky C]

What's the big deal with 60 FPS? Why do all the developers simply have to have their games running at that?

There are many people out there who are perfectly fine with 30 or maybe even less on occasion.

[Mblackwell]

Clear the Coast definitely didn't take performance into consideration at all really. Because the point was to have this awesome sprawling detailed map and not to have a high framerate. It's not the only user map that does it (or similar).

Spoiler

Almost anything by Billy Boy comes to mind.

[Micky C]

It's all a trade off between performance and design. I was thinking about Rage when I made that post, specifically how the engine dynamically sacrificed visual quality to maintain a constant 60 fps, which I believe is a terrible idea since different people prioritize performance and visuals to different degrees.

People here may not like it, but I've made a map for the AMC TC that runs between 20-40 fps depending on the view, on my 7 year old computer. This is on the classic renderer. Somehow polymost is slower which I find a bit confusing. The map doesn't really have any fancy geometry, a lot of sprites or any effects, so it's not like I was intentionally trying to lower the framerate, but it is large. The map simply would not be anything like it is now if I made performance a priority, which would be a shame because it's fairly unique. I don't apologize for that. Although I suppose a performance boost could be had if the skybox is disabled, which is an included option.

Something I take into account is that computers are always getting better. A map with a borderline frame rate now would run fine in a year or so. If I'm getting 20-40 fps on my 7 year old machine then surely computers bought in the last 2-3 years and going forwards would be perfectly fine.

I take it the disagreement with my last post was because people felt I was saying it's ok to cram in as many pretty yet unnecessary effects as you can regardless of framerate. As I've discussed using my map as an example, this is not the case; everything in the map is essential for the map to be what it is. I'm sure Icecoldduke might feel I should cut the map down anyway, but I'm just trying to balance the discussion so that everyone's views can be considered.

[TerminX]

icecoldduke, on 10 June 2016 - 10:50 AM, said:

Figured as much. Do you have any other ideas for increasing perf?

Depends on how exactly you're using Polymost.

[Hendricks266]

Perceptually, a responsive framerate is way more important than the prettiest visuals.

[Mark]

I'm not so sure. I look at this pretty visual and don't give a hoot about framerate.

Attached thumbnail(s)

• 

[Kathy]

If you were to have control over her you would.

[Danukem]

Kathy, on 11 June 2016 - 02:48 AM, said:

If you were to have control over her you would.

Unless he's into those realistic dolls that don't move.

[icecoldduke]

Micky C, on 10 June 2016 - 04:47 PM, said:

...

Think of it this way, if the engine runs the more complicated maps you guys make at faster framerates then that leaves more room for you guys to add more shit. Now I will give you nasty stares if you release content for PolymerNG that causes the renderer to run at sub 30fps, but if we can make the math run faster, then you get to add more complex shit to your maps. How is that not a win for you?

I would like if everyone made content for PolymerNG that lets the renderer run at 60fps. I'm slowly starting to realize that no matter what I do you guys are going to tell me to "fuck off" in that regard, and push the engine as far as you guys can. That's great. So clcoast is my test case right now for performance. I think we should also just NG the fuck out of this map, I'm starting to like it.

[Spiker]

99% of people would already quit, just because of that constant rant. I really admire you for working so hard on this despite all this nonsense.

Performance is very important but I would not like to see it take away even 1% of this awesome stuff you could add. After 2 years noone will even notice the lower fps but the awesome stuff will stay.

[MusicallyInspired]

I can understand the importance of performance. After all, that was exactly the number one complaint of Polymer.

[icecoldduke]

Spiker, on 11 June 2016 - 08:58 AM, said:

99% of people would already quit, just because of that constant rant. I really admire you for working so hard on this despite all this nonsense.

I essentially grew up with a lot of people on this forum. I know how douschey a lot of you are, as far as I'm concerned this is just par for the course . What concerns me more though is other talented people who might be reading this forum, who would get turned off from helping this project because of all the vitriol.

[TerminX]

icecoldduke, on 11 June 2016 - 10:39 AM, said:

I essentially grew up with a lot of people on this forum. I know how douschey a lot of you are, as far as I'm concerned this is just par for the course . What concerns me more though is other talented people who might be reading this forum, who would get turned off from helping this project because of all the vitriol.

Meh. This forum is run like a discussion board in the late 80's through the 90's. People can nut up or shut up.

[Danukem]

icecoldduke, on 11 June 2016 - 10:39 AM, said:

I essentially grew up with a lot of people on this forum. I know how douschey a lot of you are, as far as I'm concerned this is just par for the course . What concerns me more though is other talented people who might be reading this forum, who would get turned off from helping this project because of all the vitriol.

I feel like a loser for doing so, but I went back and checked this thread and the last time there was any vitriol expressed was back on June 3rd, and that was because people were upset that maybe there wouldn't be support for vertex animation. This latest framerate disagreement is a very civilized one. Micky C suggested that it wasn't necessary to shoot for 60fps, and pretty much everyone else agreed with you that yes, 60 fps is important. So, let's try not to let the past color the present.

[icecoldduke]

Deferred per pixel lighting is working. Next up bump mapping and spec.

[Micky C]

icecoldduke, on 11 June 2016 - 08:28 AM, said:

Think of it this way, if the engine runs the more complicated maps you guys make at faster framerates then that leaves more room for you guys to add more shit. Now I will give you nasty stares if you release content for PolymerNG that causes the renderer to run at sub 30fps, but if we can make the math run faster, then you get to add more complex shit to your maps. How is that not a win for you?

I would like if everyone made content for PolymerNG that lets the renderer run at 60fps. I'm slowly starting to realize that no matter what I do you guys are going to tell me to "fuck off" in that regard, and push the engine as far as you guys can. That's great. So clcoast is my test case right now for performance. I think we should also just NG the fuck out of this map, I'm starting to like it.

Whoa, when exactly did I say we shouldn't try to optimize the renderer as much as we can? Please, by all means try to find a quote of me saying this. Naturally 100% of the community should be on board with full optimization (at least without having to sacrifice things like SOS).

It's just that I kept seeing "60 fps" "60 fps" "60fps" everywhere, along with icecoldduke's other comments like "I'm going to paste pink magneta everywhere if content guys do things that aren't good for the renderer" on several occasions. I'm not sure if he still holds that position, or if it was even ever meant in a purely framerate context in the first place, but I was just making a casual comment that some people will make ambitious maps without caring about getting the full 60 fps.

I mean, why even stop at 60fps? Let's optimize it and get 300 or more if we can.

Edit: Nice work on the lighting btw

[Tea Monster]

Pink is good. PInk makes it very easy to see what is missing so you take less time having to find it and fix it.

I don't see why people are freaking out about this - especially the mappers.

[Mblackwell]

Pink is a good option for finding problem areas, not necessarily forced to be on if you specifically know something is a problem spot but want it anyway for a justifiable reason.

[oasiz]

To get past minspec hw, you need to mail order the full version from icd. Ive heard rumors that a +8 trainer is in the works that allows you to enable a feature or all of them at once !

Nah, i am sort of ok with the idea of trying to get 60fps out of this. Maybe for pure 100% NG content in ten years it might become an issue when its like being limited to a 6600gt today.

Anyway, nice work on getting lights in!
Will you enable better support for custom shaders?
I can see potential in all kinds of stuff ranging from viewport distortion on getting damage to other visual things.