Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 27

Thread: OpenGL 4.2 Specification Published With GLSL 4.20

  1. #11
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    Quote Originally Posted by efikkan View Post
    It still lacks one feature I need though, an effective way to upload data and preferly geometry without traditional GL-calls. I would love if I could just exchange some of the vertex data and just use one glDraw-call to render it all, and program the pipeline fetch data itself and choose which fragments to process. It's rumored that Kepler will feature the ability to access system memory directly from the GPU, and this might be used to achieve what I want.
    not only nvidias Kepler

    also the r900/hd8000 will bring the same ram access system as the cpu.

    i think this will be a DX12/openGL5 feature.

    means all next gen GPUs will have this feature.

  2. #12
    Join Date
    Oct 2007
    Posts
    912

    Default

    Quote Originally Posted by efikkan View Post
    Again, nVidia provides drivers at launch and also adds the features which are possible for older hardware, such as ARB_conservative_depth which would allow more performance optimization.

    I haven't reviewed the new specification yet. But several of the new features would allow more tweaking and performance, and compression in memory which is a limitation for graphics cards.

    It still lacks one feature I need though, an effective way to upload data and preferly geometry without traditional GL-calls. I would love if I could just exchange some of the vertex data and just use one glDraw-call to render it all, and program the pipeline fetch data itself and choose which fragments to process. It's rumored that Kepler will feature the ability to access system memory directly from the GPU, and this might be used to achieve what I want.

    And of course the open source drivers are still lagging behind, and does not yet offer support for modern OpenGL specifications. Some argue that many of the components of OpenGL 3.0 is there, but the most important one, shading, is still not complete.


    What kind of multithreading do you want?
    OpenGL supports multiple rendering contexts and shared contexts, handling is up to the driver and window system. But still, as far as I can see, no one of the popular toolkits supports this, such as GLUT, SDL, glfw etc.

    But you'll have to remember that the driver will still just do one task at a time, you you'll only achieve a queue of tasks.

    Documentation is not a large issue. Samples could be much better however, almost all samples are outdated and irrelevant today. Khronos should provide samples exposing all features. I hope nVidia's new SDK will be ready soon. But still, I think the lack of a decent official OpenGL library/toolkit is a larger problem. I've had to make my own to satisfy my own needs.

    OpenGL actually has support for debugging messages.
    Not entirely sure if it's what you mean, but if you want a gui toolkit with multiple and shared rendering contexts, look up fox. Takes a little tweaking (for now - and it's really not difficult to do) for opengl3 contexts, but it works.
    Interesting thing about the multithreading with directx - it's not hardware supported at all. So people can make something similar for OpenGL, they just have to roll it for themselves. I'm in two minds about that - on the one hand, sure, it might be nice. On the other, OpenGL has always been closer to the hardware than directx, so I'm thinking that it belongs in the domain of roll it for yourself. Most games do this implicitly anyway - threading to build a list of what to draw, then process and render the list.
    If you want samples (yeah, Khronos really should be doing that), I heartily recommend www.g-truc.net - the guy there provides quite an extensive set that's well worth checking out.

  3. #13
    Join Date
    Jun 2010
    Posts
    145

    Default

    Quote Originally Posted by Qaridarium View Post
    not only nvidias Kepler
    also the r900/hd8000 will bring the same ram access system as the cpu.
    i think this will be a DX12/openGL5 feature.
    means all next gen GPUs will have this feature.
    Yes, of course AMD will provide similar features in their next generation.

    But I'm not aware of any other major new features, and I've seen a roadmap displaying "DirectX 11.1" along with Windows 8, so I guess this might end up as DirectX 11.1 and OpenGL 4.3, but I'm not sure. DirectX 12/ OpenGL 5 would make some sense, and people would love it for marketing.


    Quote Originally Posted by mirv View Post
    Not entirely sure if it's what you mean, but if you want a gui toolkit with multiple and shared rendering contexts, <cut>
    Thanks, but I don't need a GUI toolkit for that. My own library/loader currently supports separating OpenGL calls in one separate thread, so the I/O and window system does not affect the performance.

    Quote Originally Posted by mirv View Post
    Interesting thing about the multithreading with directx - it's not hardware supported at all. So people can make something similar for OpenGL, they just have to roll it for themselves.
    My point exactly.

    Quote Originally Posted by mirv View Post
    I'm in two minds about that - on the one hand, sure, it might be nice. On the other, OpenGL has always been closer to the hardware than directx, so I'm thinking that it belongs in the domain of roll it for yourself. Most games do this implicitly anyway - threading to build a list of what to draw, then process and render the list.
    If you want samples (yeah, Khronos really should be doing that)
    Agree. Perhaps one day when the hardware has changed.

    Quote Originally Posted by mirv View Post
    I heartily recommend www.g-truc.net - the guy there provides quite an extensive set that's well worth checking out.
    Yes, I'm aware of that website, and it's very good.

  4. #14
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by elanthis View Post
    I have to agree. While it sucks that we still don't have OpenGL 3.2 support on the FOSS drivers, we're a heck of a lot closer to that now than we were. I don't imagine that it'll be too terribly much longer before the FOSS drivers catch up (save for the patent problems, of course), and once that happens it should be relatively easy to stay caught up.
    Who cares about U.S. patent B.S., it needs to be ignored/skirted, just give users easy access to install it after distro installation in case they do live in a stupid country like the U.S..

  5. #15
    Join Date
    Sep 2010
    Posts
    445

    Default

    The problem is that being sued is kinda hard to ignore.

    If you have a solution for that, it would really help if you would tell everyone your solution.

    Most patents aren't confined to the U.S.
    Many countries in Asia and Europe recognize U.S. patents.

  6. #16
    Join Date
    Mar 2009
    Posts
    92

    Default

    I hear a lot of moaning and whining about open source opengl support from non developers. But has anyone considered this: The open source drivers have a single standardised codebase. Once they are finished, OpenGL will work on every single alternative OS platform out there. Linux, AROS, FreeBSD, NetBSD, OpenBSD, even the HURD. All the platforms that are currently obscure/crap to do 3D on will have ATi/NVIDIA/Intel 3d graphics support. The Open Source drivers are moving in the right direction, and have the correct architecture under way. Criticism at this point is stupid and useless. It's like criticising someone for being unemployed when they have already filled out job applications and have done everything they can to get work. It's not like they can make a company get back to them sooner or hire them any quicker. By the same token it's not like Nouveau or the open Radeon projects can make their drivers fall out of the sky magically faster. The criticisms are silly. You want to complain about something? complain about desktop coherency, about the gnome3/unity debacle. Or about Linux not using cocoa like Apple does. Complaining about a real project with real developers busting their asses off to get the results people need is a silly pointless exercise.

  7. #17
    Join Date
    Dec 2007
    Location
    Edinburgh, Scotland
    Posts
    574

    Default

    If you look at GL3.txt then you'll see most of 3.x has been completed, even some of 4.x has been started

  8. #18
    Join Date
    Jul 2008
    Posts
    565

    Default

    Quote Originally Posted by plonoma View Post
    The problem is that being sued is kinda hard to ignore.

    If you have a solution for that, it would really help if you would tell everyone your solution.

    Most patents aren't confined to the U.S.
    Many countries in Asia and Europe recognize U.S. patents.
    It's called hosting the information in a country that isn't retarded.

  9. #19
    Join Date
    Jun 2009
    Posts
    2,925

    Default

    Quote Originally Posted by DMJC View Post
    I hear a lot of moaning and whining about open source opengl support from non developers. But has anyone considered this: The open source drivers have a single standardised codebase. Once they are finished, OpenGL will work on every single alternative OS platform out there. Linux, AROS, FreeBSD, NetBSD, OpenBSD, even the HURD.
    Not really.

    First the DRM/KMS/GEM/TTM bits of the Linux kernel need to be ported over to each one of those kernels. That provides the functionality that Gallium3d (and every classic Mesa driver which can do OpenGL > 1.5) needs to function.

    The OpenGL implementation itself (Mesa) is shared, however.

    And that's quite a bit of work.

  10. #20
    Join Date
    Feb 2011
    Posts
    55

    Default

    Quote Originally Posted by smitty3268 View Post
    Where we might have better luck is with OpenGL ES. People actually care about that API and are using it heavily on the new "hot" market, and backwards compatibility isn't nearly as important in the phone market. Maybe we can get a GL ES 3 that changes the API into a more modern alternative, and then the desktop can follow along and start using that instead of the old GL.
    OpenGL ES Halti?

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
  •