On 02/16/2017 10:11 AM, Timothy Arceri wrote:


On 16/02/17 18:58, Timothy Arceri wrote:


On 16/02/17 17:55, Tapani Pälli wrote:

On 02/16/2017 04:52 AM, Timothy Arceri wrote:
In order add functionality to ARB_get_program_binary we need
binary format enums.

I've understood that this is a driver internal enumeration. When
application gets the binary it also receives enum (integer value) what
format we gave. Then when loading application needs to query what
formats are supported by the implementation and load the correct binary.
We just need to internally make agreement on format list and return
correct one matching the current driver in use?

Not that it's actually likely to happen but if we were to only have a
single MESA enum an application could only distribute a single binary.
e.g either for AMD, INTEL or NVIDIA but not one for each. That is unless
we were to compile and pack all gpu vendor binarys at the same time
which seems overly complicated and expensive.

I could see an intenal id being used for gpu generations from hardware
vendors.

Or are you saying we don't need to define the enums? If so I don't think
that is correct. The ARB_get_program_binary extension says:

    "A vendor extension must also be present in order
    to define one or more binary formats, thereby populating the list of
    PROGRAM_BINARY_FORMATS.  The <binaryFormat> returned by
    GetProgramBinary is always one of the binary formats in this list.

    ...

    The beauty of this extension, however, is that an application does
not need
    to be aware of the vendor extension on any given implementation. It
only
    needs to retrieve a program binary with an anonymous <binaryFormat> and
    resupply that same <binaryFormat> when loading the program binary."


OK, I did not spot this one. At same time we have to supply extension where values defined (which makes it hard to make changes later) but then from application POV the values are still considered anonymous and it will likely not use the extension. This is a bit strange requirement ..

We can still internally put more data in to the blob about exact backend and version requirements and so on so I guess single enum value per vendor is enough.







---

Techland games such as Dead Island and Dying Light make use of
GetProgramBinary(). My current guess is the Dead Island crash
https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
due to buggy handling of this feature not being available.

Anyway I'm not sure how we go about getting Khronos to assign
enums for the binary formats but thought I'd send this to the
list for discussion.

 docs/specs/MESA_program_binary.txt | 78
++++++++++++++++++++++++++++++++++++++
 1 file changed, 78 insertions(+)
 create mode 100644 docs/specs/MESA_program_binary.txt

diff --git a/docs/specs/MESA_program_binary.txt
b/docs/specs/MESA_program_binary.txt
new file mode 100644
index 0000000..b34e42e
--- /dev/null
+++ b/docs/specs/MESA_program_binary.txt
@@ -0,0 +1,78 @@
+Name
+
+    MESA_program_binary
+
+Name Strings
+
+    GL_MESA_program_binary
+
+Contact
+
+    Timothy Arceri (tarceri 'at' itsqueeze.com)
+
+Status
+
+    Complete.
+
+Version
+
+    Last Modified Date: February 16, 2017
+    Revision: #1
+
+Number
+
+    ???
+
+Dependencies
+
+    OpenGL ES 2.0 is required.
+
+    Written based on the wording of the OpenGL ES 2.0 specification.
+
+    This extension interacts with OES_get_program_binary.
+
+Overview
+
+    MESA provides drivers for multiple hardware vendors. This
extension
+    provides binary formats in order to avoid conflicts between
drivers when
+    loading precompiled binaries.
+
+New Procedures and Functions
+
+    None.
+
+New Tokens
+
+    Accepted by the <binaryFormat> parameter of ShaderBinary:
+
+        MESA_PROGRAM_BINARY_AMD                    ????
+        MESA_PROGRAM_BINARY_NV                     ????
+        MESA_PROGRAM_BINARY_INTEL                  ????
+        MESA_PROGRAM_BINARY_BCOM                   ????
+        MESA_PROGRAM_BINARY_QCOM                   ????
+
+Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL
Operation)
+
+    Add the following paragraph to the end of section 2.10.2:
+
+    "Depending on the hardware in use the apropriate <binaryFormat> is
+    returned when querying the list of SHADER_BINARY_FORMATS.
+
+    Pre-compiled shader binaries in this format may be loaded via
ShaderBinary.
+
+    When a binary fails to load, an INVALID_VALUE error is generated
and a
+    more detailed error message is appended to the shader's info log."
+
+Errors
+
+    INVALID_VALUE is generated if the <binary> parameter to
ShaderBinary was
+    produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+    None.
+
+Revision History
+
+    #01    02/16/2010    Timothy Arceri       First draft.
+

_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to