On Tue, Feb 09, 2021 at 01:47:37PM +0000, Laurence Tratt wrote: > On Tue, Feb 09, 2021 at 10:57:32PM +1100, Jonathan Gray wrote: > > Hello Jonathan, > > > See previous libva discussions. If it is to support more than just Intel > > it needs to be in xenocara and new Mesa Makefiles will need to be written. > > > > That would also be the case to use gallium-va with the iris Mesa driver for > > Intel >= gen8. > > I'm not aware of the previous discussions, but I'm not sure if you're saying > "don't put it in ports" or not?
Yes. On AMD graphics (and I guess Intel >= gen8) Mesa needs to be linked with libva, and Mesa is a part of xenocara. Building the base system does not depend on ports. > Even if it means that *only* Intel hardware benefits for the time being, this > port is really very useful and I've been working with Eugene to test his > work. Now that I've got it up and running, it's pretty impressive: for > example, on my OpenBSD machine, ffmpeg video encoding on a test file went > from 6m30 down to 2m20 (also, not coincidentally, moving from fully consuming > all 4 cores at to consuming only a small portion of 1 core). It's certainly something that would be nice to have, and has been attempted a few times. Someone just needs to pick up the work that has been started by others. The original ports discussions: https://marc.info/?t=157626475700001&r=1&w=2 https://marc.info/?t=157587390400001&r=1&w=2 ..when it moved to tech@ to attempt xenocara integration: https://marc.info/?t=157676538600003&r=1&w=2 > If nothing else, support in ports might be a useful stepping stone on the way > to having libva in xenocara which, I imagine, is a rather harder job? > > Laurie Putting something into ports knowing that it's the wrong place feels wrong, and will undoubtedly cause friction later when moved to base. -Bryan.
