Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download

[Philipp K. K. <pk...@sp...>]

Brian Paul schrieb:
> Pasi Kärkkäinen wrote:
> 
>> Hi all!
>>
>>> From the 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