I'm developing an operating system targetting the ARM architecture, more specifically, a RaspberryPi 4B. For that I've already managed to use the "Mailbox Property Interface" to draw some shapes on the screen. Out of curiosity I would like to know if it was possible to use OpenGL (or OpenGL ES, preferably) to render future more complex graphics. If possible, how do I do it?
You want to find out which driver the usual Raspberry Pi software uses, then adapt that driver to work on your OS. This is the code that interprets your OpenGL commands and translates them to the GPU's native language. Note there is both a kernel part and a user-space part.
It's probably not worth trying to write your own. Graphics is a whole field of study, it's like writing another OS just for the graphics card.
Related
I want to install some libraries, namely MonoGame, on my Windows10 computer. There appear to be a WindowsDX and WindowsGL (or DesktopGL). What is the basic difference between references to WindowsDX and GL. Thanks.
I assume WindowsGL refers to the Windows implementation of OpenGL. OpenGL is an open, industry standard library and interface for using/programming graphics hardware.
WindowsDX probably refers to Windows DirectX. DirectX is a suite of libraries for multimedia programming in general, including D3D for interfacing with graphics hardware, in particular.
The capabilities are comparable, but the interfaces differ.
Windows supports both, with OpenGL possibly being handled by translating commands into their DirectX equivalents at some level of the driver stack. I don't think any non-Windows platforms support DirectX.
I have successfully shared a GPU-based OpenGL context with OpenCL (using CL_CONTEXT_PROPERTY_USE_CGL_SHAREGROUP_APPLE when creating the OpenCL context).
However if the OpenGL context is software-based (created with kCGLPFARendererID, kCGLRendererGenericFloatID), then OpenCL context creation failed with error CL_INVALID_DEVICE (-33).
Is it possible to group-share a CPU-based OpenCL context with a CPU based OpenGL context?
If so, how?
I think this is a SDK/ Driver specific problem. So you should try to ask this question in a developer forum of the hardware you are trying to use.
For example you can register without problems at this page for amd related stuff:
http://devgurus.amd.com/welcome
There you get answers also from AMD interal developers like driver developer. I think they could tell you if it is possible or not.
For the Intel side of live you should try this place:
http://software.intel.com/de-de/forums/intel-opencl-sdk
But there i can't tell you how likely the internal developers try to answer.
I am trying to figure out the relationship between CGL and OpenGL on Mac platform.
More specifically about the context. Do they share context? If yes, how? Please give me a link to some related examples.
If no, then are there two contexts working in Core Animation applications which make use of OpenGL?
I am very confused by the use of OpenGL by Mac. Can somebody clarify?
CGL sets up device specific contexts suitable for OpenGL to render to. Compare to wgl and xgl on Windows and X respectively. CGL understands how to query the graphics hardware for its pixel format, and then how to set up and configure a context (e.g. double-buffered or single-buffered, what resolution depth, stencil, accumulation buffer, etc). But it doesn't provide functions to draw in that context. Once you have created the context with CGL, you make it current, and then you can call OpenGL to render in that context.
In Core Graphics (do not confuse it with CGL), both context initialization and drawing into the context are handled by the same framework. But because OpenGL is an open standard and designed to be cross-platform, the rendering functionality and the device context functionality have been abstracted into separate frameworks.
CGL is the low-level interface to OpenGL on a Mac. You probably don't want to be using it if you are writing an OpenGL Mac app. I am currently in the process of creating a intuitive OpenGL Mac application template for XCode 4, but in the mean time you can look at https://github.com/mk12/Pong-Ultimate, a pong clone I made using OpenGL. It uses NSOpenGL, a higher-level Cocoa interface to OpenGL.
You may also find the Apple docs helpful: http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_intro/opengl_intro.html.
What is the Direct3D? It is an API, is not it? Is it implemented by Windows or by graphics cards?
If the graphics cards implement the Direct3D API, why can not other operating systems use Direct3D resources from the graphics card?
If Direct3D is implemented by Windows, it has to use graphics card resources, such as OpenGL or OpenCL. If Direct3D calls are not directly to the graphics card, it would be slower due to intermediate calls.
Please, help me to understand what the Direct3D is.
What is the Direct3D? It is an API, is
not it? Is it implemented by Windows
or by graphics cards?
Yes, Direct3D is an API. It is implemented (mostly) by Windows itself. However, Windows will offload a considerable part of the actual work to the drivers of the graphics card and ultimately to the gfx card itself, so one can also say that a gfx card "implements" D3D.
If the graphics cards implement the
Direct3D API, why can not other
operating systems use Direct3D
resources from the graphics card?
They can, and they do, but only a relatively small (but often critical part) of D3D functionality is implemented directly by the card's hardware, so a lot more work in software is required to implement D3D.
If Direct3D is implemented by Windows,
it has to use graphics card resources,
such as OpenGL or OpenCL.
No, that's a misunderstanding. OpenGL and OpenCL are also APIs, and only partially implemented by the gfx hardware (just like D3D). The gfx hardware usually has a (proprietary) "native" API, which is what the gfx drivers (both for D3D and OpenGL) use.
If Direct3D calls are not directly to
the graphics card, it would be slower
due to intermediate calls.
There are not necessarily any "intermediate calls" - the D3D driver uses the cards native API, as explained above.
Direct 3D is a graphics API created by Microsoft. Its similar in function to opengl. OpenGL is a competing 3D graphics API created as a open standard. D3D doesn't need OpenGL to function.
Card manufactorers decide which APIs they want to implement; most always include DirectX (which includes Direct3D) and possibly OpenGL.
There is indirection as it doesn't go directly to the card, the cards D3D in turn calls the drivers, but this typicially is insignificant.
Direct3D is an API developed by Microsoft designed to help developers render 3D graphics. OpenGL and Direct3D are two separate APIs, but they must both interface to the video card using the drivers developed by the companies who manufacture the video cards. Both APIs (Direct3D and OpenGL) must both go through the driver in order to access the video card, and their speeds are dependent upon their design and their implementation in the video card drivers.
OpenCL is something different -- it's designed to help developers write programs which perform general-purpose computing on the GPU (not just for graphics). OpenCL is comparable to CUDA, but the latter in only supported on NVIDIA cards. Using CUDA instead of OpenCL may have some advantages, depending on your target system, since NVIDIA can make new features available to the CUDA API before they are accepted into the OpenCL API. However, even OpenCL and CUDA must interface to the driver in order to get anything done on the GPU.
As you already know, Direct3D only works on Microsoft and on Wine (for the most part), but its structure as an API is vastly different from that of OpenGL. Direct3D makes use of structures and includes more OOP elements in its API, while OpenGL acts as a state machine, lacking any structures or OOP features. Direct3D can often progress a little faster than OpenGL in terms of the features which it claims to officially support in its API because it is not designed for maximum compatibility with a wide range of devices; on the other hand, OpenGL has typically exhibited more inertia when it has come to adopting new features because of the inherent difficulty in adding new features to its API (the Khronos Group is influenced heavily by the CAD industry as well as many others, so it must cater to a wide range of needs). The time it took for the Khronos Group to finally adopt asynchronous API calls in the OpenGL is testament to this fact, and caused many people to lose faith in OpenGL.
However, OpenGL is cross-platform, endorsed by Apple, and it works on all operating systems on which it is implemented. You can easily use it with many popular window toolkits (Qt, SDL, FreeGLUT, JogAmp, gtk, etc.) and have confidence that your application will compile on other operating systems if you wrote it properly. The OpenGL API, unlike Direct3D, is an open-source industry standard.
As far as performance goes, it's still debatable as to which one is faster: depending on how you structure your program or batch your calls, this could change. However, performance should not really be a consideration for which API you use unless you have tested your application and have evidence that the choice of API is the cause of your bottleneck.
From Wikipedia:
Direct3D is a Microsoft DirectX API
subsystem component. The aim of
Direct3D is to abstract the
communication between a graphics
application and the graphics hardware
drivers. It is presented like a thin
abstract layer at a level comparable
to GDI (see attached diagram).
Direct3D contains numerous features
that GDI lacks.
Direct3D is an Immediate mode graphics
API. It provides a low-level interface
to every video card 3D function
(transformations, clipping, lighting,
materials, textures, depth buffering
and so on). It also had a higher level
Retained mode component, that has now
been officially discontinued.
I have ported uCLinux on an embedded board and want to provide it a GUI
layer.
Actually my board is consist of an ARM processor and other peripherals and
a touch screen display.
Actually this is a small embedded board which I have made .
I want to display various gui widgets like buttons , scrollbars etc . I
want to use QT for this purpose.
But I don't know how to proceed , how I can make the QT GUI layer to
interact with kernel
So , can you tell me how can I make it to talk to the uClinux kernel, I
mean how can I interface it to the kernel.
Thank you
I'd suggest you to use an embedded Linux build system. The historical one for systems based on uClinux is called uClinux-dist, but you can also use other build systems such as Buildroot. It already integrates Qt, so you'll only have to select an option, run make, and you'll have a Busybox+Qt system ready.
From the graphical side, Qt can directly use the kernel framebuffer, so as soon as your kernel has the framebuffer driver for your platform, you're ok. For the input side (keyboard, mice, touchscreen, etc.), Qt uses the Linux input subsystem, so if your input devices are supported by the kernel, Qt will be able to use them directly, with nothing additional needed.
Take a look at LVGL. It's easy to port and comes with many widgets.