Re: [info-performer] OpenGL Shading Language in Performer 3.2?

Date view Thread view Subject view Author view

From: Alexander Lechner (alexander.lechner++at++vertigo-systems.de)
Date: 09/08/2004 01:14:58


On Wednesday 08 September 2004 04:06, Alexandre Naaman wrote:
> Hi Simon,
>
> > I have a question about the next Performer version, I hope someone can
> > help me:
> >
> > Will OpenGL Shading Language be supported and if yes: When is Performer
> > 3.2 supposed to be available?
> > I'm thinking about working with GPU programming in Performer and don't
> > want to start with the GL_ARB_vertex/fragment_program Extensions, if the
> > GL_ARB_Shader_Objects stuff will soon be supported. Therfore it's very
> > important for me, for how long I have to wait...
>
> Yes, support for GLSL will be in 3.2. At this point we're merely doing
> fine tuning to our support for GLSL and adding "external" features, like
> support for ATI's RenderMonkey, samples, documentation, etc.
>
> If there's anything in particular you'd like to see for this feature in
> 3.2 please advise. The API is more or less frozen but that doesn't stop us
> from making additions in other parts of the release.
>
We've already implemented a Cg binding in our VR framework Avango (which also
features a Performer renderer). A crucial think I observed is a tight
integration of Geometry AND Shaders. For performance reasons it is obvious to
use pfGeoArrays, but I think they have a rather clumsy interface in
Performer. There should be more helper functions to cope with them. Say for
example when you want to generate binormals and tangets for a geometry in a
pfGeoArray or when trying to rearrange the vertices in a cache friendly way,
things get really complicated if you want to do this in a general manner.
When a pfGeoArray is being shaded by a GLSL shader (or Cg), the attributes
must be bound to the location the shader expects them. Maybe there could be
some clever way to match them.
Regarding parameters there should be some possibility to access the current PF
viewmatrix (without having to invert and post-rotate it!), current model
matrix and alike in the shaders. Maybe there could be some special functions
in pfGProgramParams to bind the current model matrix (normal, transposed,
inverted, inverted transposed) and so on to named parameters.

I really appreciate the hard effort you put into the integration of these
techonlogies as it's often more difficult to bring them into an exisiting
system than designing a system (using these technologies) from scratch like
NVSG.
> In terms of timing, we should have Alphas/Betas soon. Stay tuned ... I'll
> let Allan reply to the details of the timing concerning the release of
> 3.2.
Good news!

Thanks,
Alex
>
> Hope this helps,
>
> Alex.
>
> -----------------------------------------------------------------------
> List Archives, Info, FAQ: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
> -----------------------------------------------------------------------

-- 
Alexander.Lechner     ++at++        vertigo-systems.de
Engelbertstraße 30    |    phone: +49-221-2405472
D-50674 Köln          |      fax: +49-221-34892616


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Wed Sep 08 2004 - 01:18:01 PDT