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 20 of 22 FirstFirst ... 101819202122 LastLast
Results 191 to 200 of 212

Thread: Official feedback on OpenGL 3.2 thread

  1. #191
    Junior Member Newbie
    Join Date
    Sep 2009
    Posts
    11

    Re: Official feedback on OpenGL 3.2 thread

    Does anyone know if ATI will keep supporting Opengl 1.x/2.x drivers? I know that this is the case for nvidia
    Rami

  2. #192
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    353

    Re: Official feedback on OpenGL 3.2 thread

    Ati tends to avoid announcing future plans, but I consider it highly, highly unlikely that they will ever stop supporting OpenGL 1.x / 2.x.

    Obviously, I cannot speak for Ati and this is just a personal opinion, so take that as you will. However, Ati's commercial customers are *all* using OpenGL 1.x / 2.x right now - I consider that as good a guarantee as any.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

  3. #193
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 3.2 thread

    The wglenumext.spec file is missing enumerators (and the definition of the extension itself) for WGL_ARB_framebuffer_sRGB.

  4. #194
    Member Regular Contributor
    Join Date
    Oct 2006
    Posts
    353

    Re: Official feedback on OpenGL 3.2 thread

    Quote Originally Posted by Alfonse Reinheart
    The wglenumext.spec file is missing enumerators (and the definition of the extension itself) for WGL_ARB_framebuffer_sRGB.
    Confirmed and logged as bug #210. This also affects glxenumext.spec.

    On a related note, the issues from the previous page (#195 and #201) were marked as fixed yesterday.
    [The Open Toolkit library: C# OpenGL 4.4, OpenGL ES 3.1, OpenAL 1.1 for Mono/.Net]

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

    Re: Official feedback on OpenGL 3.2 thread

    On a related note, the issues from the previous page (#195 and #201) were marked as fixed yesterday.
    I checked the spec files, and they're fixed. They even added GLuint64 and GLsync, which I hadn't mentioned were also missing.

  6. #196
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948

    Re: Official feedback on OpenGL 3.2 thread

    Also missing in the WGL spec files are entrypoints for WGL_EXT_swap_control.

  7. #197
    Junior Member Newbie
    Join Date
    Jan 2008
    Posts
    3

    Re: Official feedback on OpenGL 3.2 thread

    Hi, i've got two requests :

    First I think there's a problem with current gl.spec, those are defined as OpenGL 3.2 functions but are not specified in the spec pdf.

    Code :
    # OpenGL 3.2 (ARB_geometry_shader4) commands
     
    ProgramParameteri(program, pname, value)
    	return		void
    	param		program		UInt32 in value
    	param		pname		GLenum in value
    	param		value		Int32 in value
    	category	VERSION_3_2
    	version		1.2
    	extension
    	glxropcode	?
    	glxflags	ignore
    	offset		?
    ...
    FramebufferTextureFace(target, attachment, texture, level, face)
    	return		void
    	param		target		GLenum in value
    	param		attachment	GLenum in value
    	param		texture		UInt32 in value
    	param		level		Int32 in value
    	param		face		GLenum in value
    	category	VERSION_3_2
    	version		1.2
    	extension
    	glxropcode	?
    	glxflags	ignore
    	offset		?

    ProgramParameteri is useless as its parameter are now set in the geometry shader source code.
    FramebufferTextureFace was used to attach a single face of a cube map to a framebuffer object but it can be done with FramebufferTexture2D.
    So I think gl.spec has it wrong here.
    I might add that latest nVidia GL3.2 driver on linux (190.18.05) doesn't expose them (only the ARB version, from ARB_geometry_shader4).

    Second, I've already asked if there was an equivalent to glGetActiveUniform but for fragment shader outputs (see this post). There is an equivalent to glGetUniformLocation, it's glGetFragDataLocation, but output variable names can't be dynamically queried. So is it something planned ?

    Thanks.

  8. #198
    Advanced Member Frequent Contributor
    Join Date
    Apr 2009
    Posts
    600

    MAX_CLIP_DISTANCE 6 or 8??

    I see the following in the GL 3.2. core spec (version data 20090803) {looks like this is more like a GL 3.1 spec bug that went unnoticed} I see in Section 21.9 (page 97):


    This view volume may be further restricted by as many as n client-defined half-
    spaces. (n is an implementation-dependent maximum that must be at least 6.)
    but in Section G.2 (page 343)

    Update MAX_CLIP_DISTANCES from 6 to 8 in section 2.19 and table 6.37,
    to match GLSL (bug 4803).
    Spec bug?

    In truth I found this while checking if it was supposed to be 6 or 8 because nVidia drivers have it at 6, nVidia MAX_CLIP_DISTANCE only 6

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

    More spec bugs

    Several non-core ARB extensions are missing the suffix from their enum names. GL_ARB_cube_map_array is not a core extension, and the extension spec clearly has ARB suffixes on the names. But the .spec files do not.

    This is also true of GL_ARB_texture_gather, GL_ARB_draw_buffers_blend, and GL_ARB_sample_shading.

  10. #200
    Junior Member Newbie
    Join Date
    Jan 2010
    Posts
    3

    Re: Official feedback on OpenGL 3.2 thread

    Some of the new features has not been fully implemented by the hardware vendor, for example, the conditional rendering commands, and the conditional wait commands(glWaitSync).
    Independant stencil buffer and depth buffer of fbo, etc.
    Yet most of them have not been officially documented by the hardware vendor.

Posting Permissions

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