James Jones

@jekstrand Take a look at the descriptor set idea in the current header if you haven't yet. I'm curious whether that helps bridge the gap between the larger capability structure...

@jekstrand Agreed. And in fact, I censured myself when writing up the header. Currently it's called a "capability set", and I just realized it's missing the list of constraints I...

Though it took me about 3 long iterations to get the logic for capability intersection to a reasonable place, with the current (untested) intersection logic I've managed to convince myself...

If we go with the json-style backend description files GLVND and Vulkan are using, we could ask vendors to include some vendor->backend filename mapping in the json file. However, I...

If the libraries loaded are based on those the capabilities require, then you have a chicken-and-egg problem: At least one instance of the allocator would have had to load some...

FWIW, right now the prototype loads backends like GLVND+EGL and libvulkan do based on json config files. When it gets a device file as proposed in USAGE.md, it asks each...

@jekstrand You're saying you want caps/constraint querying done only through GL/Vulkan/etc., not through the allocation API itself? I don't think that's feasible. The vendors who write only a display device...

@robclark Yeah, LUID/UUID is just a strawman. I like it for another reason though, in that I want to correlate devices in liballoc (or whatever) with devices in other APIs...

@robclark No, probably not generally. It would be nice if all drivers could export enough info in sysfs/procfs to trivially populate caps/constraints in userspace, but I doubt they all do....

This gets into some topics I had hoped to postpone, but I do have some thoughts. Allocating the surfaces is just the first step towards solving the set of problems...