Mesa3D

Philipp Klaus Krause wrote:

> I don't know much about the current vertex array implementation, so
> sorry if what I propose is already implemented or impossible.
> 
> Since vertex programs take over the first part of the OpenGL
> pipeline it might be the fastest if they can access the data directly.
> 
> So if we could just have a function called once for every vertex
> that has an index and pointers to the arrays as parameters, we
> could directly access the vertex arrays from the fragment program,
> eliminating any need for additional copies or transformations.
> 
> For immediate mode we would just call that function with zero index and
> the adresses of the supplied attributes.
> 
> ProcessVertex(GLunit index, GLvoid **arrays, GLvoid *results);

It should be possible, but it might be a little quirky for hardware 
vertex programs.  The other problem is dealing with vertex stride.  In 
addition to a pointer to the base of the array, you'd need to know the 
byte-stride.  That and the added function call overhead might ruin some 
of the potential benefit.

Ian Romanick wrote:
> Philipp Klaus Krause wrote:
> 
>> I don't know much about the current vertex array implementation, so
>> sorry if what I propose is already implemented or impossible.
>>
>> Since vertex programs take over the first part of the OpenGL
>> pipeline it might be the fastest if they can access the data directly.
>>
>> So if we could just have a function called once for every vertex
>> that has an index and pointers to the arrays as parameters, we
>> could directly access the vertex arrays from the fragment program,
>> eliminating any need for additional copies or transformations.
>>
>> For immediate mode we would just call that function with zero index and
>> the adresses of the supplied attributes.
>>
>> ProcessVertex(GLunit index, GLvoid **arrays, GLvoid *results);
> 
> 
> It should be possible, but it might be a little quirky for hardware 
> vertex programs.  The other problem is dealing with vertex stride.  In 
> addition to a pointer to the base of the array, you'd need to know the 
> byte-stride.  That and the added function call overhead might ruin some 
> of the potential benefit.

This interface already exists, in the pipeline/pipeline stage structures and 
the VB (vertex_buffer) structure.  Rather than being called once per vertex, 
the pipeline_stage.run() method is called once per group of vertices, but the 
effect is the same.

There are some tweaks that could be made to the pipeline structure to fit 
better with the way vertex & fragment programs and their attributes have been 
defined, but that's really of more concern to the ARB_fp code than for vertex 
programs.  Basically the current approach of wrapping vertex program execution 
in a pipeline stage is correct.

Keith

Brian Paul schrieb:
> Pasi Kärkkäinen wrote:
> 
>> Hi all!
>>
>>> From the http://www.opengl.org:
>>
>>
>> OpenGL 2.0 specification available for download
>>
>> http://www.opengl.org/documentation/opengl_current_version.html
>> http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
>>
>> Any plans for 2.0 support in Mesa? I think the biggest "todo" is the
>> sw-emulation of glsl?
> 
> 
> Yeah, implementing the shading language will be a huge project.  It 
> would be nice if a group of volunteers would work together to implement it.
> 
> I'll probably start working on some of the infrastructure for 2.0 
> support in the near future.  But the GLSL parser and code generator will 
> be the bulk of the 2.0 work by far.
> 
> -Brian
> 

Some modifications to Mesa are necessary:
-Change glColor3 behaviour,
-Seperate legacy and generic vertex attributes.
  GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program2
  needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3
  allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program
  (assuming both extensions present) there may be no attribute aliasing.
-I dont' know about GL_ARB_texture_non_power_of_two and
  GL_ARB_draw_buffers. Are they supported already?
-The rest should be there.

I planned to do some work towards shader support, but wanted to wait for
The 2.0 spec to be released to see what would change. I probably won't
find much time before mid-october or so. This is what I had in mind:

Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader,
GL_ARB_fragment_program and GL_ARB_fragment_shader that create some
intermediate representation.
Then, at least four backends: One for SSE to get fast software
rendering on newer x86, one that interpretes for the architectures where
there is no compiling backend, one for the new intel chips and their
fragment program support and finally, one for the Wildcat VP
(I don't have docs for it though and doubt that I will ever get any,
I haven't asked Intel about i915 yet).

So get get something running I would first craete the
GL_ARB_vertex_program frontend. Then the interpreting backend. If it's
at least as fast as the solution we have now, we can already put it in
Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend.

Then we can take the new concept to the fragment shader side, where
it should be rather easy to get GL_ARB_fragment_program and
GL_ARB_fragment_shader support and get the interpreted and SSE backends
running. Next would be the i915 backend, since the driver already
supports fragment programs and it shouldn't be left behind.

Then when someone uses the fragment shader on let's say the i915 this
will happen:
If the i915 compiler says it can't handle the program (due to lack of
hardware support for some advanced functionality) the SSE backend
with software rendeirng will be used if it's on x86. Otherwise the
generic, interpreting backend will be used.

Philipp

Philipp Klaus Krause wrote:
> Brian Paul schrieb:
>=20
>> Pasi K=E4rkk=E4inen wrote:
>>
>>> Hi all!
>>>
>>>> From the http://www.opengl.org:
>>>
>>>
>>>
>>> OpenGL 2.0 specification available for download
>>>
>>> http://www.opengl.org/documentation/opengl_current_version.html
>>> http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
>>>
>>> Any plans for 2.0 support in Mesa? I think the biggest "todo" is the
>>> sw-emulation of glsl?
>>
>>
>>
>> Yeah, implementing the shading language will be a huge project.  It=20
>> would be nice if a group of volunteers would work together to=20
>> implement it.
>>
>> I'll probably start working on some of the infrastructure for 2.0=20
>> support in the near future.  But the GLSL parser and code generator=20
>> will be the bulk of the 2.0 work by far.
>>
>> -Brian
>>
>=20
> Some modifications to Mesa are necessary:
> -Change glColor3 behaviour,
> -Seperate legacy and generic vertex attributes.
>  GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program=
2
>  needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3
>  allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program
>  (assuming both extensions present) there may be no attribute aliasing.
> -I dont' know about GL_ARB_texture_non_power_of_two and
>  GL_ARB_draw_buffers. Are they supported already?
> -The rest should be there.

Right.  That's some of the stuff I was planning on doing.


> I planned to do some work towards shader support, but wanted to wait fo=
r
> The 2.0 spec to be released to see what would change. I probably won't
> find much time before mid-october or so. This is what I had in mind:
>=20
> Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader,
> GL_ARB_fragment_program and GL_ARB_fragment_shader that create some
> intermediate representation.

Well, I'd consider the current internal representation of=20
vertex/fragment programs to act as an intermediate representation that=20
can be translated into hardware/SSE/etc forms.  That's what Keith did=20
in the i915 driver.


> Then, at least four backends: One for SSE to get fast software
> rendering on newer x86, one that interpretes for the architectures wher=
e
> there is no compiling backend, one for the new intel chips and their
> fragment program support and finally, one for the Wildcat VP
> (I don't have docs for it though and doubt that I will ever get any,
> I haven't asked Intel about i915 yet).
>=20
> So get get something running I would first craete the
> GL_ARB_vertex_program frontend. Then the interpreting backend. If it's
> at least as fast as the solution we have now, we can already put it in
> Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend.
>=20
> Then we can take the new concept to the fragment shader side, where
> it should be rather easy to get GL_ARB_fragment_program and
> GL_ARB_fragment_shader support and get the interpreted and SSE backends
> running. Next would be the i915 backend, since the driver already
> supports fragment programs and it shouldn't be left behind.
>=20
> Then when someone uses the fragment shader on let's say the i915 this
> will happen:
> If the i915 compiler says it can't handle the program (due to lack of
> hardware support for some advanced functionality) the SSE backend
> with software rendeirng will be used if it's on x86. Otherwise the
> generic, interpreting backend will be used.

This generally sounds good.  Before anyone starts tearing up the=20
current code, I'd like to see a good plan first.

I'd like to at least rename and reorganize some of the sources for=20
vertex/fragment programs before anything else.

-Brian

Philipp Klaus Krause wrote:
> Brian Paul schrieb:
>> Pasi K=E4rkk=E4inen wrote:
>>
>>>> From the http://www.opengl.org:
>>>
>>> OpenGL 2.0 specification available for download
>>>
>>> http://www.opengl.org/documentation/opengl_current_version.html
>>> http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
>>>
>>> Any plans for 2.0 support in Mesa? I think the biggest "todo" is the
>>> sw-emulation of glsl?
>>
>> Yeah, implementing the shading language will be a huge project.  It=20
>> would be nice if a group of volunteers would work together to=20
>> implement it.
>>
>> I'll probably start working on some of the infrastructure for 2.0=20
>> support in the near future.  But the GLSL parser and code generator=20
>> will be the bulk of the 2.0 work by far.
>>
>> -Brian
>>
>=20
> Some modifications to Mesa are necessary:
> -Change glColor3 behaviour,

This is a very trivial change.

> -Seperate legacy and generic vertex attributes.
>  GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program=
2
>  needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3
>  allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program
>  (assuming both extensions present) there may be no attribute aliasing.

I'm not sure I follow you here.  Doesn't this just mean that we need new=20
targets when GLSL support is added?

> -I dont' know about GL_ARB_texture_non_power_of_two and
>  GL_ARB_draw_buffers. Are they supported already?

ARB_texture_non_power_of_two is supported.  It should be easy to add=20
"fake" support ARB_draw_buffers.  It was specified such that a driver=20
can support only 1 output.  This is just like ARB_texture_compression=20
where you can support the extension, but not support any compressed=20
texture formats. :)

> -The rest should be there.

Some changes need to be made to ARB_point_sprite support, but that's=20
pretty trivial.  Some tweaks would also need to be made to=20
EXT_stencil_two_side support.  Those are less trivial, but shouldn't be=20
too painful.  All of these are jobs that someone fairly new to the=20
project could handle. ;)

> I planned to do some work towards shader support, but wanted to wait fo=
r
> The 2.0 spec to be released to see what would change. I probably won't
> find much time before mid-october or so. This is what I had in mind:
>=20
> Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader,
> GL_ARB_fragment_program and GL_ARB_fragment_shader that create some
> intermediate representation.
> Then, at least four backends: One for SSE to get fast software
> rendering on newer x86, one that interpretes for the architectures wher=
e
> there is no compiling backend, one for the new intel chips and their
> fragment program support and finally, one for the Wildcat VP
> (I don't have docs for it though and doubt that I will ever get any,
> I haven't asked Intel about i915 yet).

Ideally, this could be done as two backends.  One would be the=20
interpreter, and the other would generate code.  We'd want the second=20
backend to take some sort of description language for how to actually=20
generate code.  We want it to be easy to add support for additional CPUs=20
/ GPUs.

> So get get something running I would first craete the
> GL_ARB_vertex_program frontend. Then the interpreting backend. If it's
> at least as fast as the solution we have now, we can already put it in
> Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend.

How is your proposal for ARB_vertex_program different from what's in=20
Mesa now?  I'm not that familiar with the existing implementation.

> Then we can take the new concept to the fragment shader side, where
> it should be rather easy to get GL_ARB_fragment_program and
> GL_ARB_fragment_shader support and get the interpreted and SSE backends
> running. Next would be the i915 backend, since the driver already
> supports fragment programs and it shouldn't be left behind.
>=20
> Then when someone uses the fragment shader on let's say the i915 this
> will happen:
> If the i915 compiler says it can't handle the program (due to lack of
> hardware support for some advanced functionality) the SSE backend
> with software rendeirng will be used if it's on x86. Otherwise the
> generic, interpreting backend will be used.

Right.  Basically like the existing fallback mechanism for the=20
fixed-function pipeline.

> 
> How is your proposal for ARB_vertex_program different from what's in 
> Mesa now?  I'm not that familiar with the existing implementation.
> 

The existing implementation is an interpreter very closely tied
to the GL_ARB_vertex_program syntax.

My proposal would allow the compiler to perform optimizations
and integrate vertex programs with vertex shaders.

I don't think we can use the current internal representation of
vertex programs as the new intermediate language since vertex shaders
need lots of additional features:
-data types other than vec4 (we now have vectors, matrices, scalars of
types float, int and boolean).
-Function calls
-Possibility to link shaders.


Philipp

On Thu, Sep 09, 2004 at 05:03:27PM +0200, Philipp Klaus Krause wrote:
> Brian Paul schrieb:
> >Pasi K=E4rkk=E4inen wrote:
> >
> >>Hi all!
> >>
> >>>From the http://www.opengl.org:
> >>
> >>
> >>OpenGL 2.0 specification available for download
> >>
> >>http://www.opengl.org/documentation/opengl_current_version.html
> >>http://www.opengl.org/documentation/specs/version2.0/glspec20.pdf
> >>
> >>Any plans for 2.0 support in Mesa? I think the biggest "todo" is the
> >>sw-emulation of glsl?
> >
> >
> >Yeah, implementing the shading language will be a huge project.  It=20
> >would be nice if a group of volunteers would work together to implemen=
t it.
> >
> >I'll probably start working on some of the infrastructure for 2.0=20
> >support in the near future.  But the GLSL parser and code generator wi=
ll=20
> >be the bulk of the 2.0 work by far.
> >
> >-Brian
> >
>=20
> Some modifications to Mesa are necessary:
> -Change glColor3 behaviour,
> -Seperate legacy and generic vertex attributes.
>  GL_NV_vertex_program, GL_NV_vertex_program1_1 and GL_NV_vertex_program=
2
>  needs attribute aliasing. GL_ARB_vertex_program, GL_NV_vertex_program3
>  allow it. GL_ARB_vertex_shader sas that even for GL_ARB_vertex_program
>  (assuming both extensions present) there may be no attribute aliasing.
> -I dont' know about GL_ARB_texture_non_power_of_two and
>  GL_ARB_draw_buffers. Are they supported already?
> -The rest should be there.
>=20
> I planned to do some work towards shader support, but wanted to wait fo=
r
> The 2.0 spec to be released to see what would change. I probably won't
> find much time before mid-october or so. This is what I had in mind:
>=20
> Frontends for GL_ARB_vertex_program and GL_ARB_vertex_shader,
> GL_ARB_fragment_program and GL_ARB_fragment_shader that create some
> intermediate representation.
> Then, at least four backends: One for SSE to get fast software
> rendering on newer x86, one that interpretes for the architectures wher=
e
> there is no compiling backend, one for the new intel chips and their
> fragment program support and finally, one for the Wildcat VP
> (I don't have docs for it though and doubt that I will ever get any,
> I haven't asked Intel about i915 yet).
>=20
> So get get something running I would first craete the
> GL_ARB_vertex_program frontend. Then the interpreting backend. If it's
> at least as fast as the solution we have now, we can already put it in
> Mesa. Next will be GL_ARB_vertex_shader frontend and SSE backend.
>=20

Hmm.. is it possible to use the frontend compiler which is available from
3dlabs website? Or does it help anything..=20

-- Pasi K=E4rkk=E4inen
      =20
                                   ^
                                .     .
                                 Linux
                              /    -    \
                             Choice.of.the
                           .Next.Generation.

Philipp Klaus Krause wrote:
> 
>>
>> How is your proposal for ARB_vertex_program different from what's in 
>> Mesa now?  I'm not that familiar with the existing implementation.
>>
> 
> The existing implementation is an interpreter very closely tied
> to the GL_ARB_vertex_program syntax.

Sure, because that (and GL_NV_vertex_program) is all we've needed to 
support so far.  Obviously, I couldn't predict what else would be 
needed for the shader extensions back then.


> My proposal would allow the compiler to perform optimizations
> and integrate vertex programs with vertex shaders.
> 
> I don't think we can use the current internal representation of
> vertex programs as the new intermediate language since vertex shaders
> need lots of additional features:
> -data types other than vec4 (we now have vectors, matrices, scalars of
> types float, int and boolean).
> -Function calls
> -Possibility to link shaders.

I'll have to look at the details, but I was hoping the current 
codebase could be extended to support those things, rather than 
throwing it all away and starting over.

-Brian

> > How is your proposal for ARB_vertex_program different from what's in 
> > Mesa now?  I'm not that familiar with the existing implementation.
> > 
> 
> The existing implementation is an interpreter very closely tied
> to the GL_ARB_vertex_program syntax.
> 
> My proposal would allow the compiler to perform optimizations
> and integrate vertex programs with vertex shaders.

Michal Krol was talking about some GLslang work back around the beginning 
of the year.. It may be that the wheel doesn't need to be 
completly reinvented...

Karl