LLVMpipe Driver Can Almost Do OpenGL 3.0~3.1
With the arrival of sRGB frame-buffers support, the Gallium3D LLVMpipe software driver is nearly ready to advertise OpenGL 3.0 support and OpenGL 3.1 is also attainable.
As covered earlier today, most of Mesa/Gallium3D is nearing OpenGL 3.2~3.3 compliance. However, besides the RadeonSI Gallium3D driver, LLVMpipe has also been living in an OpenGL 2.1 era.
While LLVMpipe is software-based and leverages LLVM without any GPU hardware requirements, it hasn't yet seen OpenGL 3.x support. LLVMpipe just doesn't receive the same level of attention and development work as the Intel/Radeon/Nouveau drivers even though it's increasingly used as the software fallback method for modern Linux desktops.
Roland Scheidegger of VMware committed sRGB frame-buffers support for the driver on Monday to mainline Mesa with this commit. "Just use the new conversion functions to do the work. The way it's plugged in into the blend code is quite hacktastic but follows all the same hacks as used by packed float format already. Only support 4x8bit srgb formats (rgba/rgbx plus swizzle), 24bit formats never worked anyway in the blend code and are thus disabled, and I don't think anyone is interested in L8/L8A8. Would need even more hacks otherwise."
The ARB_framebuffer_sRGB OpenGL extension provides support for sRGB frame-buffer updating and blending over OpenGL's traditional assumptions of frame-buffer color components being in a linear color-space. With LLVMpipe now meeting the sRGB frame-buffers requirement, the only major item apparently left for this driver is multi-sample anti-aliasing (MSAA) support before it reaches OpenGL 3.0 compliance. Roland also notes that there's nothing else holding it back from OpenGL 3.1 compliance once MSAA is in place.
It's good to see LLVMpipe finally getting close to residing in a GL3 world. The LLVMpipe performance is also much better in the upcoming Mesa 9.2 release.
As covered earlier today, most of Mesa/Gallium3D is nearing OpenGL 3.2~3.3 compliance. However, besides the RadeonSI Gallium3D driver, LLVMpipe has also been living in an OpenGL 2.1 era.
While LLVMpipe is software-based and leverages LLVM without any GPU hardware requirements, it hasn't yet seen OpenGL 3.x support. LLVMpipe just doesn't receive the same level of attention and development work as the Intel/Radeon/Nouveau drivers even though it's increasingly used as the software fallback method for modern Linux desktops.
Roland Scheidegger of VMware committed sRGB frame-buffers support for the driver on Monday to mainline Mesa with this commit. "Just use the new conversion functions to do the work. The way it's plugged in into the blend code is quite hacktastic but follows all the same hacks as used by packed float format already. Only support 4x8bit srgb formats (rgba/rgbx plus swizzle), 24bit formats never worked anyway in the blend code and are thus disabled, and I don't think anyone is interested in L8/L8A8. Would need even more hacks otherwise."
The ARB_framebuffer_sRGB OpenGL extension provides support for sRGB frame-buffer updating and blending over OpenGL's traditional assumptions of frame-buffer color components being in a linear color-space. With LLVMpipe now meeting the sRGB frame-buffers requirement, the only major item apparently left for this driver is multi-sample anti-aliasing (MSAA) support before it reaches OpenGL 3.0 compliance. Roland also notes that there's nothing else holding it back from OpenGL 3.1 compliance once MSAA is in place.
It's good to see LLVMpipe finally getting close to residing in a GL3 world. The LLVMpipe performance is also much better in the upcoming Mesa 9.2 release.
Add A Comment