Originally Posted by bridgman
My understanding was that Gallium3D/pipe/winsys acted as a library you could statically link into "any" driver, and compatibility with kernel (and maybe X) would be a function of the winsys code that was used. Mesa is just one essays example of a driver that can be built over Gallium3D, and multiple Gallium3D-based drivers should be able to co-exist assuming they each performed different functions (so you don't get two libGL implementations fighting, for example).
Mesa compatibility shouldn't be an issue unless there was some kind of "hardware programming philosopy break", where (for example) a new version of Mesa programmed some registers in a new way that the other driver didn't (re)program, ie if the other driver made assumptions about hardware state based on the way Mesa happened to leave it.
Take this with the usual grain of salt.
My understanding was that Gallium3D/pipe/winsys acted as a library you could statically link into "any" driver, and compatibility with kernel (and maybe X) would be a function of the winsys code that was used. Mesa is just one essays example of a driver that can be built over Gallium3D, and multiple Gallium3D-based drivers should be able to co-exist assuming they each performed different functions (so you don't get two libGL implementations fighting, for example).
Mesa compatibility shouldn't be an issue unless there was some kind of "hardware programming philosopy break", where (for example) a new version of Mesa programmed some registers in a new way that the other driver didn't (re)program, ie if the other driver made assumptions about hardware state based on the way Mesa happened to leave it.
Take this with the usual grain of salt.
Leave a comment: