This may be a somewhat silly question, but if you are working with a single board computer that boasts that it has 2d/3d graphics acceleration, what does this actually mean?
If it supports DirectX or OpenGL obviously I could just use that framework, but I am not familiar with working from this end of things. I do not know if that means that it is capable of having those libraries included into the OS or if it just means that it does certain kinds of math more quickly (either by default or through some other process)
Any clarification on what this means or locations of resources I could use on such would be greatly appreciated.
On embedded system's, 2D/3D Graphics Acceleration could mean a lot of things. For instance, that framebuffer operations are accelerated through DirectFB, or that OpenGL ES is supported.
The fact is that the manufacturer of the board usually provides these libraries since the acceleration of the graphics itself is deeply connected to the hardware.
It's best to get in touch with your manufacturer and ask which graphics libraries they support that are hardware accelerated.
There are two very important features of 2D/3D graphics cards:
Take a load away from the CPU
Process that load much faster than the CPU can do because it has a special instruction set that was designed explicitly for calculations that are common in graphics (e.g. transformations)
Sometimes other jobs are passed on to the GPU because a job requires calculations that fit very good to the instructions of the GPU. E.g. a physics library requires lots of matrix calculation so a GPU could be used to do that. NVIDIA made PHYSIX to do exactly that. See this FAQ also
The minumum a graphics display required is to allow the setting of the state (colour) of individual pixels. This allows you to render any image within the resolution and colour depth of the display, but for complex drawing tasks and very high resolution displays this would be very slow.
Graphics acceleration refers to any graphics processing function off-loaded to hardware. At its simplest this may mean the drawing and filling of graphics primitives such as lines, and polygons, and 'blitting' - the moving of blocks of pixels from one location to another. Technically graphics acceleration has been largely replaced by graphics processors (GPUs), though the affect is the same - faster graphics. GPUs are more flexible since a hardware accelerator can accelerate only the set of operations they are hard wrired to perform, which may benefit some applications more than others.
Modern GPU graphics hardware performs far higher level graphics processing. It is also possible to use the GPU to perform more general purpose matrix computation tasks using interfaces such as Nvidia's CUDA, which can then accelerate computational tasks other than graphics but which require teh same kind of mathematical operations.
The Wikipedia "Graphics processing unit" article has a history of Graphics Accelerators and GPUs
Related
I've just started looking to graphics tools and how it could be made to be faster without compromising performance and then this question came to mind: what is the difference of filling the screen pixels with some colors coordinated by some optimized code to deal with "graphics" versus the actual 2D/3D graphics tools such as OpenGL, Unity, etc.?
What I want to mean by that is the following: I was seeing this video about .kkrieger fps game that used only 96kB of memory. Of course it produced huge amount of need for CPU and GPU to perform well. But what if instead of compact size files, there was a way to actually do some nice graphics with great performance without a need for a very expensive CPU+GPU combo? Is that possible anyway?
One way of doing GPU programming is OpenCL, which will work with parallelized, number-crunching operations.
Now think of your favorite 3D PC game. When the screen renders, what's going on? Did the developers hand-craft an OpenCL kernel (or something like it), or are they using pre-programmed functions in the graphics card?
Sorry to make this sound like a homework problem, I couldn't think of a better way to ask it.
H'okay, so, I'ma answer this in terms of history. Hopefully that gives a nice overview of the situation and lets you decide how to proceed.
Graphics Pipeline
3D graphics have an almost set-in-stone flow of calculations. You start with your transformation matrices, you multiply out your vertex positions (maybe generate some more on the fly), figure out what your pixels ought to be colored, then spit out the result. This is the (oversimplified) gist of 3D graphics. To change anything in it, you just twiddle one aspect of the pipeline a bit with a 'shader', i.e. little programmable elements with defined inputs and outputs so that they could be slotted into the pipeline.
Early GPGPU
Back when GPGPU was still in its infancy, the only way people had access to the massively parallel prowess of the GPU was through graphics shaders. For example, there were fragment shaders, which basically calculated what colors should be on each pixel of the screen (I'm kind of oversimplifying here, but that's what they did).
So, for example, you might use a vertex shader to chuck data about the screen before reducing a bunch of values in the fragment shader by taking advantage of color blending (effectively making the tricky transformation of mathematical problem space to... well, color space).
The gist of this is that old GPGPU stuff worked within the confines of 3D graphics, using the same 'pre-programmed functions in the graphics card' that the rest of the 3D graphics pipeline used.
It was painful to read, write, and think about (or at least, I found it so painful that I was dissuaded).
CUDA and OpenCL and [all of the other less popular GPGPU solutions]
Then some folks came along and said, "Wow, this is kind of dumb - we're stuck in the graphics pipeline when we want to be doing more general calculations!"
Thus GPGPU escaped from the confines of the graphics pipeline, and now we have OpenCL and CUDA and Brook and HSA and... Well, you get the picture.
tl;dr
The difference between GPGPU kernels and 3D graphics kernels are that the latter are stuck in a pipeline with (convenient) constraints attached to them, while the former have far more relaxed requirements, the pipeline is defined by the user, and the results don't have to be attached to a display (although they can be if you're masochistic like that).
When you run a game there may be two distinct systems operating on your GPU:
OpenGL renders images to your screen (graphics)
OpenCL does general-purpose computing tasks (compute)
OpenGL is programed with shaders. OpenCL is programmed with kernels.
If you would like to learn in more detail how games work on the GPU, I recommend reading about OpenCL, OpenGL, and game engine architecture.
I was wondering if it would be possible to get graphical hardware acceleration without Xorg and its DDX driver, only with kernel module and the rest of userspace driver. I'm asking this because I'm starting to develop on an embedded platform (something like beagleboard or more roughly a Texas instruments ARM chip with integrated GPU), and I would get hardware acceleration without the overhead of a graphical server (that is not needed).
If yes, how? I was thinking about OpenGL or OpengGLES implementations, or Qt embedded http://harmattan-dev.nokia.com/docs/library/html/qt4/qt-embeddedlinux-accel.html
And TI provides a large documentation, but still is not clear to me
http://processors.wiki.ti.com/index.php/Sitara_Linux_Software_Developer%E2%80%99s_Guide
Thank you.
The answer will depend on your user application. If everything is bare metal and your application team is writing everything, the DirectFB API can be used as Fredrik suggest. This might be especially interesting if you use the framebuffer version of GTK.
However, if you are using Qt, then this is not the best way forward. Qt5.0 does away with QWS (Qt embedded acceleration). Qt is migrating to LightHouse, now known as QPA. If you write a QPA plug-in that uses your graphics acceleration by whatever kernel mechanism you expose, then you have accelerated Qt graphics. Also of interest might be the Wayland architecture; there are QPA plug-ins for Wayland. Support exists for QPA in Qt4.8+ and Qt5.0+. Skia is also an interesting graphics API with support for an OpenGL backend; Skia is used by Android devices.
Getting graphics acceleration is easy. Do you want compositing? What is your memory foot print? Who is your developer audience that will program to the API? Do you need object functionality or just drawing primitives? There is a big difference between SKIA, PegUI, WindML and full blown graphics frameworks (Gtk, Qt) with all the widget and dynamics effects that people expect today. Programming to the OpenGL ES API might seem fine at first glance, but if your application has any complexity you will need a richer graphics framework; Mostly re-iterating Mats Petersson's comment.
Edit: From the Qt embedded acceleration link,
CPU blitter - slowest
Hardware blitter - Eg, directFB. Fast memory movement usually with bit ops as opposed to machine words, like DMA.
2D vector - OpenVG, Stick figure drawing, with bit manipulation.
3D drawing - OpenGL(ES) has polygon fills, etc.
This is the type of drawing you wish to perform. A framework like Qt and Gtk, give an API to put a radio button, checkbox, editbox, etc on the screen. It also has styling of the text and interaction with a keyboard, mouse and/or touch screen and other elements. A framework uses the drawing engine to put the objects on the screen.
Graphics acceleration is just putting algorithms like a Bresenham algorithm in a separate CPU or dedicated hardware. If the framework you chose doesn't support 3D objects, the frameworks is unlikely to need OpenGL support and may not perform any better.
The final piece of the puzzle is a window manager. Many embedded devices do not need this. However, many handset are using compositing and alpha values to create transparent windows and allow multiple apps to be seen at the same time. This may also influence your graphics API.
Additionally: DRI without X gives some compelling reasons why this might not be a good thing to do; for the case of a single user task, the DRI is not even needed.
The following is a diagram of a Wayland graphics stack a blog on Wayland.
This is depend on soc gpu driver implement ,
On iMX6 ,you can use wayland composite on framebuffer
I build a sample project as a reference
Qt with wayland on imx6D/Q
On omap3 there is a project
omap3 sgx wayland
I used DirectDraw in C and C++ years back to draw some simple 2D graphics. I was used to the steps of creating a surface, writing to it using pointers, flipping the back-buffer, storing sprites on off-screen surfaces, and so on. So today if I want write some 2D graphics programs in C or C++, what is the way to go?
Will this same method of programming still apply or do I have to have a different understanding of the video hardware abstraction?
What libraries and tools are available on Windows and Linux?
What libraries and tools are available on Windows and Linux?
SDL, OpenGL, and Qt 4 (it is gui library, but it is fast/flexible enough for 2D rendering)
Will this same method of programming still apply or do I have to have a different understanding of the video hardware abstraction?
Normally you don't write data into surface "using pointers" every frame, and instead manipulate/draw them using methods provided by API. This is because the driver will work faster with video memory than if you transfer data from system memory into video memory every frame. You still can write data into hardware surface/texture (even during every frame), if you have to, but those surfaces may need to be treated in special way to get optimal performance. For example, in DirectX you would need to tell the driver that surface data is going to change frequently and that you're going only to write data into surface, never reading it back. Also, in 3D-oriented APIs (openGL/DirectX) rendering surface on the other surface is a somewhat "special case", and you may need to use "Render Targets"(DirectX) or "Framebuffer Objects"(OpenGL). Which is different from DirectDraw (where, AFAIK, you could blit anything onto anything). The good thing is that with 3D api you get incredibly flexible way of dealing with surfaces/textures - stretching, rotating, tinting them with color, blending them together, processing them using shaders can be done on hardware.
Another thing is that modern 3D apis with hardware support frequently don't operate on 8bit palleted textures, and prefers ARGB images. 8 bit surfaces with palette may be emulated, when needed, and 2D low-level apis (SDL, DirectDraw) provide them. Also you can emulate 8bit texture on hardware using fragment/pixel shaders.
Anyway, if you want "old school" cross-platform way of using surfaces (i.e. "write data every frame using pointers" - i.e. you need software renderer or something), SDL easily allows that. If you want higher-level, more flexible operations - Qt 4 and OpenGL are for you.
On Linux you could use OpenGL, it is not only used for 3D support but also supports 2D.
SDL is also pretty easy to use, out of the box. It is also cross-platform, and includes (and has a lot of) plugins available to handle your needs. It interfaces nicely with openGL as well should you need 3D support.
Direct2D on Windows.
EGLOutput/EGLDevice or GEM depending on the GPU driver for Linux.
I read in this article that a company has created a software capable of using multiple GPU-based video cards in parallel to process hundreds of billions fixed-point calculations per second.
The program seems to run in Windows. Is it possible from Windows to assign a thread to a GPU? Do they create their own driver and then interact with it? Any idea of how they do it?
I imagine that they are using a language like CUDA to program the critical sections of code on the GPUs to accelerate their computation.
The main function for the program (and its threads) would still run on the host CPU, but data are shipped off the the GPUs for processing of advanced algorithms. CUDA is an extension to C syntax, so it makes it easier to programmer than having to learn the older shader languages like Cg for programming general purpose calculations on a GPU.
A good place to start - GPGPU
Also, for the record, I don't think there is such a thing as non-GPU based graphic cards. GPU stands for graphics processing unit which is by definition the heart of a graphics card.