> It falls back gracefully though (I think TTM did as well, though this API is > smaller in that it doesn't pass a huge gob of flags around), so if we think > the libdrm bufmgr interface is stable there should be no problem.
The problem is I am not that happy that the bufmgr interface is stable, its been changed quite a bit during GEM dev, and I forsee more changes to it to support other users... You missed the point it fails back gracefully at *runtime*, and if we do end up with a slight change to the interface in the kernel later we have code that could wait in hiding for the bits to be enabled in the kernel. > Don't we keep saying "libdrm is the interface" these days anyway? So if that > part is sane we should just release what's in libdrm master now or soon. But > maybe I'm forgetting (ignorance is bliss) some aspect of the pain we had with > TTM... for instance there are two direct GEM ioctls in the intel mesa code, libdrm currently publishes files it shouldn't, the plan is to build libdrm against kernel published files, however these files aren't in the kernel so I can release a libdrm against them. As I said on irc, you build a house (even a house of cards) from the bottom, doing it in reverse is not a good plan. There is no point having released userspace bits with no kernel to support them. So there will not be a libdrm release with any of this stuff in it before the upstream bits are in the kernel. We tried that with TTM, and we had lots of pain. Dave. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
