I need to software render OpenGL in Windows and have already found about Mesa3D, which doesn't provide DLLs and I'm having some pain to build... Are there alternatives available?
That depends on what OpenGL version you wish to accelerate. Depending on your needs, there are some alternatives available. I've listed those I'm aware of below:
OpenGL 1.0 & 1.1
Windows (since Windows NT 3.5) actually includes an OpenGL software implementation to begin with. If you haven't installed any other software rasterizer, this ought to be your default implementation. The Microsoft software rasterizer supports either OpenGL 1.0 or 1.1, depending on your platform, but will not accelerate anything newer than that. If your desired OpenGL version is covered by 1.0 or 1.1 (however unlikely), the solution should be sufficient. I'm unsure as to what extent the default Windows OpenGL software implementation covers the OpenGL ES 1.x frameworks through its OpenGL 1.0 or 1.1 support.
OpenGL 1.4
Furthermore, in Windows Vista, Microsoft included an emulation layer which may translate OpenGL into Direct3D; thus supporting up-to OpenGL 1.4. Additionally, this should mean that Windows Vista (and up?) runtimes may accelerate most parts of OpenGL SC. I've never used this emulator myself, and was quite surprised to hear about it, but it may be of interest to someone having to run one of these old frameworks in a Windows environment.
Note that the standard Windows OpenGL software rasterizer (OpenGL 1.0 or 1.1) is also included in Windows Vista and above.
OpenGL ES 2.0
Additionally, there's the ANGLE project which accelerates WebGL and OpenGL ES 2.0 by translating OpenGL ES 2.0 invocations to DirectX 9 and 11. Their development notes also mention that an OpenGL ES 3.0 solution is in the works. Never having used ANGLE, I cannot offer a verdict.
OpenGL 3.1
In addition to those mentioned above, Mesa 3D (which supports up to OpenGL 3.1) feature three software implementations:
swrast
softpipe
llvmpipe
Since I know very little of swrast (the original Mesa project software rasterizer) and softpipe (a reference driver) I'll refrain from going into these. The third implementation, llvmpipe, and probably the one that may interest you the most, is a high-speed software implementation that uses multithreading and JIT compilation to speed up simulation with native- and SIMD instructions.
I have used Swiftshader from Transgaming for a production project before and I must say, it was brilliant. A tad costly, but brilliant.
As far as I've searched, the only other option is using WebGL software renderer, that as of today only Chrome supports. Direct3D has the reference driver (which is really unstable) and Swiftshader, which is good and expensive.
After some more headaches I managed to build Mesa3D for Windows, but only an old version which had still some support for it. At least, it has an awesome performance.
Related
I am trying to make use of some ES 3.1 features, and it's unclear if this is supported:
I notice that there is an OpenGL ES 3.1 header in the emscripten repository which defines some of the functions I'm looking for, and I can include them successfully in my project. However, they are not available when I try to link:
error: undefined symbol: glDispatchCompute (referenced by top-level compiled C/C++ code)
warning: _glDispatchCompute may need to be added to EXPORTED_FUNCTIONS if it arrives from a system library
The documentation says that OpenGL ES3 is supported if I specify -s FULL_ES3=1 (which I am doing).
Since there are headers for it, is this functionality available? If so, how do I enable support for it? (Does it require manually loading extensions or enabling experimental support in emscripten, for example?)
First thing to realize, is that decent Browsers currently implement only WebGL 1.0 (based on OpenGL ES 2.0) and WebGL 2.0 (based on OpenGL ES 3.0). So that Emscripten SDK may implement only features presented by WebGL 2.0 + extensions, and, unfortunately, Compute Shaders are not presented in any way in WebGL (and there are no more plans to add this functionality in future).
By the way, WebGL 2.0 support has been added to Safari 15 (iOS 15) only this (2021) year, so that even OpenGL ES 2.0 will not work on all devices.
I notice that there is an OpenGL ES 3.1 header in the emscripten
The extra <GLES3\gl3*.h> headers are there not because Emscripten implements all of them, but because this is a common way to distribute OpenGL ES 3.x headers that existing applications may rely on to conditionally load / use OpenGL ES 3.x functions at runtime, when they available.
The documentation says that OpenGL ES3 is supported if I specify -s FULL_ES3=1 (which I am doing).
I think that documentation is more or less clear about what FULL_ES3=1 adds:
To enable OpenGL ES 3.0 emulation, specify the emcc option -s FULL_ES3=1 when linking the final executable (.js/.html) of the project.
This adds emulation for mapping memory blocks to client side memory.
There is no word about OpenGL ES 3.1 here, nor a reason to expect a wonder from Emscripten, as I can barely imagine a reasonable hardware-accelerated way to emulate things like Compute Shaders on top of OpenGL ES 3.0. And software emulation would be certainly of no use for most applications.
WebGPU 1.0 that promised to appear mid '2022, is more capable than WebGL 2.0. So that WebGPU developers already see that at one time native WebGL 2.0 implementation in the Browsers could be replaced by a WebAssembly module implementing this legacy API on top of WebGPU - but in some very distant future. The same could also bring OpenGL ES 3.1/3.2 features to Emscripten SDK - at least theoretically, if somebody will be still interested to work on this.
Qt5 can use the OpenGL driver or the DirectX Driver by using ANGLE. As we cannot depend on an installed OpenGL driver, we need to use the ANGLE backend. Unfortunately, this doesn't solve all deployment problems especially on Windows virtual machines without hardware acceleration. On these systems, we're getting an error message saying that the creation of an OpenGL context failed.
Screenshot: Failed to create OpenGL context for format QSurfaceFormat
We're deploying all required libraries (libEGL.dll libGLESv2.dll libeay32.dll msvcp110.dll msvcr110.dll d3dcompiler_46.dll) but we're still getting this error message.
How do you deploy a QML application that needs to run on end user machines without OpenGL driver and on (virtual) machines without Direct3D Acceleration?
There is a page on the Qt wiki mentioning this problem, but that's not very helpful for solving it.
Update for Qt 5.4.0:
My findings so far are:
Setting QT_ANGLE_PLATFORM=warp -> creates a windows without content.
Setting QT_ANGLE_PLATFORM=d3d9 -> same error dialog, as expected.
Setting QT_ANGLE_PLATFORM=d3d11 -> same error dialog, as expected.
Setting QT_OPENGL=desktop -> same as QT_ANGLE_PLATFORM=warp.
Setting QT_OPENGL=angle -> same error dialog, as expected.
Setting QT_OPENGL=software + opengl32sw.dll (mesa for windows) -> unpredictable: May run, may crash, may show the error dialog.
Update for Qt Quick 2D Renderer
Although, Mesa seems to be a partial solution, the configration seems to be very crash often in Qt 5.4.0 .
Another fallback could be the Qt Quick 2D Renderer, but unfortunately this crashes too.
Copying softwarecontext.dll into /scenegraph + Setting QMLSCENE_DEVICE=softwarecontext -> crash
Update after some user experience:
Angle
Has some render bugs on some systems
Does not work reliable on all systems
Angle with Warp
Not reliable
Desktop OpenGL
The default implements OpenGL 1.1, which is too old.
Not reliable, even if the OpenGL version is ok.
Has render bugs, if used by Qt
QtQuick2dRenderer
Has some major render issues
Crashes, Freezes
Works on systems without HW acceleration
Mesa OpenGL Backend
Seems to be quite reliable at the moment
quite slow in general, very slow on some systems.
Heavy Deployment weight
Conclusion: there is still no real solution for these systems
Update for Qt 5.5
Anno 2015: Broken graphics drives are still broken.
My conclusion for the moment is:
Use QtQuick2dRenderer if possible.
Use Mesa backend otherwise.
Skip Angle, skip Desktop OpenGL, skip Warp.
QT 5 has huge compatibility issue with opengl on some hardware configurations
Combination of Intel HD3000 driver and Nvidia/ATI card won't work on Windows 10.
https://bugreports.qt.io/browse/QTBUG-42240
Intel drops support for this card but their drivers has bug that leads to crash.
You cannot rely on hardware opengl if you want to support customers with HD3000.
Under Windows, opengl32.dll is the default OpenGL driver. It implements OpenGL 1.1 (really old version).
ANGLE has a baseline of OpenGL ES 2.0 and needs DirectX 9/11 installed to map the calls into.
So if you got a video card that doesn't have an OpenGL driver installed, an OpenGL driver less than 2.0, and/or DirectX 9/11 not installed, your app is not going to work.
In regards to virtualization and 3D acceleration, these maybe worth a read:
Why does Qt Creator 3.0.0 Welcome Mode not work in VM?
https://bugreports.qt.io/browse/QTBUG-34964
Also, if you run a multi monitor Windows environment under VirtualBox, 3d acceleration will be disabled.
I re-checked this to see if these problems have been fixed by the latest release of QT 5.12.2, but no they have not. The function described in the QT wiki entry OP referenced
https://wiki.qt.io/Qt_5_on_Windows_ANGLE_and_OpenGL sounds good but in practice it simply doesn't work.
I conclude avoid OpenGL on QT in any form. It's just too unreliable.
I recently moved the rendering part of a program of mine from GDI+ to OpenGL.
Now I'm wondering: are there any downsides to doing so?
For example, are there any versions of Windows (XP or later) that support GDI+ but not OpenGL?
Or, for example, is it possible for a lack of drivers (or poor drivers), or a lack of a graphics card, etc. to make OpenGL rendering impossible on a system on which GDI+ works fine?
(I understand the OpenGL might need to resort to software rendering on less capable systems, but aside from slowness, I'm wondering if it would ever simply not work correctly in a situation in which GDI+ would.)
It depends on the OpenGL version/profile you're using. Up to, inclusing Windows XP OpenGL-1.1 is available by default without additional drivers. Since Windows Vista the minimum available OpenGL version is OpenGL-1.4.
However if you need anything more than that, you're relying on the user installing the drivers that come from the GPU vendor; the drivers installed by default in a standard Windows installation don't cover OpenGL (for not perfectly sane reasons).
Programs and libraries that strongly depend on OpenGL-ES have resorted to incorporate fallbacks like ANGLE.
There are some idiosyncrasies, as for example: you cannot create a transparent OpenGL window, if transparency is disabled (which means, not at all, under XP). Otherwise, as datenwolf notes, there's ANGLE, but even that does not always work. Another option might be mesa3d compiled for the windows target, with software rendering enabled. This option might be the safest one and faster than the software OpenGL 1.1 implementation from Microsoft.
I've read places that Windows Phone 8 will not support OpenGL, and I'm unable to find anything useful in the SDK.
So am I or will I ever be able to use OpenGL (ES) in my Windows Phone 8 game? I have a game I would like not to rewrite completely to DirectX when porting.
Please cite good sources, the only thing I've found are speculations and blog posts with little to no information.
OpenGL isn't supported on WP8, but Direct 3D feature level 9_3 is supported. If you're looking to port over a game from OpenGL ES over to D3D have a look at the Angle Project. Angle Project helps bridge the gap between OpenGL ES 2.0 and D3D 9. It doesn't have WP8 targeting just yet and you'll have issues with runtime compile shaders not being supported on WP8, but Angle project is still a good first step.
Either way, for games portability with other platforms it's really best if you work with a middleware gaming framework such as MonoGame, Unity, Cocos2D, Havok, Marmalade, SharpDX, Ogre, Autodesk Scaleform or others. These engines will mostly handle cross platform support for you within their own framework (each with it's own limitations on code and assets portability).
If you already have an existing OpenGL game you want to port over to WP8, than Angle project if your best bet going forward. If you're just starting out creating a cross-platform portable game than choosing a gaming middleware framework that seems right for your game's needs is the way to go.
Marmalade does let you write OpenGL ES 2.0 code and make it work in Windows phone 8 without making you do anything
Check this for more details:
http://www.madewithmarmalade.com/windows-phone-8
Even if Windows Phone 8 supported OpenGL (which it doesn't), it would support OpenGL ES, not destkop OpenGL. Since it's for embedded platforms.
So that's no twice.
Gideros uses OpenGL and targets Windows RT/Phone graphics by means of a lightweight DX wrapper.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been thinking about starting a new graphics project and I want to use Java. Java has wrappers for all of the relevant GL functionality but I wonder how many people, including casual users, actually have decent GL drivers installed. By decent, I mean somewhat stable and fairly new (GL 1.5 support would probably do although the GLSL support that comes with 2.0 would be great). I could DirectX, even with Java, but I pretty much hate it and this project is supposed to be 'fun'. Also, I like the at least near-cross-platformedness of GL. So, anyone know of any non-imaginary stats on what percentage of Windows users have the drivers to run a GL app?
The Steam Hardware Survey is probably the best and most detailed source for info about what gamers have. Accurate statistics for the general population will be harder to come by. Instead, you should look at this in terms of how recent you want the graphics hardware. For example, any ATI chip from the R300 series (Radeon 9550+) onward supports OpenGL 2.0. On the NVidia side, any GeForce 6000+ series chip will support OpenGL 2.0, and their predecessors, the FX series, almost supported OpenGL 2.0. The R300 series and the FX series were both introduced in 2002, so if you know what portion of your target market is using a PC from 2003 or later, you'll have a fairly good idea of how widespread OpenGL 2.0 support is among users with discrete graphics.
If you want to support integrated graphics (which are the largest segment of the market, but aren't particularly common with those who are serious about graphics of any kind) your users will need at least a GMA X3000 for hardware acceleration of OpenGL 2.0 features, which means their system has to be from 2006 or later.
If you're interested in support on other operating systems, any Intel Mac will support OpenGL 2.0 with software fallbacks, and hardware acceleration whenever the chip would support it under Windows. On Linux, any system with Mesa 7 or later (June 2007 or later) will support OpenGL 2.0 software rendering. Hardware acceleration is less reliable, but there are decent open-source drivers for ATI chips from R300 and newer.
Every modern day video card supports OpenGL ... Shouldnt you be questioning how many Windows boxes have the Java runtime?
As I recall, Windows XP comes with 1.1 support out of the box. Vista upgrades this to 1.5. So you can at least count on those as an absolute minimum.
Apart from that, the GPU drivers from pretty much any vendor gives you at least 2.0 support.
But if I were you, I'd reconsider DirectX. I don't know what you hate about it, but it does have some advantages. The tool support is vastly better (ie, there are tools available. And PIX is nothing short of amazing), the API is up to date, and well designed, rather than accumulated over 20 years of a committee working at cross purposes, and if this is limited to Windows anyway, cross-platform doesn't really matter. (On the other hand, of course, if you do need cross-platform capabilities, it doesn't really matter what else DirectX can offer, it won't deliver that one killer feature)
Nearly everybody has SOME form of OpenGL support. Experience has shown that the actual drivers involved can be quite poor when dealing with ATI and especially Intel hardware, but it will at least work, aforementioned bugs notwithstanding. If nothing else, Windows can fall back to its built in 1.1 (XP and earlier) or 1.4 (Vista and higher) implementation. It won't work well, but it will work.
Windows XP comes with OpenGL 1.1 (quite slow though). Windows Vista also comes with OpenGL 1.1 (but for some special applications it has OpenGL 1.4 emulator on top of D3D).
When you install a graphics driver on Windows, it installs a more OpenGL version. OpenGL 1.5 is roughly "DX9 shader model 2.0" capable hardware. How many machines have that kind of hardware depends on your target market. In traditional/hardcore games space, almost all will (see Steam Hardware Survey).
In more casual/small games space, quite a lot of machines have much older hardware (see Unity Hardware Stats - almost 30% in 2009 Q1 are older than "DX9 shader model 2.0"). Also, a lot of machines in that space do not have custom drivers; they use whatever display drivers are shipped in Windows (which do not provide anything more than GL 1.1). Again, see Unity Hardware Stats - the most popular driver versions are the ones that come with Windows.
Stability wise, I'd strongly suggest using D3D9 on Windows instead of OpenGL. Driver quality is much better for D3D9 (less crashes inside drivers, less incorrect rendering, better performance, ...).
I'd say that all Windows users have some support for OpenGL. The latest versions usually are reserved for Vista users, gamers, and developers.