1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Marek Files Patches For Floating-Point In Mesa Master

Free Software

Published on 01 April 2011 01:10 PM EDT
Written by Michael Larabel in Free Software
27 Comments

Forget about the fun being had today on April Fools' Day with openSUSE / Gentoo / Arch / Debian supposedly merging to form the Centerbury Linux distribution, GNOME 3.0 being delayed until September, or hypothetical Linux disasters as there is actually some serious and important news: Marek Olšák has published his patch-set he wishes to push into Mesa master for OpenGL 3.0 floating-point textures and render-buffers support. He's pushing for this legally-iffy code to go into the mainline Mesa code-base but to block it by an opt-in --enable-texture-float build flag.

Marek Olšák, the well known community developer who's made significant contributions to Mesa / Gallium3D itself and particularly the open-source ATI drivers, has just published a set of six patches to the Mesa mailing list. "This patch series adds the last pieces of ARB_texture_float support to Mesa and Gallium."

Here's the main part of the message:
The thing is Mesa and Gallium more or less already support float textures and renderbuffers in master. Gallium has full floating-point support in the interface and if it was a public API, people could just expose it and not care. There is clearly a need for a configure switch which can hide float renderbuffers from any interface, public or private, and driver developers should use such a switch.

So ARB_texture_float is mostly implemented in master. What's missing is the A/L/LA/I formats in Gallium, and the R/RG formats in the Mesa core, and some glue between Mesa and st/mesa.

I am proposing to merge all these patches and advertise ARB_texture_float if --enable-texture-float is used in configure.sh/autogen.sh. This is the same strategy the FreeType project had. If Linux distributors want ARB_texture_float (e.g. to get OpenGL 3), they should obtain the patent or find any other legal way around it, and then use the configure switch, but it's their and only their problem, not ours. By default, ARB_texture_float is disabled, so the Linux distributors not willing to support ARB_texture_float don't need to care.

BTW, this is not April Fools' prank.

It was in the beginning of March when Lucas Stach proposed merging Marek's floating-point/render-buffer branch to mainline Mesa and to conceal it behind a --enable-patented build option to move the legal burden from the Mesa developers and onto the distribution vendors and those compiling the code and distributing the binary packages.

There was interest in merging the work, but ultimately it didn't happen. This also then brought another proposal of merging the S3TC support to Mesa and hiding it behind a similar build switch. The difference though between the S3TC and floating-point / render-buffer work is that the the S3 Texture Compression work can live relatively cleanly in an external library that's dynamically loaded by Mesa. The floating-point / render-buffer work does much better living directly within the core.

While it didn't get merged then, Marek himself is now bringing the matter to the mailing list himself and showing the six patches in particular that would need to be merged rather than just trying to pull his floating branch.

Hopefully now we will see GL_ARB_texture_float merged to master, albeit it will be disabled by default. This would be another step forward with Mesa / Gallium3D finally catching up to the latest OpenGL 3.x/4.x specifications. As far as what this means, with the very latest Mesa 7.11-devel / Gallium 0.4 development Git code and floating-point support enabled, Unigine Heaven can now run on Gallium3D. This impressive technology demo may now function, but how it performance is still less than desirable.

Latest Linux Hardware Reviews
  1. Overclocking The AMD AM1 Athlon & Sempron APUs
  2. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  3. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
  4. AMD Athlon 5350 APU On Linux
Latest Linux Articles
  1. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  2. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  3. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
  4. DDR3 Memory Scaling Performance With AMD's Athlon 5350
Latest Linux News
  1. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  2. Red Hat Releases Its RHEL 7 Release Candidate
  3. New Features Coming To Xubuntu 14.04 LTS
  4. NVIDIA Officially Releases CUDA 6
  5. Google Releases An AutoFDO Converter For Perf In LLVM
  6. Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation
  7. Star Citizen Will Be Coming To Linux
  8. Ubuntu 14.10 Convergence To Focus On Replacing Core Apps
  9. The Results Of Optimizing Radeon's VRAM Behavior
  10. Kernel Developers Discuss Improving Kernel Configurations
  11. Apple, LLVM Developers Figure Out Their 64-Bit ARM Approach
  12. NVIDIA GeForce GTX 750 Maxwell GPUs Light Up On Linux 3.15
Latest Forum Discussions
  1. The GNOME Foundation Is Running Short On Money
  2. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  3. Bye bye BSD, Hello Linux: A Sys Admin's Story
  4. New tool for undervolt/overclock AMD K8L and K10 processors
  5. How to enable opengl 3.3 on r9 270?
  6. R290x sound problems
  7. radeon-profile: tool for changing profiles and monitoring some GPU parameters
  8. Torvalds Is Unconvinced By LTO'ing A Linux Kernel