OpenGL 2.0 specification available for download
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? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: OpenGL 2.0 specification available for download
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 --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47alloc_id808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
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 --- 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
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
Philipp Klaus Krause wrote: 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. 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 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. Well, I'd consider the current internal representation of vertex/fragment programs to act as an intermediate representation that can be translated into hardware/SSE/etc forms. That's what Keith did 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 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. This generally sounds good. Before anyone starts tearing up the 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 vertex/fragment programs before anything else. -Brian --- 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
Re: [Mesa3d-dev] Re: OpenGL 2.0 specification available for download
On Thu, Sep 09, 2004 at 05:03:27PM +0200, Philipp Klaus Krause wrote: 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. Hmm.. is it possible to use the frontend compiler which is available from 3dlabs website? Or does it help anything.. -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- 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
