Mesa Looks To Take Use Of C11 Threading

[smitty3268]

Why care about XP users, the OS is EOL next year...

I'm not sure of Chrome's exact usage statistics, but I wouldn't be surprised if Windows XP usage was still their #1 operating system.

It's got to at least be #2.

And I'm sure it's way, way ahead of the combined Linux and OSX market share.

So would you also be in favor of making a change that is incompatible with Linux and OSX, and dropping support for those OS's? I mean, according to your logic, who cares about those users, right?

[dee.]

Why care about XP users, the OS is EOL next year...

[smitty3268]

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.

Only if they don't care about windows xp users. Which means you are talking about adding another backend only available to a subset of their users, and increasing the amount of maintenance they have to do and the amount of code running they have to provide security audits on, etc.

Also, they've only chosen to use angle because OpenGL drivers suck on windows. The core browser still has it in OpenGL, so I'm not convinced translating that to D3D just to use a software renderer would be any better than using another software renderer that accepts the native GL commands. Maybe it would be, but you'd have to do some actual testing to show me why, rather than just assuming it must be.

[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.

[przemoli]

And you have horribly unrealistic assumptions about people having good GPU drivers...

Mozilla stats for Firefox WebGL and layers code that need GPU show only 30% of FF users have up to date, and ok GPU drivers. That is called minority.

(And no wonder. Auto-magical GPU driver update on Windows is nogo..)

[przemoli]

LLVMpipe is good for testing (as reference implementation) and for thouse unlucky folks who do not have GPU capable of given API. They can play with it on CPU then (eg for learning purposes..)

[smitty3268]

@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.

I believe at one time there was a project to provide WebGL support in Firefox through LLVM. As an extension, not the default. I'm not sure whatever happened to it.

I agree, LLVM isn't for playing games, it's way too slow for that purpose.

[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.

[zxy_thf]

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

[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.