Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I'm looking into linux and Graphical API's, however I'm confused at how opengl is implemented in operating systems.
Is it just a set of libraries that use the kernel to "talk" to your graphics card about which pixels to colour or not?
if so then I don't know where the pipeline comes in - how 3D scenes are rasterized and shaders effect geometry.
And How Come GPU's can support shader languages from both DX and OGL? - and where do shader languages actually fit?- are they compiled, or interpreted at runtime?
I don't have very much experience with graphical API's myself despite using several game engines - usually the nitty gritty is far lost with several layers of abstraction.
I explained it thoroughly here: https://stackoverflow.com/a/6401607/524368 and here https://stackoverflow.com/a/7967211/524368
At least on most typical graphics cards, most of the OpenGL pipeline (fixed or programmable) is implemented in the graphics hardware itself. This is even more true of DirectX (i.e., DirectX is missing quite a bit of functionality in OpenGL that's not directly supported by current hardware).
Shaders are normally compiled. The graphics card has a special purpose processor (or, often, more than one) so the compiler takes the input in the shader language and turns it into the assembly language for that processor, much like a C compiler does for the CPU. Supporting different input languages isn't a whole lot different from a single CPU supporting input in C, C++, Pascal, Fortran, Cobol, etc.
I can't talk to how the API is implemented.
But I do know from experience that shaders are compiled. So you compile them and send them to your GPU where they're executed.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I see on quite a few job descriptions for embedded developer positions, that a requirement would be for example to have knowledge of embedded C programming on ARM microcontrollers.
What's not very clear to me is , what is the difference between having knowledge of developing C for a particular ARM processor, or developing C for a PowerPC or other type of processor. Developing with C we are abstracted from the actual instructions which will get compiled and the architecture so why does it really matter?
I would guess that it is important mainly to have knowledge of embedded development, knowing memory constraints etc. and that the actual target processor wouldn't matter too much. For example, won't a developer who was writing code for PowerPC MCUs for many years be just as good as developing code for an ARM-based or other type of MCU?
Perhaps i'm missing something obvious here. Please could someone give an example of what could be some major differences between writing C/C++ code for one type of processor and another type. Thanks
All you write about Linux and kernels, but 99% of the embedded work is purely bare metal. therefore, the knowledge of the core and peripherals is essencial.
In the most cases, before Linux programmers learn how to program the bare metal, they are way useless.
And this time needed costs your employer money.
As usual, it depends.
If you are going to develop at a deep C level, it is a good idea to know about the architecture, in order to optimize your code according to speed or/and memory (data bus size, instructions per clock, etc).
It is a must if you are going to develop at a deeper level (and if we are talking about ARM and its thumb, thumb2 and ARM... It is madness).
Furthermore, each architecture because of legacy reasons or to make our life better, adds some tricks. For instance, ARM PC points to the instruction after the next one to be executed, which is quite different in PowerPC or RH850 or whatever.
Above that (I mean, above or close to an OS), the compiler uses to be better than us, but anyway, it is a nice to know how it is working (and definitely it will make the debugging easier)
The answer is yes and no.
If a job is more of application related then MCU specific knowledge will be of little help
If the software development is at kernel/BSP/drivers or hardware related then the knowledge of MCU/CPU hardware is critical.
Please check the Job Description in details to know the kind of work expected.
Well, I haven't written any ARM code myself, but I would think the ARM-specific experience would be (in no particular order):
Experience with ARM-specific toolchains (particularly non-standard parts of that toolchain, pieces of proprietary software etc)
Knowledge of which relevant libraries are available on ARM rather than on Intel machines, and whether their ARM version is performant enough, stable enough etc.
Knowledge of how certain coding patterns look like when compiled to ARM machine code, and consequently, good discretion regarding certain choices regarding low-level implementation.
Ability to write inline ARM assembly when and if necessary
Knowledge of ARM systems' cache layout
Ability to estimate/forecast the power economy of code rather than its mere performance (as ARM processors are sometimes more concerned with that).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm new to computer graphics and game development, and wanted to know whats easier to learn - Directx 12 or Vulkan?
By easier I'm referring to function names, class names, naming conventions, how to setup/initiate a vulkan project vs directx 12 etc etc.
Neither is an appropriate API for a newbie. Both APIs expose the application programmer to the intimate details of the GPU, making you fully responsible for synchronization in a 'lock-free' style, memory management including all edge-cases such as low-resource scenarios, fully described state, etc. These APIs are intended for expert graphics programmers who essentially want to talk directly to the video driver with some level of vendor-neutral abstraction.
Graphics programming is already a challenging discipline particularly when it comes to debugging. You can mess up a single number in a thousand lines of code and end up with a blank screen and have to work out what went wrong. It's particularly challenging to debug in context with GPU shader programming once you move beyond trivial shaders. With Direct3D 12/Vulkan, you can multiply the challenges even further with driver crashes that stop your application, timing-based synchronization issues that change based on even tiny differences in variables, or worse it works perfectly fine unless you use a different screen resolution or completely fails on a different PC.
Direct3D 11 is a good API for learning graphics programming and game development on the Windows platform. Direct3D 9 is only applicable to legacy systems or emerging markets which tend to have very specific and idiosyncratic hardware requirements. All modern Windows platforms support Direct3D 11 including Universal Windows Platform (UWP); Windows Win32 desktop apps on Windows 7, 8.1, or 10; and Xbox One. If you are interested, I suggest taking a look at the DirectX Tool Kit for DirectX 11.
UPDATE DirectXTK is also a good place to start because once you have learned it on DirectX 11, you can transition over to the DirectX 12 version and have a leg-up on the basics.
You can certainly learn the basics of graphics programming and game development on other platforms, but I can't speak to the best options there. One thing I can suggest is that you decide if your passion is really game development or graphics programming. You may not know enough right now to really judge fully, but these are distinct paths in the industry. If you have a game vision you want to make, then look at something like Unity or Unreal Engine so you can focus on game development aspects. If you are more interested in graphics or game-related technology (audio and media, engines, simulations, real-time interactive behvaior, etc.) in general, then learning Direct3D 11 is as good a place to start as any.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
EDITED, see below
I need an library to display graphics of music notation on a music making software. It will be Sibelius-like: Basically the user creates the sheet music and the app sends midi output.
I'm not looking for an library to display music notation, as for various reasons i must implement it myself. Also, the library i'm looking for must be cross-platform (should run at least on Windows and Linux).
The graphics will be vector-based or drawn with functions like "line(point1, point2);"
(Before continuing let me state that i'm new to C++ and most of my experience is with interpreted languages - PureData and Processing, mostly)
Now to the question:
I've found Cinder. You think Cinder is sutiable for the task? If no, you might skip 2 and 3.
I don't have experience with OpenGL. I couldn't actually figure out if Cinder uses OpenGL exclusively or if it uses it only on demand. My doubt here is, when using OpenGL libraries my application will only be able to run on computers with dedicated graphics cards?
Cinder doesn't have the hability to create GUIs like Qt or GTK+. Is it possible to integrade Cinder in another window, created by Qt/GTK+/SDL/etc ? I want something like Sibelius, where you have normal GUI (buttons, menus, etc) integrated in the notation graphics window.
If Cinder is not a good option, what might you recommend for that specific application needs? OpenCV? SDL? SFML?
EDIT:
I see this was marked as off-topic. Sorry, i'm new here. I've seen some posts asking for this kind of recomendation so i thought it was okay. Well, i will try to be objective and straight-forward
Question:
I need to draw music notation graphics, but i don't want to deal with low-level stuff (like Cinder, SDL, SFML, Ati-Grain). So, what are the other technologies available? That is, what are the other options?
What you are describing is a LOT of work and something impossible for someone with limited programming experience such as yourself. C++ is neither an easy language nor a language that forgives.. it's not just about learning the syntax (as is the case with processing or similar languages with automatic garbage collection) - it's also about managing memory and other resources, invariants, etc - leaving aside the complexities of linkage, compilation, etc: in turn this prerequisites that you have a thorough understanding of how computers work at a lower level.
Anyway, I'll try to answer your questions:
You could do this with cinder - this would probably mean having to re-invent the wheel - but you can do. I wouldn't say, however, that cinder is really suitable for such a task. This is meant for accelerated 2D/3D computer graphics. What you want is some more generic GUI library (maybe QT?). Regarding midi-support, you'll probably have to rely on some other library for this anyway.
Most computers these days do support openGL. Again you don't really need openGL for what you want to do.
Yes you can do this in theory - but it won't be easy and it's not really necessary for what you want to do.
OpenCV definitely NOT. This is for image processing - i.e. raster graphics - you need vector graphics. Let aside that OpenCV's Highgui is really slow on certain things so you'd have to use some other library for rendering anyway. I have no experience with the other libraries. My suggestion would be to either use some interpreted language such as python, luaAV or maybe SuperCollider (which does have built-in midi support by the way) which is far easier than C++, or to search for some open-source music-notation alternative (if there any) -> you can always build something of your own upon an existent code-base - reinventing the wheel is not necessary...
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I know that you can program an OS by putting your code in the first 512 bytes of the RAM and things like that, but how do you program a GPU? Is it possible in standard C++?
I've heard of CUDA, but I would like to go by standards. Does Adobe Photoshop also use CUDA?
For all intents and purposes, there is no way to program a GPU without making use of some libraries, whether OpenCL, CUDA, or otherwise. While it is technically possible to drive the GPU directly (given that the GPU drivers are doing so!), documentation on how GPUs work is very difficult to come by, especially regarding advanced features such as those required for computation, and it's almost certainly not something you want to get involved with.
CUDA is a proprietary Nvidia language and software. It won't work on AMD graphics cards, or on recent Intel or AMD processors having an integrated GPU.
OpenCL is an industry standard, available on Nvidia and AMD graphics cards (and recent processors with integrated GPU).
However, pure standard C++ don't give you access to graphics cards or GPGPUs. You'll need an operating system and some libraries.
Notice that the small codes (called kernels) running on the GPU are not coded in fully standard C++, but in a small C-like dialect (also called OpenCL). There are some limitations (no recursive function, no function pointers, etc...) because of the weird nature of GPGPUs. The programming model is not as general as in C++.
There is also OpenACC, a set of pragmas for C++ compilers.
CUDA is the standard for NVidia cards. Alternatively OpenCL is also an option for a bit more cross platform.
http://en.wikipedia.org/wiki/OpenCL
Coding a GPU is fundamentally different to coding a CPU in that you have hundreds to well in the thousands of concurrent threads hence the different way of calling functions/kernels on the GPU.
NOTE: There is no way you can run your own code on the GPU without compiling it for the GPU therefore a standard C++ compiler will only be able to call functions in libraries.
It is surely possible up do everything in C++, but you will need to use some external libraries.
You might want to consider OpenCL instead of CUDA.
CUDA is a proprietary NVidia technology, while OpenCL works on more hardware and platforms.
This question already has answers here:
How does OpenGL work at the lowest level? [closed]
(4 answers)
Closed 9 years ago.
I was wondering about OpenGL's main interface. Simply, how does the OpenGL DLL call graphics functions? Is there some secret hidden rendering code in C++? If it can call the GPU from a DLL, it should be possible in any C++ program. If so, could I make some API of my own for my programs? Or what? I'm hoping someone here knows. Can someone shed some light on this subject? Thanks in advance!
First and foremost: Modern OpenGL is not a library and on Windows the DLL doesn't contain a OpenGL implementation that talks to the hardware. The opengl32.dll merely acts as a placeholder, into which the drivers hook their low level functions (called ICD).
I answered it in detail here: https://stackoverflow.com/a/6401607/524368
The OpenGL DLL's communicate with Ring 0 like any other application module does, with calls like DeviceIoControl. The exact details of the data passed to those calls is not publicly documented and that's not likely to change. The GPU manufacturers just aren't willing to part with that information all willy nilly like. While it's possible you could create your own API, the details to talk to the driver are not going to be readily available.
In general sense the answer is "yes", but to make it viable, it must necessary be somewhat "Hardware dependent"
What you call "Graphics functions" (something you suppose OGL is based on) at the very bottom level depends on the way the hardware structures the image frames into itself an communicate with the processor.
There are hardware that are just a plane frame buffer and hardware that are capable to manage themselves the rasterization process of a vectorial scene.
There are operating system API that are plane 2d vector and imaging support (like GDI) or even three-dimensional modeling system (like direc3d).
OGL is just an API: it define a consistent set of function prototypes to accomplish a task (describe a 3D scene). The renderimg process is implemented into DLLS that differ depending on the nature of the system they have to work with.
Some of them just operate on their own buffers that treat as raw data for bitmaps to be Blit-ted on the screen via OS native api (see BitBlit), some other translate the OGL calls into calls to specific op-code to specific io-ports of hardware device.
Due to the popularity of OGL, there are also manufacturers that are standardizing the "language" between the library and the devices. So things are not so "linear" as they can seem...
Writing directly to hardware registers is how graphics programming was done before OpenGL and other standardised graphics APIs were introduced.
Generally speaking, it was a nightmare to write for, and almost impossible to debug. Higher level APIs were invented for a reason.
The closest you can get to hardware these days is on the consoles, where you still have much lower level access than on the PC, but even that access is abstracted away more then it was in the past.
If you really want to do it, you can, but you'll basically be writing your own driver if you're not writing your own OS as well, and you wont find much publicly available documentation on modern GPUs.