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.
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 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 5 years ago.
Improve this question
I want to do 1024*768 programming in Turbo C++
I am using Turbo C 3.0 where i am using the old VGA method to invoke graphics
initgraph( &GraphDriver, &GraphMode, "..\\bgi" );
I want a library which can easily handle the SVGA mode and true colors.
There are several chip manufacturers for SVGA cards, and programming them may require specific code for each of them (unless your graphic board supports VESA, see below). I did that ages ago (in the 90s'), and I used the sources of POVRAY (a raytracer) as a reference.
Fortunately, POVRAY still exists today: http://www.povray.org/
You need to grab here http://www.povray.org/ftp/pub/povray/Old-Versions/ the sources of an old 1990's version that still has the routines for SVGA (the authors probably removed them in the recent versions !). You will find in the sources a bunch of inline assembly functions to initialize graphic mode and set a pixel for various graphic boards/manufacturers (S3, ET4000, ...). First unzip POVSRC.ZIP, then MACHINE.ZIP, then IBMPC.ZIP (and it is in IBM.C).
The code is a bit esoteric: this is because initially the IBM PC was meant to have no more than 64Kb of video ram (at segment A000:0000). To allow having higher resolution, there is a technique that is called "bank switching", that allows changing a "window" in video RAM that is mapped to A000:0000.
If your SVGA board supports the VESA standard (which is the case for most of them), then things might be easier, there is a standard interrupt for changing the graphic mode and for doing the bank switching (so you probably just need to find in POVRAY the VESA implementation of "set graphic mode" and "set pixel").
Finally, I mention djgpp (g++ port to MSDOS) that has both a 32 bit DOS extender and a graphic library (grx) that uses the virtual memory in a nifty way to simulate a contiguous graphic memory (it creates virtual addresses for the video RAM and uses page faults interrupts to trigger bank switching automatically). I used it to do 3D graphic programming on a 33Mhz 486.
Edit:
After digging a bit, I found that the latest version that has the routines is the one here:
http://www.povray.org/ftp/pub/povray/Old-Versions/Official-3.1g/MS-Dos/
unzip povmsd_s.zip
The routines are in SOURCE/MSDOS/VESAVBE.{H,C} (usable if your cards supports the VESA norm). Other cards have their routines in SOURCE/MSDOS/MSDOSVID.C
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.
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 7 years ago.
Improve this question
I am trying to write a program which I want to run just before booting up the system like the Setup program of Windows XP. The problem is that I cannot figure out which version of C/C++ programming language should be use. Because as far as I know about the many versions of C language they only works in DOS, Windows and Linux. Or is there any way to write the program in the Visual C++ or Turbo C that can run without any OS.
My next question is that which Graphics library can be use in that C language to create and display Images and Shapes on screen, Setting Background color etc.
I read an article on Windows in Wikipedia and I found that it is written on C++. So I thought that I can also write similar type of program in C++ without switching to Assembly language.
You want to write a program that runs directly off boot, with no OS loaded? Sorry, but if you need to ask which language to use, you have a learning curve ahead of you that's so steep that you ought to consider lowering your ambitions considerably for a first effort.
In the bad old days when space was at a premium, bootloaders were written in raw assembler. Today most of the functionality is written in C (or perhaps C++), but one still needs to go to assembler for the very earliest stages that take over from the BIOS, loads more code from disk than the single sector BIOS gives you, and puts the processor into protected mode so it can access more than 1 MB of RAM.
The choice between C and C++ is mostly up to preferences. C++ tends to require a somewhat more complex assembly intro in order to set up its run-time environment as the compiled code expects to find it. In either case, you won't have much in the way of standard libraries available. No malloc/free/new/delete unless you implement them yourself, for example.
No matter what the language, you will need to customize the linking phase much beyond what an off-the-shelf compiler toolchain will do for you with a simple command.
If you're using an x86 machine, you are going to have to learn how to work with either the default VGA buffer, or possibly VBE mode buffer if you want higher-resolution graphics. Most of this will have to be setup through calling BIOS interrupts or using MMIO ports dedicated to controlling the VGA buffer. In either case, this is going to have to be a mixture of assembly and C ... you can't really take advantage of C++ in this instance, since you will not have the use of a OS runtime that typically provides support for many C++-specific language features like exceptions, etc. If you want those types of features, you're going to have to setup the runtime yourself.
Here is a great site for information on the VGA registers that can be accessed through x86 MMIO: http://www.osdever.net/FreeVGA/home.htm
C/C++ does not matter as each system will compile it into the correct machine code for that machine. I can't remember the exact steps, but you're definitely going to have to mess around with copying your code into boot sector, etc.
You will inevitably have to write a little assembly language to be able to write something which boots before the OS. You'll have to write a boot-loader for one thing.
As to a graphics library, you will pretty much have to roll your own if you want graphics, because most libraries use at least some capabilities of an underlying operating system, no mater how cross-platform they are. You'll notice, for example, that the Windows setup program is all text until it boots into the Windows that's being set up for the first time.
As you mentioned yourself, you need to write a boot loader and that is, after compiling your boot loader you have to install it somehow (I'm not so sure about this part), but that usually involves copying it to a certain location of your hard disk, referenced by the master boot record.
As for graphics (or better say graphics card), as well as any other device that you want to interact with at boot time, you simply need to load their driver. So, in principle, your boot loader starts running, loads a bigger portion of itself into memory and once that is done, it start loading the drivers and starts working (similar to how an operation system boots, but much much simpler). The drivers are usually very limited but very generic drivers that you either have to write yourself or find on the internet.
I'm investigating ways of using GPU in order to process streaming data. I had two choices but couldn't decide which way to go?
My criterias are as follows:
Ease of use (good API)
Community and Documentation
Performance
Future
I'll code in C and C++ under linux.
OpenCL
interfaced from your production code
portable between different graphics hardware
limited operations but preprepared shortcuts
CUDA
separate language (CUDA C)
nVidia hardware only
almost full control over the code (coding in a C-like language)
lot of profiling and debugging tools
Bottom line -- OpenCL is portable, CUDA is nVidia only. However, being an independent language, CUDA is much more powerful and has a bunch of really good tools.
Ease of use -- OpenCL is easier to use out of the box, but once you setup the CUDA coding environment it's almost like coding in C.
Community and Documentation -- both have extensive documentation and examples, however I think CUDA has better.
Performance -- CUDA allows for greater control, hence can be better fine-tuned for higher performance.
Future -- hard to say really.
My personal experiences were:
API: OpenCL has slightly more complex api. However most time you will spent with writing kernel code, and here both are almost identical.
Community: CUDA has a much bigger community then OpenCL up til now, but this will probably about to even out.
Documentation: Both are very well documented.
Performance: We made the experience, that OpenCL drivers are not yet fully optimized.
Future: The future lies with OpenCL as it is an open standard, not restricted to a vendor or specific hardware!
This assessment is from 2010, so probably out-dated.
OpenCL all the way unless you have a specific reason to use CUDA. OpenCL runs well on multicores like Intel i7 in addition to running on GPUs. By using OpenCL you can run it on a much wider range of hardware from Droid cell phones to the IBM Power7 compute nodes of the world's largest supercomputer, Blue Waters, which is supposed to come online next year.