The hard part is adding the pipelines to mesa to talk to the hardware. This is where the DRI
Hell magic comes in.
GCC2 will never have hardware acceleration... the version of Mesa that will build on gcc2 is really outdated and Mesa has 0 interest in supporting gcc2 in modern code (and I don't blame them)
I was writing a "hardware rendering pipeline" wrapper once upon a time that can talk to any hardware device (DRI, Haiku, etc) but haven't done much to it lately. You would have to talk the mesa developers into supporting it which would be a hard sell... they really like DRI even though it is very linux centric. (They say it's cross platform, but it requires a lot of X-centric stuff... DRI3 was supposed to fix a lot of the Xorg dependencies)
Under Linux. Build under Haiku and it automatically adjusts to the Haiku accelerant interface.
kallisti5@avongluck01:~/Code$ cd librendomatic/
docs include mkdocs.yml README.md run_tests SConstruct src tests
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
gcc -o src/backend/dri/bo.o -c -g -g -Iinclude -Isrc -Isrc/backend -Isrc/backend/dri -I/usr/include/libdrm src/backend/dri/bo.c
gcc -o src/backend/dri/entry.o -c -g -g -Iinclude -Isrc -Isrc/backend -Isrc/backend/dri -I/usr/include/libdrm src/backend/dri/entry.c
src/backend/dri/entry.c: In function ‘base_device’:
src/backend/dri/entry.c:169:6: warning: #warning DRI: TODO: Get card base address! [-Wcpp]
#warning DRI: TODO: Get card base address!
gcc -o src/bufferobject.o -c -g -g -Iinclude -Isrc -Isrc/backend -Isrc/backend/dri -I/usr/include/libdrm src/bufferobject.c
gcc -o src/util.o -c -g -g -Iinclude -Isrc -Isrc/backend -Isrc/backend/dri -I/usr/include/libdrm src/util.c
gcc -o src/rendomatic.o -c -g -g -Iinclude -Isrc -Isrc/backend -Isrc/backend/dri -I/usr/include/libdrm src/rendomatic.c
ar rc src/librendomatic.a src/bufferobject.o src/util.o src/rendomatic.o src/backend/dri/entry.o src/backend/dri/bo.o
gcc -o tests/devicebo.o -c -g -g -Iinclude -Isrc -Isrc/backend -I/usr/include/libdrm tests/devicebo.c
gcc -o tests/devicebo tests/devicebo.o -Lsrc -ldrm -lrendomatic
gcc -o tests/deviceopen.o -c -g -g -Iinclude -Isrc -Isrc/backend -I/usr/include/libdrm tests/deviceopen.c
gcc -o tests/deviceopen tests/deviceopen.o -Lsrc -ldrm -lrendomatic
scons: done building targets.
librendomatic-trace: Using DRI backend.
librendomatic-trace: open_device: Found card /dev/dri/card1
librendomatic-trace: open_device: Found card /dev/dri/card0
librendomatic-trace: connect_device: authenticated to DRI2
librendomatic-trace: connect_device: info: nouveau, nVidia Riva/TNT/GeForce/Quadro/Tesla, 20120801
librendomatic-info: context initialization successful.
librendomatic-info: context destruction successful.
Implementing DRI wrapper code within the accelerant would be the easier sell to the Mesa developers and a lot less stress... the DRI2 api's are pretty horrible though.
In theory we could eliminate the DRI2 card-centric code and put it into the accelerant. Then just point Mesa at each card device in /dev/graphics/*
Lots, and lots of work to do.. and so little time.
Start with improving / fixing up llvm softpipe rendering under Haiku... the latest Mesa code doesn't work so well under Haiku anymore and needs some minor patching. Mesa developers are always changing what arguments functions take, and since they use pointers to functions for eveything it creates a lot of code that "compiles but crashes when used"