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