Mesa Looks To Take Use Of C11 Threading

[phoronix]

Phoronix: Mesa Looks To Take Use Of C11 Threading

Jose Fonseca is seeking comment from Mesa developers about possibly taking advantage of C language thread primitives that were introduced in the new C11 standard...

http://www.phoronix.com/vr.php?view=MTMyODY

[mayankleoboy1]

who uses LLVM pipe on windows ?
I can think of maybe Chrome, when Hardware acceleration is not available...

[schmidtbag]

who uses LLVM pipe on windows ?
I can think of maybe Chrome, when Hardware acceleration is not available...

Aside from a VM or server, when is hardware acceleration not available in windows?

[GreatEmerald]

Aside from a VM or server, when is hardware acceleration not available in windows?

When you don't have drivers installed (and disabled auto update, if on Win7+).

[mayankleoboy1]

Aside from a VM or server, when is hardware acceleration not available in windows?

Or have obsolete drivers, which dont expose enough API's, and crash.

[curaga]

Looks like even gcc 4.8 doesn't support C11 threads. So the wrapper here may live for a long while still.

[smitty3268]

Aside from a VM or server, when is hardware acceleration not available in windows?

A lot of older Intel drivers on Windows are incredibly buggy. Especially OpenGL support.

And there are a lot of machines out there with outdated Intel drivers.

[zxy_thf]

It's great to have a unify abstraction.
I think using OpenMP is a better idea on LLVMpipe however.

[schmidtbag]

@mayankleoboy and smitty
If that's the case, you should not be running LLVM for graphics because chances are the CPU will struggle so badly the program won't be usable. IIRC, LLVM can barely play old games at 30FPS at lowest details on an i7. While LLVM isnt meant for gaming, a system where GPU drivers are faulty to the point of failure is likely to not have a CPU capable of LLVM.

But suppose in the off chance your proposed system did have a worthy CPU. Chances of someone with a system like that knowing LLVM exists is pretty slim.


Im not saying either of your answers are wrong, but I'm looking for a more realistic scenario.

[elanthis]

who uses LLVM pipe on windows ?
I can think of maybe Chrome, when Hardware acceleration is not available...

Chrome uses DirectX 9 on Windows. The WebGL API is translated via ANGLE to D3D. When it comes to software rasterization, they could port ANGLE and their page/canvas rendering/compositing code to D3D11 (a new but much improved API) and get WARP. It not only is quite fast, it was designed for the debugging and performance testing of apps, making it useful in its own right even if hardware support is available. Chrome has little use for Mesa.

I kinda wish Chrome would better abstract rendering and at least offer a more modern API. Having looked at embedding Chromium (via CEF and similar libraries) into a game for main UI development, I've been turned off by the shoddy performance. chrome still does a lot of CPU-side compositing. Rendering a "page" involes using the GPU for some operations, downloading render target textures to the CPU, doing software ops, handing those over to the host app, which then has to upload back to the GPU, wasting precious GPU bandwidth and forcing graphics pipeline stalls. There's no compelling technical reason why Chrome couldn't hand over a texture reference for a fully GPU-composited page (in D3D9, D3D11, GL, whatever the rendering backend is set to) for the game to use in its own final scene compositing. It also unfortunately requires the multi-process architecture (good for PC, non-starter for consoles) and has no way to set resource limits or a custom memory allocator, which one needs for consoles.

This is one of several reasons why Flash will remain dominant in games for years to come. Libraries like Scaleform provide real host app integration and a wider range of renderers (including for non-D3D, non-GL platforms with very particular requirements) and can be used for real-time interactive HUDs in games. Iggy looks promising, too; I might take a crack at integrating it into our commercial engine next week. I'd really like to see HTML5 take off here, but it's not (yet) feasible. Even the game-oriented Awesomium is limited to being basically a PC-only library due to Chrome's architecture (and license; LGPL WebCore is a problem for some platforms that ban dynamic linking), and still is only something I'd even consider using in screens outside of actual gameplay on a PC-only game. Maybe someday a non-horrible alternative to LibRocket will appear (that lib is severely lacking in features, has no JS support, relies on weird non-standard extensions for things HTML5 can do in a standard way, and was obviously designed by PC developers with no care about resource or memory management, and its pluggable renderer API is not friendly to some platforms requirements; even porting it to GL Core Context was a total bitch, on par with porting AntTweakBar).

These are all areas where in theory FOSS could crush proprietary vendors... but they don't. Just like the sound middlware scene (no, OpenAL is not middleware, it's a low-level sound API that serves as a backend to real middleware like FMOD, Miles, or Wwise on platforms that use it). Likewise for most other interesting game middleware; the only viable options are proprietary solutions or custom rolling (at great expense) your own.