OptimusShepard

I add the patch D1789, hopefully it work system.zip If this doesn't work you may want to test this here. I hardcoded some parts, so another chance ^^ system_hardcoded.zip So ignoring this bug?

I guess, test.exe wont work, because it's normally only available with the development (svn/git) version. I didn't delete all unnecessary files out of the folder.

Yep, this is what I meant. If we detect a false positive for TSC. Do you meant the performance difference at all, or only when using SSE? I guess, most of the differences are related to the AMD OpenGl drivers. Do you think the newer 2019 compiler would have a big performance benefit?

I'm sorry to hear that. I will have a look on the code again, but I guess, without the possibility of debugging, my chances aren't that good to find a quick workaround. I have also already tried, to do the correct implementation, but the CPUID and the technical backround ist out of my knowledge. I hope @Imarok can fix it soon. On the Ryzen CPUs it was possible, to press multiple time continue (at the crash window), to launch the game. Maybe this will work on the Threadrippers too? If so, you can press Alt + Enter to change to fullscreen mode.

Hello @Froschkoenig84 I may have a workaround for you. system.zip Try this, and give me feedback please. Our problem with the wrong hardware detection is, that we read the new CPUIDs in a wrong way. So we get a wrong index, to interpret the cache associativity value. My workaround for you replaces the associativityTable[idxAssociativity] directly by the associativity value. @Stan` I was thinking, if our timer problems are CPUID problems? Do we read the CPUID to get the right timer? I know from my SIMD patches, that we use CPUID in other parts of the code too. I think it might be good, to have a look on this implementations. Maybe they need changes too. I don't know if the CPUID changes came with Zen2, or earlier. If the changes are older, we may had only luck, that the first Zen CPUs didn't crash too. But this is only speculating.

I guess the workaround for the hardware detection is not working for the Threadrippers, so it crashes by starting the game. I remember, there was another Threadripper guy, who didn't get it to work. So I think, we should drop the detection, or do the correct implementation. Especially as we have good chances, to get the next problems, when the new Ryzen gen will be released. Maybe @Imarok could do that, if he has the time? For more informations have a look on the post at the AMDs forum here.

Don't know why you get the wrong version. @Stan` any idea? I guess the files will only work with the 23b version. I only have a Ryzen CPU, but from the specs, the Threadrippers should have the same behaviour. So the fix should work. When installing the new version, and replacing the files, make sure your antivirus programm will not block some files.

I'm also thinking you are using an outdated version of 0 A.D.? The current alpha is 23b with the revision number r21946. Yours shows 23 with r21935.

@Stan`?

Here are the texts. https://github.com/0ad/0ad/tree/master/binaries/data/mods/public/gui/text/tips And here are the pictures. https://github.com/0ad/0ad/tree/master/binaries/data/mods/public/art/textures/ui/loading/tips

Dann lag es vermutlich tatsächlich am fehlenden Flag. Ohne dem geht dir schnell der Speicher aus. In der Release Version ist das Flag gesetzt, in der SVN Version nicht. Ohne Flag lassen sich wohl leichter Speicherfehler finden. So I think, the issue was actually the missing flag. The release version includes this flag. The developers version not, for developing reasons. Der Patch sollte eigentlich nur die Performance erhöhen in dem die Wegberechnung der Einheiten auf verschiedene Kerne aufgeteilt wird. Ich drück dir aber die Daumen, dass der Framebuffer Fehler nicht wieder auftritt. Hab den Fehler leider selber auch. Denke aber nicht dass der so bald gefixt wird, den gibts schon etwas länger. The patch should only speed up the game by threading the pathfinder. But I hope, you can go on playing your game without the framebuffer bug

Ich habe eben nochmals den Patch mit der aktuellsten SVN getestet. Nach 14min ohne Crash hab ich das Spiel dann beendet. Vielleicht gab es da einfach kurzzeitig einen Fehler in der SVN der jetzt behoben wurde. Wenn du Lust hast kannst du das gerne nochmals testen. Schau vielleicht, dass du vorher noch einen Cleanup machst damit du sicher bist, dass der Crash nicht durch irgendwelche Codereste/Überbleibsel ausgelöst wird. Ansonsten, falls du das "large addresse" Flag (https://trac.wildfiregames.com/wiki/premake) bereits gesetzt hast, hab ich leider auch keine Idee mehr (nicht mein Metier). Dass das Spiel ohne Crashlog crasht hört sich für mich zumindest mal nach dem fehlenden Flag an. I have tested the current svn with that patch without crashes. Maybe there was a problem, and it's gone now. Maybe you want to test it again? Else, did you set the "large addresse" flag?

e.g. this See the black lines in the top, and on the button.

Is that the same reason, why you get black lines in the GUI, when scaling the GUI? Or is this another bug?

Yes it's possible. Have a look on the link https://code.wildfiregames.com/D1253 Attend, that you won't get the real monitor resolution. You get the resolution that 0 A.D. uses. On Windows it's the monitor resolution divided by the scaling factor of Windows. But I think an extra option is too much work for to less people. I guess, nearly no one uses an monitor with an resolution lower than 1366 x 768 (old notebooks). If something is redone, it should be done for high resolution, in a view to the future. In a few years the named notebook resolutions will be obsolet too. So working on low resolution will be a waste of time. Meanwhile "gui.scale", like @Nescio said, should do the job.

I see, thx

Why don't have a third option? In my opinion, the more icons at once, the worse the clarity. So I would suggest to splitt them into sub panels like in Spellforce 3. I can think of three different variations. First possibility, splitting them into phases like Spellforce. Second possibility, splitting them into buildings and units. Or splitting them into civil and military.

I agree with that. Many of the users are allready using your experimental patch, as we didn't get any bug report, it seems to be working correctly. I self played only a few times since that. But I updated my comment in Phabricator anyway.

He starts 0 A.D. allready in VS, as you can see in his video. But I guess, he don't know (same as me) how to get the stacktrace. So maybe you could explain him, how to do?

I think, these are the two most interesting patches. Feel free, to help testing and reviewing, to speed up the development progress. https://code.wildfiregames.com/D14 https://code.wildfiregames.com/D2528

I remember there is another CPU which has his own VRAM. There was a Intel AMD cooperation. Intel has used some AMD graphic chips. They used HBM for the memory. But this CPU was very exotic, no normal mainstream CPU.

From what I understand of you link, they have no separate memory. They explain the false Windows display in the bottom boxes. The Iris Pro uses some eDRAM. Don't know if there are some more Intel CPUs with separate VRAM.

Intel has two different integrated graphics. I guess you meant the Iris Pro graphics? The normal integrated graphics do also use the RAM.

Correct, APUs don't have an own VRAM, they using the RAM. This is why the RAM is that important for the GPU speed. Dual channel configuration can double the performance compared to a single setup. And an 3200MHz RAM compared to an 2400MHz can have another impact of 25-35%. As @Stan` said it's possible to configurate the amount of RAM usage in the BIOS, but this not necessary. The usage is dynamicaly managed by the OS. So changing this configuration in the BIOS can make it worse than better.