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
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel