You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reported in version: HG 2.1 Reported for operating system, platform: Linux, Other
Comments on the original bug report:
On 2020-12-26 14:43:09 +0000, Ivan Kuzmenko wrote:
Created attachment 4609
patch
MCST Elbrus 2000 (E2K, https://en.wikipedia.org/wiki/Elbrus_2000) is a russian processor architecture based on VLIW/EPIC instruction set (like Intel Itanium (IA-64) architecture). Architecture has half native / half software support of most Intel/AMD SIMD (e.g. MMX/SSE/SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AES/AVX/AVX2 & 3DNow!/SSE4a/XOP/FMA4).
It also has built-in x86/x86_64 <-> e2k binary translators (RTC, http://www.mcst.ru/rtc and Lintel, http://www.mcst.ru/lintel) that can run code for x86/x86_64 architecture (Transmeta did something similiar with their Crusoe series) with SIMD extensions support.
Attached patch allows SDL2 to detect extensions supported by E2K like MMX, 3dNOW!, AVX etc. (test/testplatform log: https://termbin.com/7qs3).
On 2020-12-26 18:48:51 +0000, Ozkan Sezer wrote:
Which gcc version supports __builtin_cpu_name()? I can't find
documentation for it.
On 2020-12-26 19:15:43 +0000, Ivan Kuzmenko wrote:
Created attachment 4610
patch (USE THIS INSTEAD OF FIRST ONE)
On 2020-12-26 19:18:58 +0000, Ivan Kuzmenko wrote:
(In reply to Ozkan Sezer from comment # 1)
Which gcc version supports __builtin_cpu_name()? I can't find
documentation for it.
const char* __builtin_cpu_name (void)
That's a MCST lcc for E2K exclusive function which returns name of used CPU.
On 2020-12-28 19:54:30 +0000, Sam Lantinga wrote:
These tests should be based on runtime environment, not compiler environment. It's completely possible to build SDL with MMX defined and run it on a processor that doesn't have MMX.
Similarly for E2K, I assume that it's possible to compile SDL for x86 and then run it on that processor and it should detect the change at runtime.
Look at the code in SDL_GetCPUCacheLineSize() for an example of dynamically changing results based on the CPU type.
On 2020-12-28 21:37:57 +0000, Alibek wrote:
Sam, I'm afraid that there is no real need of doing so on E2K.
E2K unlike Intel, doesn't have CPUID instruction and there is no real way to know, for example, to know L1 cache size. I didn't really heard about such instruction or special register. The only way is to rely on numbers given by Linux kernel at /proc/cpuinfo. (And even these numbers are actually hardcoded into kernel)
3DNOW/MMX/SSE support in E2K is done at compile-time, we can only use compiler intrinsics that are translated into native E2K code. It's directly supported by vendor and common way to re-use code written for Intel processors. There is no such thing as "MMX support" in runtime.
If these macro values will be hardcoded into SDL binary, there can be also theoretical possibility that if software using SDL will be compiled with another compiler version that one that was used to compile SDL itself, the values returned by SDL_Has* functions can be outdated and not reflect what is really supported by compiler. For example, latest version of LCC (eLbrus C Compiler) does not support AVX2 but maybe it will be added in the future.
What I do suggest though, is to give ports ability to define SDL_Has3DNOW/MMX/SSE function as macros for such architectures. Therefore compiler can enable and optimize branches in applications that rely on these functions.
On 2020-12-28 21:51:31 +0000, Alibek wrote:
For example, latest version of LCC (eLbrus
C Compiler) does not support AVX2 but maybe it will be added in the future.
My bad, it does define AVX2 and seems implements it somehow.
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
patch (sdl_e2k_cpuinfo.patch, text/plain, 2020-12-26 14:43:09 +0000, 3135 bytes)Reported in version: HG 2.1
Reported for operating system, platform: Linux, Other
Comments on the original bug report:
On 2020-12-26 14:43:09 +0000, Ivan Kuzmenko wrote:
On 2020-12-26 18:48:51 +0000, Ozkan Sezer wrote:
On 2020-12-26 19:15:43 +0000, Ivan Kuzmenko wrote:
On 2020-12-26 19:18:58 +0000, Ivan Kuzmenko wrote:
On 2020-12-28 19:54:30 +0000, Sam Lantinga wrote:
On 2020-12-28 21:37:57 +0000, Alibek wrote:
On 2020-12-28 21:51:31 +0000, Alibek wrote:
On 2020-12-29 04:59:12 +0000, Sam Lantinga wrote:
The text was updated successfully, but these errors were encountered: