Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 38

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

  1. #21
    Join Date
    Jan 2009
    Posts
    624

    Default

    Another great OpenGL release, but ... who will implement that?

  2. #22
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,628

    Default

    Actually the biggest responsibility here is on the game and application developers. If they decide that the applications don't run without each and every one of the new extensions, then people do have to buy new hardware to run it. If they design the games to be scalable and to work without the new and fancy stuff, no problem for the people who want to upgrade systems slower either. Then again, this implies more work for application developers.
    But I wouldn't really blame standardization bodies for making new hardware necessary. If it wasn't for them, application developers would just use vendor-specific extensions always and you'd have to have a graphics accelerator chip from a specific vendor in your computer for things to run.

  3. #23
    Join Date
    Jun 2006
    Posts
    94

    Lightbulb Tutorials for new driver hackers

    Quote Originally Posted by agd5f View Post
    Also, keep in mind that mesa and the open source drivers are open source so anyone that's interested in adding support for newer functionality is free to contribute. The the hardware and software specs are available, the only thing missing is more manpower.
    I agree with this very much. but I also see a problem that is probably a reason why there is lack of manpower. There is no good documentation for those who would like to start hacking on drivers. Some kind of a tutorial to orient newcomers so open source driver developer which would help them orient. Like how the card works, where does one start if she wants to add support for one openGL extension. i have this feeling that the whole graphics stack in Linux is very complex and confusing and there is nothing to gently introduce a new contributor to all this.

  4. #24
    Join Date
    Feb 2009
    Location
    Poland
    Posts
    72

    Default

    Well... Modern systems and stacks just *are* complex, and it's impossible to overcome this. But I agree with you in terms of documentation. There are some bits of it here and there, but some of them is outdated, etc.

    I have one month of holiday left, and I wanted to contribute a FOSS project during this time. But I don't know how to start... It was simple to add one feature to KHTML, but that whole stack (linux kernel + drm + libdrm + ddx + mesa, including g3d, drivers, state trackers...) is a bit complicated, and doing anything *major* in terms of OpenGL 3.x support (like UBO/TBO) will require contributions to almost whole stack (that is my assumption).

    Maybe I should spend a day or two (or ten) reading source

  5. #25
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    I just skipped this entire thread (mostly) and like to say:
    1. Awesome. Let OpenGL slaughter DirectX because it was about to die and I am not kidding.
    2. Don't hate on OpenGL simply because Mesa is heavily understaffed. Don't hate Mesa either for trying to keep up, no matter what.
    3. Gallium, in a working state, can handle everything. The 90's called and took fixed function cards away already.
    4. Almost no-one implemented Direct3D 10 and 11, let alone without d3d 9 fallback anyway, so OpenGL won't either. Plenty of time to catch up.
    5. The OpenGL revision train won't be running at full speed for long anymore.

    Now grab a beer/smoke/icecream and chill a little.

  6. #26
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,628

    Default

    Quote Originally Posted by Wielkie G View Post
    (linux kernel + drm + libdrm + ddx + mesa, including g3d, drivers, state trackers...) is a bit complicated, and doing anything *major* in terms of OpenGL 3.x support (like UBO/TBO) will require contributions to almost whole stack (that is my assumption)
    I suspect just focusing on the userspace implementation inside Gallium3D would already go a long way.

  7. #27
    Join Date
    Aug 2007
    Location
    Europe
    Posts
    401

    Default

    Quote Originally Posted by jrch2k8 View Post
    i agree that apps have to keep a moderated adoption rate at least until mesa do some catch up but khronos cant just slow down cuz that will efectively kill OpenGL.
    Yes. That is very true.

    It is also called the "Red Queen Hypothesis" - you must run in order to stand still.

    With DX10 and DX11 here since long, the programs (games etc) which have been in development for three or four years are finally coming out in force.

    So, for OpenGL to be relevant, they must keep the pace of MS, at least. "Unfortunately", as the gaming industry has grown to be gigantic, it really does matter. All graphic cards are designed together with MS (quite possibly with Xbox in mind 1st), which has given MS a head start for a decade or so.

    Sad but true.

  8. #28
    Join Date
    Jul 2009
    Location
    Torrington, Ct. USA
    Posts
    168

    Default

    I'm happy to see OpenGL moving along at a brisk pace. It sucks to see the open source stack fall further and further behind but Khronos can't sit on their hands and wait for the open source stack to catch up to the standard. Microsoft ain't going to stop and wait so Open GL needs to keep up with feature parity (in a perfect world maybe even come out with features first like it was years ago), otherwise OpenGL will fall further and further behind and even developers super friendly to OpenGL like id may have to turn to DX exclusively and shun OpenGL.

  9. #29
    Join Date
    Oct 2007
    Location
    Toronto-ish
    Posts
    7,463

    Default

    For the record, I don't think the open source stack is falling further and further behind unless you interpret the OpenGL version numbers as being directly proportional to the complexity of the implementation. GL 4.0 is not twice as hard as GL 2.0. As others have said, the jump from GL 4.0 to GL 4.1 is a tweak, not a wrenching change.

    The entire graphics stack had to be revamped in order to get to GL 2.0 (rebuilding around a kernel memory manager, along with the associated KMS work, and making Gallium3D production-ready) but AFAIK that effort ("two years gone from everyone's life" ) should not have to be done again in the next few years.

  10. #30
    Join Date
    Jan 2009
    Posts
    624

    Default

    Quote Originally Posted by Tsiolkovsky View Post
    I agree with this very much. but I also see a problem that is probably a reason why there is lack of manpower. There is no good documentation for those who would like to start hacking on drivers. Some kind of a tutorial to orient newcomers so open source driver developer which would help them orient. Like how the card works, where does one start if she wants to add support for one openGL extension. i have this feeling that the whole graphics stack in Linux is very complex and confusing and there is nothing to gently introduce a new contributor to all this.
    Programming a GPU is no different from programming in OpenGL. Instead of calling e.g. glBlendFunc, you set the corresponding register (such a register usually contains the blend enable bit, the blend func, and the blend equation). Shaders are not a big deal either, you just use something like ARB_fragment_program in a binary representation. Of course, before joining any project, you need to know something about its code, so just read the code you are interested in, and ask questions. That's all.

    I do not think the Linux graphics stack is complex, it is just another project a skilled programmer may come across and jump in (or not...).

    Quote Originally Posted by Wielkie G View Post
    I have one month of holiday left, and I wanted to contribute a FOSS project during this time. But I don't know how to start... It was simple to add one feature to KHTML, but that whole stack (linux kernel + drm + libdrm + ddx + mesa, including g3d, drivers, state trackers...) is a bit complicated, and doing anything *major* in terms of OpenGL 3.x support (like UBO/TBO) will require contributions to almost whole stack (that is my assumption).
    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.

    BTW Mesa supports a lot of GL 3.x extensions including geometry shaders, just not all of them to be able to bump the GL version.

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
  •