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
