AMD R600g Now Does TBO, UBO & Advertises GLSL 1.40
Phoronix: AMD R600g Now Does TBO, UBO & Advertises GLSL 1.40
Last year UBO and TBO for the Radeon R600 Gallium3D driver was talked about and early patches proposed, but merged on Friday was finally this support for Uniform Buffer Objects and Texture Buffer Objects. With the OpenGL UBO/TBO support, the Radeon R600g driver is now advertising GLSL 1.40 as needed for OpenGL 3.1 compliance...
Wow. I just looked at the TODO list: http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt
It looks like GLSL 1.5 is the last big hurdle for full OpenGL 3.3 compliance.
Good work, mesa devs!
You forgot Geometry shaders. That's the really big problem as AFAIK no further progress anymore (GLSL gets love from Intel OTC).
Originally Posted by DanL
Lets hope it and Clover gets hammered out and commited fast so that this fall's distro update cycle can have full OpenGL 3.3 and OpenCL 1.2 support activated by default in the OSS drivers.
Originally Posted by zxy_thf
Then onward to OpenGL 4 glory!
Problem loading the driver
Does anyone have this problem with these latest commits:
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri/r600_dri.so
libGL error: dlopen /usr/lib/xorg/modules/dri/r600_dri.so failed (/usr/lib/xorg/modules/dri/r600_dri.so: undefined symbol: _ZTVN10__cxxabiv120__si_class_type_infoE)
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
There is a tree on github with unproven geometry shader code for r600g, intel would need to add 965 support, it just needs a lot of piglit tests and a lot of review, the last missing bit then is GL_ARB_texture_multisample which is also under construction by another dev for 965, which could be fixed up for gallium fairly easily hopefully.
Originally Posted by zxy_thf
but writing the piglit tests for geometry shaders is probably the biggest problem.
It's interesting that OpenGL 3.3 is ready, according http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt. Does that mean when GL 3.2 gets done we automatically have and GL 3.3?
yeah pretty much.
Originally Posted by pejakm
Although there are no piglit tests for it yet, my geometry shader code on GitHub has had a decent amount of stress-testing; I'm not too concerned about an abundance of bugs in the existing code. Aside from piglit tests (which are, as you say, the biggest problem), though, there are a few other things that need to be done:
Originally Posted by airlied
- The changes will need to be rebased and reformatted into a sane patch set rather than the current haphazard mix of commits that add functionality with commits to fix mistakes in previous changes.
- The interactions with FBOs (section "Dependencies on EXT_framebuffer_object" in the ARB_geometry_shader4 spec) need to be implemented. This might only be needed for the EXT/ARB extensions and not core, but with this much work done on the extensions it would be silly not to support them as well as the core version. It seems that doing this properly will also require changes to the softpipe driver.
- If it hasn't already been done, the GLSL compiler will need to implement the core version of the geometry shader language. The main change is using the "gl_in" struct array for input/output instead of one input array per attribute. This will just require a lowering pass to lower gl_PerVertex accesses to the 2D array accesses used in the extension, which can be (and already are) sanely translated to TGSI by glsl_to_tgsi.
Also, sorry for suddenly disappearing from the graphics world last year. Hopefully I will be able to be able to do more for Mesa in the future, but for now there's not much choice but to leave my unfinished geometry shader work to be completed by someone else.
Tags for this Thread