E2k support #3288
E2k support #3288
Conversation
Can you give examples of such stations? Where are they being deployed? What is the demand actually like, practically speaking? I have literally never even heard of Elbrus until this pull request, and I can't imagine the maintenance burden is going to be worth merging this. |
You may found some examples in MCST product catalog and INEUM product catalog. Unfortunately, these pages are in Russian yet, but you may use Google Translate if you want.
If you're speaking of numbers, there are several thousands of machines are deployed for now, and even more are planned to be made. Not as many as x86_64 or even ARM, or even RISC V, but at least not just single prototypes. If you're speaking of exact demand of OBS installed on these machines, I don't know exactly, but I've heard from some people that they want to have OBS on their workstations, but they can't just build it from the upstream due to issues that are being fixed by this PR.
As this PR does not introduce major changes, but some clear, simple and obvious fixes, I see no reason it could lead to maintenance hell you're thinking of. |
|
Doom3 on e2k: https://youtu.be/6CGxTn_I3n0 |
| set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DSIMDE_ENABLE_OPENMP") | ||
| set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DSIMDE_ENABLE_OPENMP") | ||
| CHECK_C_COMPILER_FLAG("-fopenmp-simd" C_COMPILER_SUPPORTS_OPENMP_SIMD) | ||
| if(C_COMPILER_SUPPORTS_OPENMP_SIMD) | ||
| set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fopenmp-simd") |
There was a problem hiding this comment.
If openmp{,-simd} support is not enabled, then SIMDE_ENABLE_OPENMP should NOT be defined
There was a problem hiding this comment.
In the case of lcc, openmp-simd is always enabled, rather than disabled (and -fopenmp-simd is just an unrecognized option).
For this omp.c:
int main() {
int j;
#pragma omp simd
for(int i=1;i<1000;++i) ++j;
}
That's what I get on x86_64:
flandre ~ # gcc -fopenmp-simd -Wunknown-pragmas omp.c
flandre ~ # gcc -Wunknown-pragmas omp.c
omp.c: In function ‘main’:
omp.c:3: warning: ignoring #pragma omp simd [-Wunknown-pragmas]
3 | #pragma omp simd
|
flandre ~ #
So, unless I specify -fopenmp-simd, there is no support for #pragma omp simd.
But that's what I get on Elbrus:
tenshi ~ # lcc -fopenmp-simd -Wunknown-pragmas omp.c
lcc: error: unrecognized command line option "-fopenmp-simd"
tenshi ~ # lcc -Wunknown-pragmas omp.c
tenshi ~ #
You see, #pragma omp simd is supported without any options, but once I specify -fopenmp-simd, it starts failing due to unrecognized option.
Probably I get your point: you're about these compilers, who might have no support for openmp-simd, and thus have no option (it's not the case of gcc, which has this option, and not the case of lcc either, which has it always enabled). It can be diverged by compiler identification, though; should I implement this case then?
There was a problem hiding this comment.
clang doesn't have -fopenmp-simd, so that's the biggest problem.
The Intel compiler icc has a different, but equivalent option -qopenmp-simd that can be combined with -DSIMDE_ENABLE_OPENMP.
There was a problem hiding this comment.
Ah, ok, I see. So you mean clang ends up in setting CMAKE_COMPILER_IS_GNUCC or CMAKE_COMPILER_IS_GNUCXX true, and therefore enters this block?
If so, then looks like you're right. Thus the correct way here seems to be like this: check_c_source_compiles() and check_cxx_source_compiles() of source with #pragma omp simd with -Werror-unknown-pragmas, and based on this, decide, if compiler which does not support -fopenmp-simd actually allows omp-simd or not. Correct?
If so, I'll make another PR for this.
There was a problem hiding this comment.
Ah, I missed the CMAKE_COMPILER_IS_GNUCC part, whoops! So neither clang nor Intel's compiler will be affected by this section.
Seems that cmake doesn't know about the Elbrus lcc: https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_COMPILER_ID.html#variable:CMAKE_%3CLANG%3E_COMPILER_ID
So this section is fine, but there should be a comment explaining that it is necessary due to Elbrus lcc being misidentified as a GNU compiler by cmake.
There was a problem hiding this comment.
So, the only thing needed to do here is place a comment describing a situation?
(Yes, CMake does not distinguish LCC from GCC; actually LCC tries to mimic GCC to be used in building in place of GCC despite not having 100% compatibility with it.)
There was a problem hiding this comment.
So, the only thing needed to do here is place a comment describing a situation?
Yep!
There was a problem hiding this comment.
Ok. Should I post a PR for this then?
There was a problem hiding this comment.
Sure! Sorry for the confusion on my end.
Description
This pull request introduces support for building obs-studio on Elbrus hardware platform (which is based on Russian Elbrus CPU family) with its native lcc (eLbrus Compiler Collection) compiler.
Motivation and Context
As currently Elbrus-based stations are introduced into general puprose applications, including video streaming and recording, it is better to have OBS buildable on this platform directly from upstream, rather than being patched with some specific patches prior to building.
How Has This Been Tested?
Build and testing plan:
Details of Elbrus workstation:
Details of x86_64 workstation:
Results:
Successfully performed
mkdir build; cd build; cmake -DCMAKE_BUILD_TYPE=Release .. && make -j16 && sudo make installand ranobson both workstations; no suspicious behavior found.Types of changes
Checklist: