Page 4 of 4 FirstFirst ... 234
Results 31 to 38 of 38

Thread: We're Now Up To OpenGL 4.1; Brings New Features

  1. #31
    Join Date
    Nov 2009
    Posts
    106

    Default

    Quote Originally Posted by marek View Post
    Did you have to know whole KDE before contributing to KHTML? No you didn't. You don't need to know kernel DRM to be able to contribute to a driver (you don't even need to know whole Mesa, not even a fifth). Sometimes you just know the few source files you work with, ignoring everything else. Code reviews ensure that you commit good stuff, especially when touching someone else's code. Complexity is not an excuse, lack of time or motivation is.
    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.

  2. #32
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    Quote Originally Posted by hiryu View Post
    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.
    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.

  3. #33
    Join Date
    Nov 2009
    Posts
    106

    Default

    Quote Originally Posted by agd5f View Post
    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.
    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?

  4. #34
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,514

    Default

    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.

  5. #35
    Join Date
    Dec 2007
    Posts
    2,395

    Default

    yes, master. You pretty much always want master unless there is some special topic branch you are interested in.

  6. #36
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    Quote Originally Posted by Nille View Post
    Jay the next OGL Version but no1 use OGL3 or OGL4 (except an benchmark *yell* ) ...
    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.

    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.

  7. #37
    Join Date
    Nov 2009
    Posts
    19

    Default

    1.
    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.

    2.
    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.

  8. #38
    Join Date
    Jun 2009
    Location
    Paris
    Posts
    432

    Default 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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •