But it was probably a lot easier for him to figure out where and how to implement his feature. I agree that lack of time and motivation is most of it. A lack of time is certainly the main thing holding me back, but if I had an idea of how all the different parts of the graphical stack fit together, then perhaps I could make some small contributions here and there.
Originally Posted by marek
It all depends on what you know. If you know HTML, it's fairly easy to contribute to KHTML, if you know OpenGL or DX, it's fairly easy to contribute to X/mesa.
Originally Posted by hiryu
Alright, so it sounds like Mesa is where I'd want to start looking. The Mesa git repository currently has 137 branches. If I was interested in looking at the work being done on say r600c and/or r600g, which branch would I want to look at? Would it be master?
Originally Posted by agd5f
I think it's all in master. The 600c driver can be found in src/mesa/drivers/dri/r600 and the 600g driver can be found in src/gallium/drivers/r600.
yes, master. You pretty much always want master unless there is some special topic branch you are interested in.
Sure they do. Just not a lot that's released. OpenGL 3 is pretty young. Keep in mind that your average successful commercial game goes through 2-4 years of development, if not a few more.
Originally Posted by Nille
There's also a problem of support. If you actually want to use OpenGL 3/4, the best place to do it is on Windows. Sure, the proprietary Linux drivers support them as well, but Linux is the bottom-rung platform for games, coming in after the game consoles (which either use DirectX or platform-proprietary graphics APIs), OS X (which is also still stuck at 2.1 for now), and mobile phones (all OpenGL ES). And if you're going to be writing apps that only work on Windows, most people are going to prefer DirectX which at least classically has had more stable drivers for most hardware (due likely to being more widely used and hence more widely tested).
To be honest, as a game developer, I don't really care about Linux supporting OpenGL 4 so much as I just care about having Linux support modern graphics hardware features. If somebody wrote a quality DirectX 11 API library for Linux, I'd be just as happy to start using that. Hell, it'd probably be even more popular as a gaming platform than if it just supported OpenGL 4, due making it at least a little easier to port existing DirectX titles (granted, still be a shitload of other things to rewrite).
Although, in that line of thinking, the differing APIs are far less of an annoyance than the differing shading languages. That's what makes toolkits like Cg so attractive, but far more games just use straight HLSL (combined with a custom effects layer for composing the HLSL scripts) than use Cg. Giving Mesa an extension to parse both binary and source HLSL scripts might just be more useful than adding in OpenGL 4 support, now that I think about it. Porting the code from D3D to OGL is really quite trivial in any competently written game engine (not even lazy graphics programmers expose much D3D internals to the rest of the engine, as there's not actually anything useful from those low-level API calls that the higher-level rendering portions of the engine remotely have need for); it's the many thousands of lines of HLSL code stored mostly in the data files that can become the real bitch when doing a port. The engine may also have some HLSL-specific code for effect composition.
Why everyone crys that Mesa isn't fast enough in adapting new OpenGL Standards? Every card which supports these new Features and also has the power to use them, comes also with proprietary drivers. Ok, BSD and Solaris users aren't able to use them and some people dislike proprietary modules but for most users there is a way to use these features.
And you should also know that the difference between 3.0 and 4.0 isn't that great. H/W tesselation is the only big extra of 4.0, so if Mesa becomes OpenGL 3.0 compliant then the step to 4.0 is not soo big as the one from 2.x to 3.0.
The wonderful new features of the new versions aren't that great because OpenGL-API still lacks of useable and OpenGL 3.0 compatible debugging tools (esp. for shader-development). There is also not a reference implementation to check if your code is correct and only the graphics driver does something strange. Without that you have to develop your code for all available GPUs and under linux also for all kinds of graphics drivers as the open-source driver might implement things differently as the proprietary one does.
This is the real pain of everyday graphics development.
OpenGL 4.1 support on NVIDIA
NVIDIA already has OpenGL 4.1 support for Linux through drivers version 256.38.02: http://developer.nvidia.com/object/opengl_driver.html -- A Fermi card is required.
Tags for this Thread