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