XDS 2008: GLSL, Radeon, Graphics Testing
This morning Tungsten Graphics was speaking at XDS 2008 about the status of Gallium3D. However, the rest of the day is filled with a variety of other OpenGL and graphics related talks. Intel's Gordon Jin had talked about Intel's community testing process, Jerome Glisse had talked about a few aspects of the open-source Radeon drivers, and Ian Romanick just gave a talk on GLSL (GL Shading Language).
Intel Graphics Testing:
- AutoBuildAutoTest - Intel's suite for building from source the driver components and running its tests.
- Call for increased quality of bug reports.
- Intel wants more community testers. Intel community team created to have test coverage for their old hardware.
Radeon:
- R100-200: No Gallium support planned and limited development restricted to kernel mode-setting and memory management.
- R300-400: Gallium, Vertex shader, pixel shader, memory management, and kernel mode-setting planned.
- R500: Vertex shader, pixel shader, support loop with limited depth, kernel mode-setting through AtomBIOS, memory management, and power management.
- R600/700: Unified pixel/vertex shader, complex, drawing triangle, power management is critical.
- R500 3D support should be the same as the R300/400 support.
- Command Submission is easier with modern ATI hardware where it takes a hardware formatted stream that can be sent directly to the hardware.
- Producing hardware shader code from a high-level shading language like GLSL is one of their biggest tasks ahead.
- Kernel mode-setting for R100 to R400 was ported from their DDX code and for the R500 series and lter it's using the new AtomBIOS parser.
- The ATI support will use the GEM API but underlying code will be powered by TTM.
GLSL:
- Language extensions allow many language intrinsics to be written in GLSL: __constructor, _operator, __asm.
- GLSL 1.30 support not even started.
- Really Bad State: one-off parser generator, linker can't support multiple compilation units on the same shader target, ARB_fragment_program is the IR.
- Desired infrastructure: sensible parser infrastructure, back-end independent IR, parser re-written using flex and bison.
- Language features they want: A compliant linker, real integer support, and full GLSL 1.20 and 1.30 support.
- Other features needed: geometry shader support, code-generator generator.
- Assembly shaders to MIR (modeled after GCC).
- Current GLSL infrastructure will continue on for at least a year.
There wasn't anything pertinent shared during the Intel graphics talk and much of the Radeon information isn't new if you're a faithful Phoronix reader staying up to date with the latest news, but the GLSL talk had shed some new light on Ian's (and Intel's) plans for GLSL within Mesa. Quite a few improvements for GLSL are planned including support for GLSL 1.30, which came as part of OpenGL 3.0.
Intel Graphics Testing:
- AutoBuildAutoTest - Intel's suite for building from source the driver components and running its tests.
- Call for increased quality of bug reports.
- Intel wants more community testers. Intel community team created to have test coverage for their old hardware.
Radeon:
- R100-200: No Gallium support planned and limited development restricted to kernel mode-setting and memory management.
- R300-400: Gallium, Vertex shader, pixel shader, memory management, and kernel mode-setting planned.
- R500: Vertex shader, pixel shader, support loop with limited depth, kernel mode-setting through AtomBIOS, memory management, and power management.
- R600/700: Unified pixel/vertex shader, complex, drawing triangle, power management is critical.
- R500 3D support should be the same as the R300/400 support.
- Command Submission is easier with modern ATI hardware where it takes a hardware formatted stream that can be sent directly to the hardware.
- Producing hardware shader code from a high-level shading language like GLSL is one of their biggest tasks ahead.
- Kernel mode-setting for R100 to R400 was ported from their DDX code and for the R500 series and lter it's using the new AtomBIOS parser.
- The ATI support will use the GEM API but underlying code will be powered by TTM.
GLSL:
- Language extensions allow many language intrinsics to be written in GLSL: __constructor, _operator, __asm.
- GLSL 1.30 support not even started.
- Really Bad State: one-off parser generator, linker can't support multiple compilation units on the same shader target, ARB_fragment_program is the IR.
- Desired infrastructure: sensible parser infrastructure, back-end independent IR, parser re-written using flex and bison.
- Language features they want: A compliant linker, real integer support, and full GLSL 1.20 and 1.30 support.
- Other features needed: geometry shader support, code-generator generator.
- Assembly shaders to MIR (modeled after GCC).
- Current GLSL infrastructure will continue on for at least a year.
There wasn't anything pertinent shared during the Intel graphics talk and much of the Radeon information isn't new if you're a faithful Phoronix reader staying up to date with the latest news, but the GLSL talk had shed some new light on Ian's (and Intel's) plans for GLSL within Mesa. Quite a few improvements for GLSL are planned including support for GLSL 1.30, which came as part of OpenGL 3.0.
7 Comments