Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 11 of 17 FirstFirst ... 910111213 ... LastLast
Results 101 to 110 of 166

Thread: Official feedback on OpenGL 3.1 thread

  1. #101
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 3.1 thread

    Ector, as always if you have specific use cases or functionality that you can describe here that would make your app easier to develop (or perform better etc) please post them in the perpetual "talk about your applications" thread too.

    http://www.opengl.org/discussion_boa...133#Post246133

  2. #102
    Junior Member Newbie
    Join Date
    Oct 2006
    Location
    Sweden
    Posts
    23

    Re: Official feedback on OpenGL 3.1 thread

    I've already talked about my main issue - the requirement to explicitly link vertex and pixel shaders. It's just weird. Why? It's not necessary when using either ARB_*_program, Cg or HLSL. My app uses insane amounts of combinations.

    I also share about 40 float4 constants between all pixel shaders, and over 200 between all vertex shaders (not all shaders use all of them, of course, but there's a lot of sharing going on). It's just too much overhead to keep uploading them once per shader. And since GLSL only supports uniform buffers on the newest hardware, using them isn't an option, while classic indexed constants works just fine.

    You may ask, why this inefficient-looking design? Well, simply because my app is Dolphin, the Wii and Gamecube emulator, and I'm using shaders to emulate one of the most complex pieces of fixed function graphics hardware out there. It has MASSIVE configuration state, which is what we're using all these constants for.

  3. #103
    Member Regular Contributor
    Join Date
    Apr 2006
    Location
    Irvine CA
    Posts
    299

    Re: Official feedback on OpenGL 3.1 thread

    OK that is one that we are well familiar with and is near the top of the priority queue. It's an issue that I know Blizzard and TransGaming have both run into as well.

  4. #104
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,269

    Re: Official feedback on OpenGL 3.1 thread

    The need to link shaders into a program is simply because of the varyings. GLSL doesn't let you specify which slot to take.

    Try glProgramLocalParameters4fvEXT. Though, it requires you abandon GLSL: use nVidia asm for GF, and for ATi/Intel either
    1) use old ARB-asm for ATi/Intel or
    2) use GLSL but have your materials manually upload uniforms in a non-brute fashion or
    3) use GLSL and uniform-buffers/texture-buffers/VTF if available
    Imho, if you want to have speed and support SM2/SM3/SM4, there are 5 code-paths.

  5. #105
    Intern Newbie
    Join Date
    Jun 2008
    Location
    Russia, Moscow
    Posts
    40

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by Ilian Dinev
    T
    Try glProgramLocalParameters4fvEXT.

    Try void Uniform4fvARB(int location, sizei count, const float *value)

    or void UniformMatrix4fvARB(int location, sizei count, boolean transpose, const float *value

    uniform vec4 StreamVec4[ SIZE1 ];
    uniform mat4 StreamMatrxi[ SIZE2 ];


    instead ARB ASM ( which is obsoluted )

    Тут по-русский понимает кто-нибудь ?





  6. #106
    Senior Member OpenGL Pro Ilian Dinev's Avatar
    Join Date
    Jan 2008
    Location
    Watford, UK
    Posts
    1,269

    Re: Official feedback on OpenGL 3.1 thread

    ARB asm is obsolete, but fast and supported correctly on all gpus.
    NV asm is more modern than GLSL could hope to be; and loads/runs fast and without nV's shader-recompilation hiccups.
    Afaik GLSL and its glUniform*() are fast on ATi, without hiccups - provided that they compile under a given card/driver combo.

    glProgramLocalParameters4fvEXT's speed on E8500 @3.8GHz, SysRAM DDR3 @1.6GHz (timing 7-7-7-20), GF8600GT:
    144 bytes: 108 cpu cycles
    288 bytes: 224 cycles
    1728 bytes: 607 cycles

    So yes, gpu asm is as obsolete as C++ is to Java...

  7. #107
    Intern Newbie
    Join Date
    Jun 2008
    Location
    Russia, Moscow
    Posts
    40

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by Ilian Dinev
    ARB asm is obsolete, but fast and supported correctly on all gpus.
    Fine. If I wrote shader on DX10 will it run on DX9 hardware ?
    Why is it so non equal conditional for GL and DX ?

  8. #108
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,124

    Re: Official feedback on OpenGL 3.1 thread

    Quote Originally Posted by Ido Ilan
    The interest in OpenGL is declining, the community has lost faith in the Khronos group regarding OpenGL.
    s/the community/you/. Please speak only for yourself and stop spreading FUD.

  9. #109
    Advanced Member Frequent Contributor
    Join Date
    May 2001
    Posts
    566

    Re: Official feedback on OpenGL 3.1 thread

    The Khronos could have added more core features easily, such as geometry shaders, direct state access, long promised templated objects

    However it's crawling so that Direct3D is guaranteed to stay ahead by years.

  10. #110
    Junior Member Regular Contributor
    Join Date
    Mar 2009
    Location
    California
    Posts
    188

    Re: Official feedback on OpenGL 3.1 thread

    I don't have much of an opinion because the only thing I see that affects me is the uniform buffer objects feature. I never liked bindable uniforms, and ATI's first attempt to implement it didn't work for me, so I guess this is a good thing.

    I'm still using OpenGL 2.1, and I am mostly satisfied since ATI's drivers have gotten a lot better. I think an instance shader would be useful, that could discard entire instances of an object before they are drawn, for trees and grass.

    Really, for me the whole issue has not been Khronos but the state of ATI's drivers. And they have improved to the point where they are now usable.

Posting Permissions

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