How does OpenGL work, internally?
We will use OpenGL for our 2D game project, and think that it is important for us to first find out more about how OpenGL actually works before diving right into it.
What we need isn't some getting-started tutorial, rather basic information on how OpenGL internally handles textures, draws, interacts with the graphics card, and so on.
We have already searched for a while yet couldn't find anything suitable.
OpenGL is just an interface. How it works depends on the implementation, that is drivers and hardware. For example: if the hardware doesn't support some feature then the implementation is free to implement it on the client side (CPU) rather than on the GPU. Moreover there is software only implementation.
In general you can think of it as you sending commands to the graphics card that are buffered somewhere and executed with some ordering constraints on the graphics card.
Note: your question is too general.
You might be interested in mesa. It is an open source Opengl implementation. Most implementations are trade secret so you will never know how ATI\Nvidia implemented anything except what you can infer by the results produced by interacting with their implementations. You might find Intel's drivers informative as they are open source as well.
If by internally, you mean what is the works that opengl does with what you draw, you would be interested in pipeline.
Related
I have been wanting to make a game in OpenGL, c++ for a while now and i would love some explanation on how exactly it works and what it is.
Can computer graphics be made without OpenGL ? most of the tutorials i have seen online show how to use OpenGL for the most basic graphics drawing, it is possible to directly interface with your GPU ?
How does OpenGL work on different CPU's and Operating systems ? As far as i know languages like c++ must be recompiled if they want to be used on an ARM processor and the such, is this not the case for GPU's in general ?
If you can indeed make graphics without OpenGL, does anybody still do this ? how much work and effort does OpenGL save in general and how complex are the systems that OpenGL facilitates for us?
Are there other libraries like OpenGL that are commonly used ? if not, will new libraries eventually come and take it's place or is it perfect for the job and not going anywhere ?
How exactly it works and what it is?
OpenGL defines an interface that you as a programmer can use to develop graphics programs (API). The interface is provided to you in form of header files that you include to your project. It is meant to be multiplatform, so that you can compile your code that uses OpenGL on different operating systems. People that manage the OpenGL specification do not provide the implementation of specified functionality. That is done by the OS and hardware vendors.
Can computer graphics be made without OpenGL?
Yeah, sure. You can e.g. calculate the whole image manually in your program and then call some OS-specific function to put that image on the screen (like BitBlt in Windows).
How does OpenGL work on different CPU's and Operating systems?
Each OS will have its own implementation of OpenGL specification that will usually call the hardware drivers. So let's say you have machine with Windows OS and Nvidia graphics card. If you run some program that calls glDrawElements it will look like this:
your_program calls glDrawElements
which calls glDrawElements implementation written by people from Microsoft
which calls Nvidia drivers written by people from Nvidia
which operates the HW
If you can indeed make graphics without OpenGL, does anybody still do this?
Yeah sure. Some people might want to implement their own rendering engine from ground up (although that is really hardcore thing to do).
Are there other libraries like OpenGL that are commonly used ? if not, will new libraries eventually come and take it's place or is it perfect for the job and not going anywhere ?
Sure. There is DirectX that is maintained by Microsoft and targets only Windows platforms and the Vulkan that can be seen as successor to OpenGL.
I am relatively new to graphic programming so I wanted to start from the very basic. I see there is library like PyOpenGl which provides binding to the opengl api itself. Now, I really want to create things like PyOpenGl on my own so I can understand how everything work in the process.
Is it possible for me to creates library like PyOpenGl or GLFW? If so please give me some general tips of what should I do.
If not please explain to me why I can't create my own binding and I do apologize if my question above sounds absurd.
PyOpenGL is a fairly thin wrapper that, for the most part, simply turns Python function calls into calls of native machine code functions of the same name. There are a few little details like calling conventions in the mix, but these are actually boring stuff. The fact is that (as far as OpenGL is concerned) the source code you write in Python with PyOpenGL looks almost identical to the source code you'd write in C. There are a few "smart" things PyOpenGL does, like providing means to interface NumPy arrays to OpenGL calls that take a data pointer parameter, but that's just house keeping.
And when you do OpenGL calls in C or – even more extreme – assembly language (perfectly possible) that's the lowest level you can go (with OpenGL), short of writing your own GPU device driver. And writing a GPU device driver is super hard work; it takes literally millions of lines of C code (NVidia's OpenGL implementation is said to consist of about ~40M LoC, there are open source drivers for AMD and Intel GPUs, and each of them have MLoC, too).
If you're interested in some middle ground, have a look at the Vulkan API. If writing higher level wrappers for graphics is your thing I'd suggest you implement some higher level API / renderer for Vulkan and interface it to Python. This is likely to be much more rewarding, as a learning experience (IMHO).
The OpenGL API lives in the driver for the graphics card. All OpenGL functions are there. You only need to know how to get them. As Spektre said, the proccess is:
Create an OpenGL context. This is a job for the OS. Each OS has its
way and its issues. Read https://www.khronos.org/opengl/wiki/Load_OpenGL_Functions
Define function pointers as glext.h does and then extract them from
the driver. Apart from standard OpenGL funcs, vendors add their own
ones, called "extensions". You can see how GLEW does this job. If you want to set all functions and extensions then make a script that uses glext.h because there are about one thousand of them.
You can download glext.h from https://www.opengl.org/registry/
Doing something like GLFW requires, added to the previous two points, knowing how to create a window and handle its messages for keyboard and mouse. Again this is OS dependant. On Windows there is a way. On Linux it depends on the window manager used, GTK+ for example. Or X11 directly. Or...
Anyhow my best advise is that you can read how GLEW and GLFW did, looking into their code. BUT don't lose much time on it. Prefer getting experience on OpenGL and let those "diggins" for later time.
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.
How do I find out, if a specific OpenGL feature is supported by hardware or not?
In my case I want to know, if two-sided lighting is available in hardware.
An approach using OpenInventor would be just as well.
In general, you don't.
If something is part of core OpenGL, then it should be implemented by the OpenGL implementation. Whether this happens "in hardware" or not is not something that you can detect.
For extension based features, you can obviously check for the presence of the extension. But otherwise, there's nothing you can do except better know the hardware your code is running on.
If i understand correcty, the graphics card are programmed to display 2D&3D graphics and these cards have native functions, but because these functions are obsolete and hard to use, we nou use drivers, that makes the programmers life easier.
Now, my question is that if there are some native graphics card function tutorials and if these are universal, that works on every graphics card or differ from one to another like ASM language does. And if there exists tutorials, can i use C language or C++ or i need to have asm knowledge ?
The way GPUs are programmed (at least the advanced functions) is typically through either MMIO (as in, an address in virtual memory corresponds to a register in the GPU instead of actual DRAM), or more often, through command buffers (as in, a chunk of memory is used to store commands for the GPU, that the GPU reads sequentially.
Now, those commands and registers are very hardware dependent (even within a single hardware vendor): see for example ATI R600 registers. They are not "universal" at all.
Those types of interfaces are what driver developers use to implement the DirectX and OpenGL APIs that typical programs use.
Probably the best source of "tutorial" for that level of programming are the open source drivers in linux.
There's a good reason there are now more standardised ways of talking to the graphics subsystems in computers. Unless you have a specific platform in mind I'd suggest you stick to using the standard API's I.e. go through OpenGL or DirectX.
If i understand correcty, the graphics card are programmed to display
2D&3D graphics and these cards have native functions, but because
these functions are obsolete and hard to use, we nou use drivers, that
makes the programmers life easier.
in a sense yes, although not obsolete, it is all about abstraction.
there are several tutorials on the web, for instance for OpenGL there
is nehe.gamedev.net DirectX has also a number of tutorials, just
use your favorite search engine although OpenGL has the big advantage
of being portable.
Generally you can use either C or C++ and do not need to know any ASM if you
do not have some extreme requirement.