I am working on embedded device and trying to figure-out basics of opengl-es-2.0, I am not able to understand what is the usage of libGLES_CM.so? what functionality does it provides? why there are two opengl-es related libraries 1). libGLESv2.so and 2). libGLES_CM.so?
It is there for OpenGL-ES 1.0, If there are two libraries 1). libGLESv2.so and 2). libGLES_CM.so available on Embedded Device, this means that board supports both opengl ES 1.0 and opengl ES 2.0.
Related
I'm trying to draw a triangle according to LINK
The problem is that my GPU is AMD Radeon (TM) R5 M330 // Discrete/Hybrid.
It supports Vulkan™ API Version 1.2.170.
Vulkan Sdk version is 1.3.216.0.
I get
'FeatureRestrictionNotMet(FeatureRestrictionError { feature: "dynamic_rendering", restriction: NotSupported })'
due to Vulkan supported API version with GPU
Is there any way to draw the triangle without the need of dynamic_rendering or is it possible to draw that using another way?
I am new to graphics programming and this will be my first experience with Vulkano-rust-AMD stuff.
I am building an NPAPI plugin for Linux that uses the XEmbed protocol for the window that is controlled by the plugin. I am using Gtk+ for attaching to the window, wrapping the XEmbed window with a GtkPlug. I want to render an OpenGL surface on the window (using GtkGLExt) but when I enable the resulting OpenGL context I am unable to create GLSL shaders; indeed, querying the value of glGetString( GL_VERSION ) shows that the version string for OpenGL has changed from "2.1 NVIDIA..." to "1.4 (2.1 NIVIDIA...)", suggesting that the GL drivers have downgraded the OpenGL functionality in this situation.
I haven't been able to find any direct references to limitations that using XEmbed places on OpenGL functionality. Does anyone know if XEmbed effectively downgrades OpenGL to a fixed pipeline?
I'd like to open an OpenGL context without X in Linux. Is there any way at all to do it?
I know it's possible for integrated Intel graphics card hardware, though most people have Nvidia cards in their system. I'd like to get a solution that works with Nvidia cards.
If there's no other way than through integrated Intel hardware, I guess it'd be okay to know how it's done with those.
X11 protocol itself is too large and complex. Mouse/Keyboard/Tablet input multiplexing it provides is too watered-down for modern programs. I think it's the worst roadblock that prevents Linux desktop from improving, which is why I look for alternatives.
Update (Sep. 17, 2017):
NVIDIA recently published an article detailing how to use OpenGL on headless systems, which is a very similar use case as the question describes.
In summary:
Link to libOpenGL.so and libEGL.so instead of libGL.so. (Your linker options should therefore be -lOpenGL -lEGL
Call eglGetDisplay, then eglInitialize to initialize EGL.
Call eglChooseConfig with the config attribute EGL_SURFACE_TYPE followed with EGL_PBUFFER_BIT.
Call eglCreatePbufferSurface, then eglBindApi(EGL_OPENGL_API);, then eglCreateContext and eglMakeCurrent.
From that point on, do your OpenGL rendering as usual, and you can blit your pixel buffer surface wherever you like. This supplementary article from NVIDIA includes a basic example and an example for multiple GPUs. The PBuffer surface can also be replaced with a window surface or pixmap surface, according to the application needs.
I regret not doing more research on this on my previous edit, but oh well. Better answers are better answers.
Since my answer in 2010, there have been a number of major shakeups in the Linux graphics space. So, an updated answer:
Today, nouveau and the other DRI drivers have matured to the point where OpenGL software is stable and performs reasonably well in general. With the introduction of the EGL API in Mesa, it's now possible to write OpenGL and OpenGL ES applications on even Linux desktops.
You can write your application to target EGL, and it can be run without the presence of a window manager or even a compositor. To do so, you would call eglGetDisplay, eglInitialize, and ultimately eglCreateContext and eglMakeCurrent, instead of the usual glx calls to do the same.
I do not know the specific code path for working without a display server, but EGL accepts both X11 displays and Wayland displays, and I do know it is possible for EGL to operate without one. You can create GL ES 1.1, ES 2.0, ES 3.0 (if you have Mesa 9.1 or later), and OpenGL 3.1 (Mesa 9.0 or later) contexts. Mesa has not (as of Sep. 2013) yet implemented OpenGL 3.2 Core.
Notably, on the Raspberry Pi and on Android, EGL and GL ES 2.0 (1.1 on Android < 3.0) are supported by default. On the Raspberry Pi, I don't think Wayland yet works (as of Sep. 2013), but you do get EGL without a display server using the included binary drivers. Your EGL code should also be portable (with minimal modification) to iOS, if that interests you.
Below is the outdated, previously accepted post:
I'd like to open an OpenGL context without X in linux. Is there any way at all to do it?
I believe Mesa provides a framebuffer target. If it provides any hardware acceleration at all, it will only be with hardware for which there are open source drivers that have been adapted to support such a use.
Gallium3D is also immature, and support for this isn't even on the roadmap, as far as I know.
I'd like to get a solution that works with nvidia cards.
There isn't one. Period.
NVIDIA only provides an X driver, and the Nouveau project is still immature, and doesn't support the kind of use that you're looking for, as they are currently focused only on the X11 driver.
You might be interested in a project called Wayland
http://en.wikipedia.org/wiki/Wayland_%28display_server%29
Have you looked at this page?
http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_
It is likely a bit outdated. I haven't tried yet, but I would appreciate more documentation of this type.
Probably a good idea, as of today, is to follow Wayland compositor-drm.c implementation:
http://cgit.freedesktop.org/wayland/weston/tree/src/compositor-drm.c
https://gitlab.freedesktop.org/mesa/kmscube/ is a good a reference implementation of OGL (or OGLES) hardware-accelerated rendering without an X11 or wayland dependency.
You can look at how Android has solved this issues. See Android-x86 project.
Android uses mesa with egl and opengles. Android has its own simple Gralloc component for mode setting and graphic allocations. On top of that they have SurfaceFlinger component which is a composition engine, which uses OpenGLES for acceleration.
Cannot see why couldn't you use these components in similar way and even reuse the Android glue code.
I have Windows CE 5.0 device and it doesn't support any hardware accelearation.
I am looking for some good 2d graphics library to do following things.
I prefer backend programming in Compact .Net Framework.
Drawing fonts with antialiasing.
drawing lines, and simple vector objects with antialiasing.
I am not doing animation, so i don't care about frames per seconds performance.
i have looked into following libraries, but nothing suits me.
opengl (vincent 3d software rendering) - works, but api is very low level and complex.
openvg - no software implementation for windows ce.
Cairo - api is very neat, but no wince build.
Adobe Flash - installs as browser plugin , no activex support in wince.
Anti-aliased fonts in .Net CF 2.0+ can be done with Microsoft.WindowsCE.Form.LogFont -- after creating your logfont, you can use it with any WinForms widget's .Font property by converting it using System.Drawing.Font.FromLogFont().
...you might need to enable anti-aliasing in the registry for these to render properly, see this MSDN article for the right keys: [http://msdn.microsoft.com/en-us/library/ms901096.aspx][1].
There was a decent implementation of GDI+ for .Net CF 1.0 called "XrossOne Mobile GDI+", it's not longer supported, but you can get the source code here: http://www.isquaredsoftware.com/XrossOneGDIPlus.php -- Run it through the import wizard on VS2008 to build it for later versions of CF. I liked this library for its alpha transparency support without hardware acceleration, rounded rectangles and gradient support.
Someone was advertising this library in some forum. It's for Windows Mobile, but you can check it out. I have no experience with it.
link
I have Google's skia library compiling under WindowsCE, although I haven't done much with it yet :) It wasn't too hard to get working. It does support a OpenGL/ES backend.
There is also AGG (Anti Grain Geometry) which is a heavy C++ library based on templates.
I am writing an OpenGL game which will hopefuflly be for both linux and iphoneOS, I basically want to be able to build using the OpenGL ES 1.5 headers and run it on my linux desktop. Can I do this? IE, I want to only use the subset of API calls common between OpenGL and OpenGL-ES.
Doing the above and linking with normal libGL.a from my system gets me my screen but I seem to be able to do nothing but change the scene background colour.
I've done exactly that, and it worked well for me.
There are a bunch OpenGL|ES extensions that aren't available on standard OpenGL but very nice to have on a low spec platform. glDrawTexImage is such an extension. Emulating these extensions using a hand full of desktop OpenGL-calls is not a big deal though.
Also OpenGL|ES supports the fixed-point data-format for most entrypoints. Take glClearColorx for example. These aren't available for the desktop OpenGL, so you have to write a wrapper if you want to use them. It's a bit more work if you also store your vertex data in this format.
Oh - and note that OpenGL|ES does not come with the glu-library. You can use it on the desktop, but if you do you'll have to reimplement them later (see the 100 questions about gluLookAt and gluUnproject).
There is no such thing as OpenGL ES 1.5. Did you mean 1.1 ?
Also, how do you get a window ? This is platform specific.
In any case, you still should compile against the header that corresponds to the lib you will link against. You don't know for sure what the header sets up (e.g. on windows, which you don't care about but still, calling conventions are specified in there).
There are also some calls that don't map well between the 2. E.g. APIs that are only using doubles in GL are float in GLES (from the ES spec):
The double-precision only commands
DepthRange, Frustum, and Ortho are
replaced with single-precision or
fixed-point variants
So in short, there is a bit more work than just using the same code, although the work in question is still minimal if you stick to GL ES subset.