Hi, On Thursday, September 12, 2013 08:41:10 Christian König wrote: > I completely agree. > > Building everything shared might speed up the build process a little bit > and save some space, but for the cost of having to handle allot of > rather small shared libraries where which each clashing the symbol space > of any application using these drivers with a bunch of unnecessary symbols. > > Building everything as one big blob sounds like the better idea. +1.
Symbol clashes with libraries used in drivers are a huge problem for applications that either ship with their own version/variant of this kind of library and do not expect to have a second one injected by the side effect of a user space driver or in case of LLVM just because of this not being reliably thread safe. If your driver knows the version and instance of llvm it has linked with, because it's its own internal one technically hidden from all other potential users we will see less unwanted side effects. To get this symbol clash problem right, there could be an other solution I have been playing with which is loading the drivers with RTLD_DEEPBIND. I am running with patches for this already for a long time here but I never found the time to test this for side effects on OpenCL use. The problem that still needs to be investigated there is that you want to share buffer objects between OpenCL and OpenGL and for that you work you might(?) need a single instance of libdrm in the application. Also this dlopen flag is not part of the standard that covers dlopen and thus not avaiable everywhere. What problem do you want to solve exactly with this shared library split? If you care for memory use of the running application, you will need to have the driver binary loaded including all its code. Having a big blob without any relocs in between increases the probability that you can reuse read only pages for the code segments to be shared between applications. Note that the RTLD_DEEPBIND variant above uses even more memory in the running application since each dlopened driver gets it's own private set of mapped shared objects. If you care about on disc use which might be interresting for small embedded like machines, is it possible to split the drivers rpm into seperate pieces per driver? That way an embedded system integrator could potentially install them individually based on the available hardware for such a specific case? Greetings Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev