Re: [Mesa3d-dev] Galuim3d alteration idea. Cache and common storage for glsl to native gpu conversions .

[Corbin S. <mos...@gm...>]

On Sat, Mar 13, 2010 at 3:13 AM, Peter Dolding <oi...@gm...> wrote:
> http://ccache.samba.org/ is where part of this idea comes from.
>
>
> Speeding up glsl conversion to gpu code will make things more effective.
> There is no point running the glsl to native gpu conversions more times than
> that are require particularly on devices or anything that is depending on
> battery life.
>
> This brings me to the second half of the idea common storage framework.
>
> Directory struct that comes to mind for me.
>
> /usr/shared/galuim3d/<target>/<application name>/<shader>/<version as
> filename>
>
> Target would contain glsl for like the raw glsl and like R300 for card
> particular implementations as per a list.
>
> Of course version of compiler would have to be  stuck at the start of the
> pre built GPU code and checked on load.  If out of date rebuild.
>
> Then like a opengl extension to request shared glsl code access.
> galuim3dloader(application,shader,version) direct.
> galuim3dloaderlatest(application,shader) just to load the newest version of
> that shader.
>
> Few advantages of common glsl storage applications able to share glsl code
> like they can share libraries making it simple to implement fancy features
> on the gpu.    Able to reduce how much glsl code has to be built to
> particular cards.  And the possibility of allowing applications to migrate
> from card to card of different types without issues.   Reason shader
> information commonally exposed.
>
> Same kind of caching for opencl would also be good.   No point wasting
> cpu/gpu time running compilers when we can cache or store the results.
>
> Of course these ideas really were not possible to implement without access
> to raw GPU native code.

Already done, at least the parts that make sense. We have a system
called CSO (Constant State Objects) that caches native shader objects.
We don't store them as files for a handful of reasons; the largest
reason is that shaders need to be recompiled depending on other state
inside the driver.

-- 
Corbin Simpson
<Mos...@gm...>