Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-21 Thread Timothy Arceri 



On 22/02/17 06:11, Ian Romanick wrote:

On 02/16/2017 04:33 PM, Timothy Arceri wrote:

On 17/02/17 10:44, Ian Romanick wrote:

On 02/15/2017 11:58 PM, 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.


Applications really, really, *REALLY* should not distribute binaries
retrieved from the driver.  The intention of this extension is for
applications to implement their own shader cache, for example, at
application installation.  The driver can reject the binary at any time
for any reason.  Driver changes, hardware changes, OS changes, phase of
the moon, etc.

Looking at the GLES extension registry, it appears that the other
vendors have just a single binary for all the hardware they make.  Based
on that, having a single Mesa enum isn't an insane idea.  We would just
need to agree on the format of the header so that the driver receiving
the blob could determine which driver generated the blob.


The only other thing to consider with a single enum is that it will
require a laptop with an Intel cpu and Nvidia gpu for example to
recompile the binary if the user were to switch between using the Intel
and Nvidia gpus. This might happen depending on if the laptop is plugged
into a power source or not.

If we don't care about this than one enum is fine.


Hm... I think we care, but I don't think multiple enums will help
existing apps... but maybe?  I imagine the usual scenario is:

- User runs first time on nouveau.

- Application saves binaries from nouveau.

- User runs second time on i965.

- Application submits binary from nouveau.

- Application deletes its binary cache, resubmits from source, resaves
binaries from i965.

- User runs third time on nouveau.

- Application submits binary from i965.

- Application deletes its binary cache, resubmits from source, resaves
binaries from nouveau.

- Lather

- Rinse

- Repeat

It seems like if we actually care about this configuration, we'd need a
more complex solution.  It's not 100% clear what that solution would be
or how we would be able to implement it.  I think the right solution is
a driver-side shader cache that is smart enough to track binaries from
multiple drivers without stomping on each other.  Right? :)


Yeah ok, I hadn't thought about apps ignoring the enum and just keeping 
a single copy. I guess your right we should eventually have a 
driver-side cache by default so can just package up the cache items and 
return them.


I'm happy with a one enum solution :)





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.



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

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-21 Thread Ian Romanick 
On 02/16/2017 04:33 PM, Timothy Arceri wrote:
> On 17/02/17 10:44, Ian Romanick wrote:
>> On 02/15/2017 11:58 PM, 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.
>>
>> Applications really, really, *REALLY* should not distribute binaries
>> retrieved from the driver.  The intention of this extension is for
>> applications to implement their own shader cache, for example, at
>> application installation.  The driver can reject the binary at any time
>> for any reason.  Driver changes, hardware changes, OS changes, phase of
>> the moon, etc.
>>
>> Looking at the GLES extension registry, it appears that the other
>> vendors have just a single binary for all the hardware they make.  Based
>> on that, having a single Mesa enum isn't an insane idea.  We would just
>> need to agree on the format of the header so that the driver receiving
>> the blob could determine which driver generated the blob.
> 
> The only other thing to consider with a single enum is that it will
> require a laptop with an Intel cpu and Nvidia gpu for example to
> recompile the binary if the user were to switch between using the Intel
> and Nvidia gpus. This might happen depending on if the laptop is plugged
> into a power source or not.
> 
> If we don't care about this than one enum is fine.

Hm... I think we care, but I don't think multiple enums will help
existing apps... but maybe?  I imagine the usual scenario is:

- User runs first time on nouveau.

- Application saves binaries from nouveau.

- User runs second time on i965.

- Application submits binary from nouveau.

- Application deletes its binary cache, resubmits from source, resaves
binaries from i965.

- User runs third time on nouveau.

- Application submits binary from i965.

- Application deletes its binary cache, resubmits from source, resaves
binaries from nouveau.

- Lather

- Rinse

- Repeat

It seems like if we actually care about this configuration, we'd need a
more complex solution.  It's not 100% clear what that solution would be
or how we would be able to implement it.  I think the right solution is
a driver-side shader cache that is smart enough to track binaries from
multiple drivers without stomping on each other.  Right? :)

>>> 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.

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

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-17 Thread Nicolai Hähnle 

On 17.02.2017 09:31, Ernst Sjöstrand wrote:

Also, what if the user switches between say AMDGPU-PRO and RadeonSI?


I'd expect radeonsi to use the single Mesa enum, while AMDGPU-PRO 
obviously uses an AMD-assigned enum.


Cheers,
Nicolai



Regards
//Ernst

2017-02-17 1:33 GMT+01:00 Timothy Arceri >:



On 17/02/17 10:44, Ian Romanick wrote:

On 02/15/2017 11:58 PM, 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.


Applications really, really, *REALLY* should not distribute binaries
retrieved from the driver.  The intention of this extension is for
applications to implement their own shader cache, for example, at
application installation.  The driver can reject the binary at
any time
for any reason.  Driver changes, hardware changes, OS changes,
phase of
the moon, etc.

Looking at the GLES extension registry, it appears that the other
vendors have just a single binary for all the hardware they
make.  Based
on that, having a single Mesa enum isn't an insane idea.  We
would just
need to agree on the format of the header so that the driver
receiving
the blob could determine which driver generated the blob.


The only other thing to consider with a single enum is that it will
require a laptop with an Intel cpu and Nvidia gpu for example to
recompile the binary if the user were to switch between using the
Intel and Nvidia gpus. This might happen depending on if the laptop
is plugged into a power source or not.

If we don't care about this than one enum is fine.



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.

---

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.


There's a two step process:

1. Vendors request a block of values via the Khronos internal
bugzilla.

2. When the spec is ready, another bug is submitted requesting
the spec
be published.

Mesa might still have some available enums assigned to it.  I'll
have to
check...

 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 000..b34e42e
--- /dev/null
+++ b/docs/specs/MESA_program_binary.txt
@@ -0,0 +1,78 @@
+Name
+
+MESA_program_binary
+
+Name Strings
+
+GL_MESA_program_binary
+

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-17 Thread Ernst Sjöstrand 
Also, what if the user switches between say AMDGPU-PRO and RadeonSI?

Regards
//Ernst

2017-02-17 1:33 GMT+01:00 Timothy Arceri :

>
>
> On 17/02/17 10:44, Ian Romanick wrote:
>
>> On 02/15/2017 11:58 PM, 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.
>>>
>>
>> Applications really, really, *REALLY* should not distribute binaries
>> retrieved from the driver.  The intention of this extension is for
>> applications to implement their own shader cache, for example, at
>> application installation.  The driver can reject the binary at any time
>> for any reason.  Driver changes, hardware changes, OS changes, phase of
>> the moon, etc.
>>
>> Looking at the GLES extension registry, it appears that the other
>> vendors have just a single binary for all the hardware they make.  Based
>> on that, having a single Mesa enum isn't an insane idea.  We would just
>> need to agree on the format of the header so that the driver receiving
>> the blob could determine which driver generated the blob.
>>
>
> The only other thing to consider with a single enum is that it will
> require a laptop with an Intel cpu and Nvidia gpu for example to recompile
> the binary if the user were to switch between using the Intel and Nvidia
> gpus. This might happen depending on if the laptop is plugged into a power
> source or not.
>
> If we don't care about this than one enum is fine.
>
>
>
>> 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.
>>>
>>> ---
>
> 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.
>

>> There's a two step process:
>>
>> 1. Vendors request a block of values via the Khronos internal bugzilla.
>>
>> 2. When the spec is ready, another bug is submitted requesting the spec
>> be published.
>>
>> Mesa might still have some available enums assigned to it.  I'll have to
>> check...
>>
>>  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 000..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  parameter of ShaderBinary:
> +
> +MESA_PROGRAM_BINARY_AMD
> +MESA_PROGRAM_BINARY_NV 
> +MESA_PROGRAM_BINARY_INTEL  
> +MESA_PROGRAM_BINARY_BCOM   
> +

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-16 Thread Timothy Arceri 



On 17/02/17 10:44, Ian Romanick wrote:

On 02/15/2017 11:58 PM, 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.


Applications really, really, *REALLY* should not distribute binaries
retrieved from the driver.  The intention of this extension is for
applications to implement their own shader cache, for example, at
application installation.  The driver can reject the binary at any time
for any reason.  Driver changes, hardware changes, OS changes, phase of
the moon, etc.

Looking at the GLES extension registry, it appears that the other
vendors have just a single binary for all the hardware they make.  Based
on that, having a single Mesa enum isn't an insane idea.  We would just
need to agree on the format of the header so that the driver receiving
the blob could determine which driver generated the blob.


The only other thing to consider with a single enum is that it will 
require a laptop with an Intel cpu and Nvidia gpu for example to 
recompile the binary if the user were to switch between using the Intel 
and Nvidia gpus. This might happen depending on if the laptop is plugged 
into a power source or not.


If we don't care about this than one enum is fine.




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.


---

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.


There's a two step process:

1. Vendors request a block of values via the Khronos internal bugzilla.

2. When the spec is ready, another bug is submitted requesting the spec
be published.

Mesa might still have some available enums assigned to it.  I'll have to
check...


 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 000..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  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  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  parameter to
ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-16 Thread Ian Romanick 
On 02/15/2017 11:58 PM, 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.

Applications really, really, *REALLY* should not distribute binaries
retrieved from the driver.  The intention of this extension is for
applications to implement their own shader cache, for example, at
application installation.  The driver can reject the binary at any time
for any reason.  Driver changes, hardware changes, OS changes, phase of
the moon, etc.

Looking at the GLES extension registry, it appears that the other
vendors have just a single binary for all the hardware they make.  Based
on that, having a single Mesa enum isn't an insane idea.  We would just
need to agree on the format of the header so that the driver receiving
the blob could determine which driver generated the blob.

> 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.
> 
>>> ---
>>>
>>> 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.

There's a two step process:

1. Vendors request a block of values via the Khronos internal bugzilla.

2. When the spec is ready, another bug is submitted requesting the spec
be published.

Mesa might still have some available enums assigned to it.  I'll have to
check...

>>>  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 000..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  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  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  parameter to
>>> ShaderBinary was
>>> +produced with an incompatible version of the MESA shader compiler.
>>> +
>>> +New State
>>> +
>>> +None.
>>> +
>>> +Revision History
>>> +
>>> +#01

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-16 Thread Nicolai Hähnle 

On 16.02.2017 09:21, Tapani Pälli wrote:

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  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
 and
resupply that same  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.


So the question is what the use case of this extension really is. Keep 
in mind that the driver can always decide to fail loading a binary.


If the purpose is to allow games to cache shaders for a second run, then 
I think even a single Mesa enum is sufficient -- the local driver is 
always going to be the same.


If the purpose is to distribute pre-compiled binaries via the internet, 
then assigning enums that need to be registered with Khronos is clearly 
not scalable. We can't have an enum for each build ID, so it's all 
unworkable anyway, and we'd need some way of querying a build ID string.


I think this points towards us registering a single enum for Mesa only.

Still, a bit more information about how this extension is actually used 
in the wild could change my mind.


Cheers,
Nicolai
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-16 Thread Tapani Pälli 



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  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  and
resupply that same  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 000..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  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  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  parameter to
ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+


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

___
mesa-dev

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-16 Thread Timothy Arceri 



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  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  and
resupply that same  when loading the program binary."









---

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 000..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  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  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  parameter to
ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy 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

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-15 Thread Timothy Arceri 



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.






---

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 000..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  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  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  parameter to
ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+


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

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-15 Thread Tapani Pälli 


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?




---

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 000..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  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  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  parameter to ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+


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

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-15 Thread Timothy Arceri 

On 16/02/17 15:42, Edward O'Callaghan wrote:



On 02/16/2017 01:52 PM, Timothy Arceri wrote:

In order add functionality to ARB_get_program_binary we need
binary format enums.
---

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 000..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  parameter of ShaderBinary:
+
+MESA_PROGRAM_BINARY_AMD


Hey Timothy,

What happens in the case when say, non-GCN vs. GCN vs.
other-shinny-new-ISA?


I believe the intention is to turn the driver into a form of offline 
compiler, so in theory you could compile and store precompiled shaders 
for multiple generations in the same binary.


In practice we would probably just return INVALID_ENUM from 
ProgramBinary/ShaderBinary which would tell the app it needs to 
recompile the program.



Since this is for mesa_ would it be better to have
something like,

MESA_PROGRAM_BINARY_GALLIUM, MESA_PROGRAM_BINARY_NIR or am I
misunderstanding something (probably?)


I think it would be better to divide things up by hardware vendor rather 
than trying to force sharing where it may or may not make sense. Other's 
may have other ideas, we will wait and see.




Kindest Regards,
Edward.


+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  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  parameter to ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+




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

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-15 Thread Edward O'Callaghan 


On 02/16/2017 01:52 PM, Timothy Arceri wrote:
> In order add functionality to ARB_get_program_binary we need
> binary format enums.
> ---
> 
> 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 000..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  parameter of ShaderBinary:
> +
> +MESA_PROGRAM_BINARY_AMD

Hey Timothy,

What happens in the case when say, non-GCN vs. GCN vs.
other-shinny-new-ISA? Since this is for mesa_ would it be better to have
something like,

MESA_PROGRAM_BINARY_GALLIUM, MESA_PROGRAM_BINARY_NIR or am I
misunderstanding something (probably?)

Kindest Regards,
Edward.

> +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  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  parameter to ShaderBinary was
> +produced with an incompatible version of the MESA shader compiler.
> +
> +New State
> +
> +None.
> +
> +Revision History
> +
> +#0102/16/2010Timothy Arceri   First draft.
> +
> 



signature.asc
Description: OpenPGP digital signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [RFC] spec: MESA_program_binary

2017-02-15 Thread Timothy Arceri 
In order add functionality to ARB_get_program_binary we need
binary format enums.
---

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 000..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  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  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  parameter to ShaderBinary was
+produced with an incompatible version of the MESA shader compiler.
+
+New State
+
+None.
+
+Revision History
+
+#0102/16/2010Timothy Arceri   First draft.
+
-- 
2.9.3

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