stgatilov

It is pretty strange that it crashes. But I can easily reproduce it on Windows. Just open two TDM instances and set "com_automation 1" in both. Obviously, it gets fatal error That's not right.

I find it hard to believe that this change could have made anything worse. And no, it is not possible to maintain both cases. If you have problems, please report performance in 8 cases: r_useNewBackend 1 and 0 Stencil and Maps Hard and Soft

To everyone who can compile from source: try rev 10211. Also, I would be glad if you actually compare the performance to that of 2.10. Even if this issue was the greatest one, there could be other reasons for slowdown. By the way, GLSL specification says that all function arguments must be copied. Although it is normal to expect from GLSL compiler to inline all function calls, then find def-use relations and not copy read-only data. Maybe AMD had to block this particular case for some reason... Also, I have launched Radeon GPU tools on TDM, and I like it a lot! Yeah, it has a bit of AMD roughness (most recent version crashes, I had to backtrack about 1 year into the past to find working version), but I like how open they are. They just write down all the information they measure, without trying to protect developer from information overload. So much stuff there... One interesting thing is that AMD profiling tool shows everything exclusively in Vulkan terms, nothing related to OpenGL. I wonder whether they merely represent internal driver routines in Vulkan terms, or they internally convert OpenGL into Vulkan completely. I've heard that Intel is converting OpenGL to Vulkan on recent drivers --- I guess that's the trend today.

It seems that when I pass vec2[150] to a function, AMD compiler honestly generates copying instructions Copying 1.2 KB of data on every fragment is quite slow...

I replugged cable to my AMD RX 550, and I can definitely reproduce the same issue. I have severe performance degradation (like 3x or 4x) in New Job on all shadows except for hard stencil. And the degradation starts on the very same dev build. I think it will get quicker from this moment

beta211-02 is available!

@Dragofer, I moved it here since it is most likely the same issue. Did you upgrade your driver? Or beta211-01 works well even if you try it now?

You can replace the loop in idEntity::ActivateTargets with a call to TriggerGuis. Then you can probably add a condition to TriggerGuis, which would skip gui if its "gui_trigger" / "gui_enable_trigger" is zero?

Maybe use a spawnarg which disables builtin "gui" behavior? Maybe there is already an existing one? @Dragofer @kingsal

I'm afraid it is not a proper fix: it will only help for "default" messages. There are ton of missions which use "atdm:gui_message" with custom "gui" set, you fix will do nothing for them. For instance: // entity 1769 { "classname" "atdm:gui_message" "name" "message_citywatch_gate1" "angle" "-90.000000" "delay" "0" "force" "1" "gui" "guis/volta_sign_small.gui" "lines" "2" "origin" "345.751 1089.88 213" "show" "1" "text" "Finnley Murray" } Just ask almost any mapper around. Here is e.g. a list of missions which all probably suffer from the problem: "gui" "guis/tdm_message_no_art.gui" hazard/hazard.pk4 -> maps/hazard_night.map northdale2/northdale2.pk4 -> maps/m2.map sirt/sirt.pk4 -> maps/sirt.map ac1/ac1.pk4 -> maps/ac1.map painterswife/painterswife.pk4 -> maps/city.map ac2/ac2.pk4 -> maps/ac2_autosave.map itb/itb.pk4 -> maps/itb.map nobleaffairs/nobleaffairs.pk4 -> maps/noble_affairs.map northdale1/northdale1.pk4 -> maps/m1.map ws1_north/ws1_north.pk4 -> maps/ws1_north.map away0/away0.pk4 -> maps/away0.map ac2/ac2.pk4 -> maps/ac2.map ws5_commerce/ws5_commerce.pk4 -> maps/ws5_commerce.map snowed_inn/snowed_inn.pk4 -> maps/snowed_inn.map airpocket/airpocket.pk4 -> maps/airpocket.map And that is just one particular value of "gui" spawnarg on messages, there are many others.

I think "gui" spawnarg is used for customizing the message .gui file: string gui_name = getKey("gui"); if (gui_name == "") { gui_name = "guis/tdm_message.gui"; // the default value } gui = $player1.createOverlay(gui_name, 10); You can delete the line, but if someone uses the customization, it won't help them. What's the duplication exactly? Does the engine handle "gui" spawnarg automatically?

@lowenz, could you please try svn rev 10204 ? (make sure glprogs get copied to game directory, they usually do it automatically along with executable) Also, I have fixed r_skipAmbient and r_skipInteractions with new backend. I guess if you set "r_skipAmbient 3" and see only lights, the things should work slowly for you. But if you set "r_skipInteractions 1" and see only ambient, then the things should work fast.

On Linux you use Mesa as frontend, so I'm pretty sure you don't have this problem. But it won't harm if you check it Just compare FPS on 2.10 and 2.11 beta in something like New Job or Saint Lucia with soft shadows, uncapped FPS and no Vsync.

I have no ideas actually. If it was caused by interaction itself, then the slowdown should be visible even without shadows. If it was caused by shadows, then it should change when you switch between stencil and shadows, since their code is completely separate. If it was caused by the way inputs are provided, then it should probably work differently with new/old backends. I think without access to this GPU to comment/uncomment all possible chunks of code I won't be able to anything with it. The commit does not have any functional changes, only refactoring, and a big one. It is not something I can simply revert, because without it our progress on shaders side will be slowed down and we'll have many bugs about discrepancy between various modes.

What about hard stencil shadows ?

If these are the very first frames, then it's probably something about initial clear or SMP. Do you have the issue if you set "com_smp 0" ? (I assume you use the latest svn trunk)

I'm not so sure I would try svn rev 10040, and if it is slow with shadows, then revs 10039-10037 too. Otherwise, try svn revs 10070-10066. I don't think anything else relates to the problem. By the way, did you try "r_useNewBackend 0" (out of curiosity) ? And condump with GL errors enabled is still welcome.

Could you please run the game with: r_ignoreGlErrors 0 r_glDebugContext 1 r_glDebugOutput 2 Then get to the place which is slow and take a condump? Are you sure you get no GLSL warnings/errors and no OpenGL error spam? Does the issue go away when you: Turn off SSAO? Both on stencil shadow and shadow maps? Turn off shadows (execute: r_shadows 0; reloadmodels) ? Other than that, we can bisect further by revisions... although that would take time if you cannot build the game yourself.

This is framebuffer setup code. You have learnt that it you disable multisampling = antialiasing, then the issue does not happen. I know that there is one frame during mission startup when GL error occurs. And as far as I recall, it occured because of some FBO weirdness. Maybe it's the source of the problem. If you enable: r_ignoreGlErrors 0 r_glDebugContext 1 r_glDebugOutput 2 Then I suppose you'll see it in game console. Catching a problem on a single frame is quote hard. Recently I used apitrace for this: it records all GL calls from the very start and allows to replay them to any moment. We can try to use it if you want, but if the problem is visible only for you, then most likely only replaying on your machine will show it, so investigation will only be possible on your machine anyway.

Maybe record a video? There is one very bad problem with decals currently (4634), when decal gets partly occluded by some surface slightly on top of it, with a clear straight line separating the areas where it is occluded and where it is not (and the line moves as player moves, so it looks very ugly). But it is not clear if you have the same problem or something else.

The old spawnarg was not working they way it was advertised: 5987 It only allows NaN to be stored, but is not the reason. Just like bloom expands them to large quads.

You can get the same issues by setting "r_useScissor 0" --- that's what screenshots did before svn rev 10198. They no longer do that, so now they should look fine.

That's most likely vertex cache resize: it never shrinks while you play, so usually it happens near map start. And if you open game console, you'll see some kind of message about it there.

@AluminumHaste, can you please toggle on/off some cvars to see if the issue depends on anything? Except for bloom: don't disable it, or you'll get tiny black pixels instead of huge blocks Most likely some of the new shader code generates NaNs again, and AMD is sorta right by propagating it all over the picture thanks to Bloom.

There is no difference.