[Mesa-dev] [Bug 87516] glProgramBinary violates spec

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=87516

--- Comment #1 from Ian Romanick <idr at freedesktop.org> ---
(In reply to Leith Bade from comment #0)
> The current implementation of ARB_get_program_binary is incomplete and
> currently violates the spec.
> 
> Specifically these are the major issues:
> * glGet with GL_NUM_PROGRAM_BINARY_FORMATS is not implemented, it should
> return a at least 1.

The ARB_get_program_binary spec says:

    Get Value                       Type    Get Command          Minimum Value 
Description                        Section
    -------------                   ----    -----------          ------------- 
-----------                        -------
    PROGRAM_BINARY_FORMATS          0* x Z  GetIntegerv          N/A           
Enumerated program binary formats  2.14.3
    NUM_PROGRAM_BINARY_FORMATS      Z       GetIntegerv          0             
Number of program binary formats   2.14.3

The Khronos conformance tests check for this and behave appropriately.  Your
code should also check the number of available formats and behave
appropriately.  Like ARB_texture_compression and ARB_multisample, this is an
"ask if you can ask" extension.  You first have to ask if the extension is
there, then you ask whether you can do anything with it.

> * glGet with GL_PROGRAM_BINARY_FORMATS is not implemented, it should return
> a list with a single binaryFormat.

Given the above, it should return zero formats.

> * glGetProgramBinary succeeds with a binary length of zero, and also does
> not set binaryFormat to a valid value, it should always succeed and set
> binaryFormat to the value returned by GL_PROGRAM_BINARY_FORMATS.

Hmm... the spec doesn't really provide any guidance here, and I think that's
why it's implemented in this way.  Since there is no possible binary format,
there are zero bytes of binary data.  Nothing in the extension spec or later
OpenGL specs give any guidance for an error to be generated in this scenario. 
There are no binary formats, so there is no value to write to binaryFormat.

It's really not clear what the correct behavior is... other than not call this
function if there are no binary formats. :)

> * glProgramBinary always fails with GL_INVALID_OPERATION despite program
> being valid, it should always succeed if binaryFormat is correct, and return
> GL_INVALID_ENUM if not. Additionally it should always set GL_LINK_STATUS to
> GL_FALSE to indicate the program will need to load source anyway.

You are correct.  It should set link status to false and generate
GL_INVALID_ENUM.

> If these are not to be implemented ARB_program_binary and GL 4.1+ support
> should not be advertised by Mesa.

FWIW, no driver in Mesa advertises a GL version higher than 3.3.  Note that
this is also part of OpenGL ES 3.0, and at least the i965 driver has passed
OpenGL ES 3.0 conformance testing.  The behavior of
GL_NUM_PROGRAM_BINARY_FORMATS and GL_PROGRAM_BINARY_FORMATS may be annoying,
but it is, strictly speaking, correct.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20141220/518e2f45/attachment.html>