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 19 of 22 FirstFirst ... 91718192021 ... LastLast
Results 181 to 190 of 212

Thread: Official feedback on OpenGL 3.2 thread

  1. #181
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Official feedback on OpenGL 3.2 thread

    I was wondering the same thing...
    GLIM - Immediate Mode Emulation for GL3

  2. #182
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,067

    Re: Official feedback on OpenGL 3.2 thread

    Huh? An ancient extension like that? Crossbar hasn't been relevant since the R300/NV30 days.
    I didn't try if it really works (maybe it is accidentally exposed by the driver in the extension string), just make a comparison of ARB extension lists of the two drivers. I have only tried GL_ARB_uniform_buffer_object, and it works (at least things that I tried).

  3. #183
    Senior Member OpenGL Pro sqrt[-1]'s Avatar
    Join Date
    Jun 2002
    Location
    Australia
    Posts
    1,000

    Re: Official feedback on OpenGL 3.2 thread

    I think that Crossbar extension was always supported by Nvidia through their own NV extension (used the same tokens and everything) I think the only difference was behaviour when accessing a texture stage that did not have a texture bound.

    From the ARB spec:
    If a texture environment for a given texture unit references a texture unit that is disabled or does not have a valid texture object bound to it, then it is as if texture blending is disabled for the given texture unit

    I think the Nvidia spec said behaviour was undefined when accessing a unbound texture stage.

    It always seemed to me that Nvidia was being really pedantic about the spec - and since it already had an extension that did exactly the same thing (in non error cases), it was impossible for them to support it fully.

  4. #184
    Junior Member Regular Contributor
    Join Date
    Jan 2004
    Location
    Czech Republic, EU
    Posts
    190

    Re: Official feedback on OpenGL 3.2 thread

    The Crossbar extension is part of OpenGL 1.4 and has been removed from OpenGL 3.1. Now it's back again.
    (usually just hobbyist) OpenGL driver developer

  5. #185
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 3.2 thread

    The Crossbar extension is part of OpenGL 1.4 and has been removed from OpenGL 3.1. Now it's back again.
    But it's part of ARB_compatibility, since it was once part of core; you don't need to advertise it explicitly.

  6. #186
    Intern Contributor
    Join Date
    Aug 2009
    Posts
    66

    Re: Official feedback on OpenGL 3.2 thread

    Original from: http://www.opengl.org/discussion_boa...316#Post263316

    A feature request about precision.

    Bundling of pipelines/stream processors for acting as a wider, more precise pipelines/stream processors. Enabling dynamical, programmable precisions.

    Have seen that with GLSL, shaders can be coupled (coupled in serie) to do multiple effects.

    What if you could couple pipelines in parallel for enhanced precision?
    Not for parallel processing, just adding precision.
    e.g. couple eight pipelines with full 32bit accuracy for each component to one combined pipeline with 8*32bit = 256bit accuracy.

    This has the advantage to be very scalable with a good specification.
    If there is only one pipeline then the pipeline will just have to take more time in calculations and store data in cache memory.
    If there are pipelines left because of the size of the combined pipeline (e.g. 5*32bit on 17 stream processors/pipelines leaves out 17modulus5 = 2 left),
    no problem, then so be it.

    This would allow dynamical, programmable precision which is useful, welcome (essential?) in several area's.
    Physics simulations for instance.

    But also in more mainstream applications.
    Position calculations in games on huge maps without running into precision issues. (It's going to be slower than less precision but at least it is possible to have good animation and movement.)


    Got this idea after thinking about precision problems in physics simulations and the fact that shaders can be coupled after each other. That each pipeline has a certain precision and the current graphics processors have a lot of them ATI: graphic cards with 800 stream processors/pipelines.

  7. #187
    Intern Contributor
    Join Date
    Aug 2009
    Posts
    66

    Re: Official feedback on OpenGL 3.2 thread

    Sounds good, doesn't it?
    Why not bundling/coupling the stream processors to enhance precision when needed anyway?

  8. #188
    Senior Member OpenGL Guru
    Join Date
    Dec 2000
    Location
    Reutlingen, Germany
    Posts
    2,042

    Re: Official feedback on OpenGL 3.2 thread

    Please don't cross-post.
    GLIM - Immediate Mode Emulation for GL3

  9. #189
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 3.2 thread

    The enumext.spec file has an error in it. There is a line:

    Code :
    	use VERSION_3_1			    R_SNORM

    in the EXT_texture_snorm extension. It should be this:

    Code :
    	use VERSION_3_1			    RED_SNORM

    as "R_SNORM" doesn't exist.

    Additionally, in gl.tm, there is no entry for Int64, though it is used in the gl.spec file. There is an entry for Int64Ext.

  10. #190
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    352

    Re: Official feedback on OpenGL 3.2 thread

    @Alfonse Reinhart: I can confirm both issues.

    The first was filed as bug #195 back in August.

    Couldn't find anything about the second one, filed it as bug #201.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

Posting Permissions

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