mesa3d-dev

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

[Peter D. <oi...@gm...>]

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.

Peter Dolding

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