On Fri, Jul 19 2019, Charlene Wendling <juliana...@posteo.jp> wrote: > On Thu, 18 Jul 2019 23:13:14 -0600 > Thomas Frohwein wrote: > >> Thanks, I appreciate that you found the fix for it! I'm traveling >> currently and can commit the change only on Sunday.
Well, Charlene wrote the diff and can commit it. :) >> I'm not sure if this should really be built if there is truly no >> hardware that's compatible... The alternative would excluding PPC and >> maybe a few other arches that are known to not work with any >> compatible hardware. > > Well, there are 2 problems in fact: > > - the one i address here is for all base-gcc archs, not macppc only > - but in fact most of these archs have no vulkan capable video cards > > As far as macppc is concerned, all G4 system are AGP-based so no amdgpu > for them, hence no vulkan. > > Some G5 ones have PCI-Express and the best upgrade official upgrade you > could get is a Radeon X1900 that doesn't as well. I'm not sure more > modern third party cards are available. > > CC'ing Jeremie and Kurt, as i don't know how sparc64 is doing in this > regard. > > I guess it should be only for x86* and arm* in the end. Consumers should be taken into account. I can imagine some ports using vulkan-loader unconditionally at build time, try to use it at runtime and fallback on another backend if vulkan-loader doesn't work. If you use NOT_FOR_ARCHS in vulkan-loader, said ports won't even get a chance to build even though runtime might be ok. Those are only guesses. There are no such ports right now; vkquake supposedly has a hard requirement on vulkan-loader. But such ports might pop up in the future, so I'd prefer vulkan-loader to be available on all arches. ok jca@ for the COMPILER line, I'm not sure the "Thread Local Storage" comment makes sense since you're not only addressing a TLS problem. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
