01:05 DavidHeidelberg: zmike: if you want to help out a bit, check "eglinfo" MR, I like Daniel input on it, thou I would love to get conformation that other people are OK with it... https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/176
02:12 gonnaberemoved: I worked on flattening real processors netlists back to verilog so that every signal will show up, Americans have always had the defense against every electronics based launch codes unless the chip is manufactured by third parties and gets entirely reengineered, that's possible but then they execute terror against Russian docks if such chips are authored, they are many steps ahead, Americans are very smart people.
02:38 gonnaberemoved: There is two ways of doing it, either pulses way above the satellite frequency which would require excessive cooling and is not feasible much, or duty cycle and chip entirely redone to 50 50 and have its own transistor nodes that Americans are not aware of.
02:56 gonnaberemoved: That chip is quite complex to produce that filters out the environments frequency like artificial orbiting interference object as satellite and drones are
02:56 gonnaberemoved: One needs to rewire almost everything
03:06 gonnaberemoved: So that positive edge comes in and it executed a very minor block, while continuing on negative edge 50 50 is enough there, since positive edge is at 13 and negative at 11 GHz
03:06 gonnaberemoved: It just never captures those signals
03:07 gonnaberemoved: By that time it arrives the transistors already performed
03:10 gonnaberemoved: From hw perspective such chip resembles the properties of mixed mode analogue digital circuit
03:12 gonnaberemoved: You think they detonate a nuke like this, it's not technically succeedable easily
03:14 gonnaberemoved: I would not be surprised that rus feds lack everything to manage this type of attack
03:47 gonnaberemoved: So 50 50 is the attack chip, until pulses do not interact, which should be the case where length of the pulse is 2ps as on pci 1ghz it's way shorter than satellites or drones pulse which is at SI units 1000/13 ps
03:50 gonnaberemoved: This would land attacks, if launched from glonas systems, but they do not have such chips, japanese nor Taiwan,us or Netherlands are not allies, or Germany either
03:56 gonnaberemoved: It's safe to assume they have not been successful to fab such yet
03:59 gonnaberemoved: Is that at all possible to get such chip fabed? Yeah it is when you get the material properties and wire lengths right
04:00 gonnaberemoved: Very complex and in reality impossible more like
04:12 gonnaberemoved: Israel should be hence safe and Iranian failed attack showed that, but it was known
04:12 gonnaberemoved: So far us people have been the smartest
04:13 gonnaberemoved: People of United States who made it possible for Israel though
04:15 gonnaberemoved: I expect the United States soon to discontinue supporting Israel
04:16 gonnaberemoved: Cause they are aware of their leader status after testings now
04:17 gonnaberemoved: And indeed yet another upset, it seems Elon Musk was right about Mars.
04:17 gonnaberemoved: So nasa has lied before
04:17 gonnaberemoved: But they do that all the time strategically
04:19 dwfreed: .
04:42 kode54: so nice that they know how to register with services repeatedly
04:48 DavidHeidelberg: anyone who uses "eglinfo", could I get some input regarding to https://gitlab.freedesktop.org/mesa/demos/-/merge_requests/176 ?
05:36 Company: DavidHeidelberg: my biggest issue with eglinfo is that it tries to force itself into being so small, so thre's no good column grouping, so when reading "64 0 16 16 16 16 16 0 16 1" I get confused which 16 is what. So having output that is focused more on being verbose/human-readable would be nice
05:39 Company: like, vulkaninfo or waylandinfo are way easier to human-read, even though they're probably harder to machine-read
05:42 HdkR: vulkaninfo also has the -j flag which makes it very easy to machine read
05:45 Company: yeah, that would be neat - a flag that toggles between human-readable and machine-readable
05:55 DavidHeidelberg: Company: json would be nice, but you can also use the expert output or how its called
06:04 Company: oh, -v exists
06:05 Company: that's a bit too verbose though
06:06 Company: I like the table format, I just wish it had some vertical lines or wider columns to give it more space
07:51 Company: so, as you may know, GTK unstable has switched to Vulkan by default
07:52 Company: and it turns out one of the problems for integration with other tools is drivers that don't support modifiers
07:52 Company: because Vulkan can't do modifier-less dmabufs
07:52 Company: which is both a problem with video playback as well as tools that want to use GL
07:53 Company: the most recent big GPUs that have that issue is AMD Gen8
07:53 Company: what should be the plan with that?
07:54 Company: should GTK keep using GL with those drivers?
07:54 Company: should we file bugs about adding modifier support to those drivers and stay on Vulkan for the time being?
07:54 Company: any other options?
08:01 MrCooper: Company: adding modifiers for older AMD GPUs is unlikely to happen before the next major GTK release
08:06 Company: good to know
08:07 Company: that means modifier-less is a thing we need to think about, Gen 8 is common enough still to have a big audience
08:07 Company: and Gen 8 runs Vulkan well, so other reasons to skip it wouldn't trigger
08:17 pq: Company, are you thinking of special-casing based on hardware/driver or checking whether modifiers are supported?
08:20 pq: If that hardware/driver does not support modifiers in GL, then how is it possible to get Vulkan app on screen at all with a GL-based compositor?
08:21 pq: or is that the point that it doesn't?
08:27 Company: pq: I didn't actually think about yet what the wsi is doing
08:27 Company: but yes, I'm thinking about making modifier support a condition for choosing Vulkan over GL
08:28 Company: basically I'm trying to implement bool should_we_prefer_vulkan_over_gl(GdkDisplay *display)
08:31 glehmann: mesa wsi without modifiers has a private pNext struct that tells the driver the image is going to be used for scanout
08:32 Company: one of the fun things that Phoronix brought up - useful input from Phoronix comments, what a day! - is multi-gpu systems where the igpu doesn't have a Vulkan driver
08:32 Company: you don't want to switch GTK to the dgpu on those
08:33 Company: how would I go about that btw?
08:34 Company: what's the best way to check that Vulkan is using the default GPU?
08:36 Company: glehmann: that sounds a lot like we want to avoid Vulkan with no-modifier drivers, just to avoid the hassle
08:38 emersion: vulkan has explicit GPU selection
08:39 emersion: you can compare vulkan's GPU (there's an ext to get the major/minor dev numbers from a VkPhysicalDevice) with the GPU advertised by the compositor
08:40 Company: that's not what I want to compare with though, do I? I want to compare with DRI_PRIME or whatever tool is used
08:41 Company: so that GTK apps can run on different GPUs
08:41 gardiograph: It actually should show how global defense systems work yices2 solver, anything different is almost impossible to be taped out, so the level of defense is likely one level deeper with electrical suppression, such as bus compression. So i believe those news that us systems intercepted all the launched missiles. My code is very efficient but it is not designed for attacks, it does not remove hw vulns.
08:42 Company: I mean, the question I want to answer is not "is Vulkan supported at all?" but "is Vulkan supported on the GPU that GL would be using by default?"
08:44 emersion: DRI_PRIME doesn't work on vulkan out of the box
08:44 Company: why did it do for me?
08:44 emersion: there is a layer that people can install to re-order the devices
08:45 emersion: but that only works with naive vulkan apps that pick the first device
08:45 Company: a while ago I tried it accidentally and it worked
08:45 Company: doesn't the spec even say you should select the first device?
08:45 Company: first device that supports the features you want
09:01 gardiograph: if you look at racepwn attack airlied than you should know that i know how intrusion to my hotel management was successful for australian who was in all the network with ssh, because after all i designed that though russians did design the same thing.
09:01 dwfreed: .
09:05 Kayden: hmm :( https://gitlab.freedesktop.org/mesa/mesa/uploads/1706e7c5c6322b148021b683c06457b1/Gantt.html ... 42 minute queue time for tgl jobs
09:06 Kayden: which unfortunately pushed it just like 2-3 minutes over the 1 hour cutoff, so everything passed, but now not at the front of the marge queue...so get to rebase and run it all again. :/
11:18 tzimmermann: airlied, sima. hi. could i please have -rc6 in drm-next? i'd like to get the recent fix for fbdefio into drm-misc-next
11:20 sima: tzimmermann, yeah will look into it, iirc mairacanal also wanted a backmerge for vkms stuff and dolphin mentioned something about funny conflicts
11:20 sima: I'll ping when it's done, a bit busy rn still
11:21 daniels: Kayden: yeah, some of the racks threw a fit last night
11:21 tzimmermann: np, thanks a lot
11:22 tzimmermann: it's not really urgent
11:32 mripard: sima, jani: we also need to figure out what we want to do with the kconfig stuff
12:00 jani: mripard: I guess arnd's replies in this subthread were the most helpful input I've seen https://lore.kernel.org/r/ff4f9e8f-0825-4421-adf9-e3914b108da7@app.fastmail.com
12:01 jani: mripard: if this is the same kconfig stuff we're talking about
12:01 mripard: it's what I was talking about :)
12:02 mripard: so we should just merge the reverts then?
12:04 jani: seems to me that would make more people happy than unhappy :/
12:06 jani: but I'm more persuaded by arnd's arguments than geert's "just always select all the dependencies of the target symbols"
12:09 jani: so, I guess ack for the reverts, and apologies for all the extra work for nothing I persuaded you to do :(
12:45 mripard: tzimmermann: should we open drm-misc-next-fixes?
12:46 tzimmermann: mripard, yes
12:46 tzimmermann: why do you ask?
12:47 mripard: I've been busy with other things so didn't really follow this cycle, and I need it to merge the patches we were discussing with Jani
12:48 tzimmermann: i thought that maarten takes care of d-m-next-fixes. shall I do it?
12:50 tzimmermann: it might be worth waiting for -rc6 to land in drm-next
12:54 mripard: tzimmermann: oh, no, sorry, I got confused and thought you were in charge of drm-misc-next this cycle...
12:54 mripard: ... like I said, I didn't really follow :)
12:55 tzimmermann: no problem, i'll update -misc-fixes soon anyway. if i find -misc-next-fixes lagging behind, i'll update that as well.
13:16 alyssa: Company: I expect on apple platforms, we'll want to prefer gl over vk
13:17 alyssa: just because there are some significant performance problems inherent to doing vk on this broken gpu, that are worked around much more efficiently in our gl driver
13:17 alyssa: (this is the same reason we won't be shipping zink on current hw)
13:18 alyssa: Is there a way to communicate that in the gl or the vk side?
13:18 alyssa: or does gtk just need to hardcode vendor IDs or something?
13:18 alyssa: [N.b.: for gtk specifically, vk performance is probably still "good enough", but battery life is a thing.]
13:21 alyssa: adding a VK_MESA_gimme_minced_fruit ext to opt into nonconformant speedhacks is also an option, I guess, but that's more work for both of us
13:23 emersion: hm, i want to switch wlroots to vulkan as well sometime…
13:23 emersion: would be nice to have a way to find out whether GL or Vulkan should be preferred
13:30 derr: hello. i was here yesterday having some troubles with my nvidia card and mesa drivers. i resolved dependency error. Wondering if anyone dare to take on the challange of downgrading or fixing my mesa drivers .. ?
13:48 koike: hello all, after drm-misc migrated to gitlab, now I'm having issues to push to it with dim tool, I receive a message saying dim is outdated, but it is not, I just pulled the latest version
13:53 Company: alyssa: I'd like to avoid vendor hardcoding, because it's a mess and because it's not forwards-compatible
13:53 Company: so if there's some feature-based method, that would be much preferred
13:54 Company: alyssa: also, there are terminal benchmarks where Vulkan is a lot faster because vte makes us switch shaders a lot and that is slow with GL
13:56 alyssa: Company: Interesting. In general, I'd expect on our platform that VK has lower CPU overhead but GL has lower GPU overhead
13:56 Company: and I want to get to rendering gnome-maps on the GPU so I can live-zoom, and that's gonna require some GPU fanciness - no idea how much is on the VUlkan/GL layer for that though
13:56 Company: why would GL have lower GPU overhead?
13:57 alyssa: 13:17 alyssa | just because there are some significant performance problems inherent to doing vk on this broken gpu, that are worked around much more efficiently in our gl driver
13:57 dj-death: Company: host based upload of mipmaps etc...
13:58 dj-death: non-bindless model also potentially?
13:59 Company: we currently have a Vulkan 1.0 and Vulkan 1.2 mode, the old one is probably going to turn into one that juggles tons of descriptorsets and then new one does just one
13:59 alyssa: non-bindless + no separate texture/samplers
13:59 Company: I originally wanted to play with bindless on GL, too, but if we switch to Vulkan anyway, that's not worth it
14:00 dj-death: iris doesn't support bindless
14:08 FLHerne: #]
14:10 Company: oh, was bindless radeon only?
14:11 Company: then I should totally get to working on it, so that I only have half the issues as with usual stuff!
14:11 dj-death: it's an extension, not sure how supports it
14:11 dj-death: zink supports it ;)
14:12 Company: zink on anv, too?
14:12 dj-death: there might be caveat there
14:12 dj-death: zmike would be able to answer
14:13 dj-death: I think it might be disabled until DG2+
14:13 dj-death: it requires 2 descriptor buffers and we can only support one on Gfx9/Gfx11/Gfx12.0
14:13 dj-death: the HW heap is too small (64MB)
14:13 zmike: if you don't use descriptor buffers it works fine
14:14 derr: hello. anyone want to help me downgrade or fix my mesa drivers ? i even buy new video card today , upgrade from nvidia quadro 370 to nvidia quadro 570. i still have same issues. -ubuntu user
14:14 zmike: you should probably try ubuntu support channels
14:14 zmike: this is a driver development channel
14:15 Company: oh yeah, descriptor buffers
14:15 derr: its mesa driver dev channel ? its ,, very mesa related i think
14:15 Company: to me "bindless" on Vulkan just means I create 1 descriptorset that's large enough to hold all the textures
14:15 zmike: it's ubuntu-related, not mesa related
14:15 dj-death: Company: it means you can update it after it's bound actually
14:16 zmike: Company: zink will automatically choose the most optimal mode, which should be the one that enables bindless
14:16 karolherbst: derr: you'll only get support here for upstream supported mesa versions, which are 24.0.6 or newer
14:16 Company: right, I don't need that because I write a new set every frame
14:16 derr: :) im trying to downgrade...
14:16 derr: its only for the upstream huh
14:16 derr: ok
14:17 derr: this server have ubuntu help channels ? #ubuntu ?
14:17 zmike: no idea
14:17 zmike: try google
14:17 FLHerne: nouveau should support that alright? It's an nv50
14:17 karolherbst: I mean.. you can read yourself into `git bisect` and use that to pin point what might have broken it, but if you just want to install an older mesa you should probably figure out how to do that in your distribution, because we can't really give you any advise on how to install it without also breaking your system
14:18 Company: (and you can't even do it yourselves, because llvm)
14:18 karolherbst: there is of course `meson devenv` to run a single application with your self built mesa, but if you e.g. need to run your entire desktop in it, we'd rather not want to risk you breaking your system
14:19 karolherbst: FLHerne: yes, but anything older than 24.0 isn't supported here anyway
14:19 karolherbst: _but_
14:19 derr: just wanted to play my cs.. im prepeared to break my stuff if anyone want to try help in privmsg
14:19 karolherbst: derr: but anyway, we are happy about figuring out how to fix your issue if it happens on mesa 24.0.6 or newer
14:19 karolherbst: just downgrading is a hariy topic
14:19 karolherbst: *hairy
14:20 derr: if i upgrade to 24
14:20 derr: and its still buggy
14:20 derr: i can come and cry ?
14:20 karolherbst: yes
14:20 zmike: if you build from source*
14:20 FLHerne: well, if there's a significant perf regression on nouveau that's probably worth knowing
14:20 karolherbst: well.. I'm not so strict on the building from source part
14:20 karolherbst: because most distributions aren't really causing that many bugs by patching things
14:20 FLHerne: I had a Quadro FX 400 perhaps 12 years ago, £5 out of a parts bin :p
14:20 zmike: the problem has been repeatedly stated as "my driver install is broken"
14:21 zmike: if distro packages are what's broken, that's not a mesa issue
14:21 FLHerne: it was a decent card after I found a second one to get one set of non-buggy VRAM chips :p
14:21 karolherbst: yeah.. but anyway, that's not the point here. If a user has an issue on upstream supported drivers it's something worth looking into
14:21 karolherbst: zmike: "my driver install is broken" can also mean I just use mesa and it's causing bugs
14:21 zmike: but mesa has no bugs
14:21 derr: for the record,, my fps was good before 22.x mesa update,,
14:22 karolherbst: ahh..
14:22 karolherbst: so it's a FPS regression?
14:22 derr: fps was 99 fairly stable before update,, now down to,, 10-20 -30 ,, sometimes 50
14:22 derr: only cs 1.6..
14:22 karolherbst: mhhh
14:22 karolherbst: I think I know what it could be
14:22 derr: .. i still need to upgrade to 24 before i can cry ?
14:22 derr: yea ?
14:23 karolherbst: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28660 might improve it
14:23 derr: i buy new card today even but,, still
14:23 FLHerne: that's between 22.0.1 and 23.2.1 according to the logs earlier, fwiw
14:23 derr: *look*
14:23 karolherbst: FLHerne: I suspect the multi threading fixes I've landed as they did some cursed stuff to workaround driver architecture
14:23 karolherbst: and the _proper_ way would have been to write a new driver
14:24 karolherbst: anyway... I should prolly go to bed because of my headache...
14:24 derr: i should maybe know what perf is but, i do not
14:24 derr: no no
14:24 derr: ill paypal u
14:24 derr: if u just tell me
14:24 karolherbst: perf = performance
14:24 derr: how to reverse this
14:24 derr: ... oh
14:24 derr: =)
14:25 derr: i can do something,, not university education needed operation to fix this ?
14:26 karolherbst: not really sadly... just downgrading your mesa, or well.. build from an old branch and run steam/cs through meson devenv
14:27 derr: i can bother you , perhaps in msg , to guide me to downgrade mesa ? no responsebility,,, ill pay u even if u got paypal if u name a fair price :)
14:27 derr: i tried but,, failed misserab ly
14:28 karolherbst: ohh actually I meant this MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28641
14:28 derr: i can wait for tomorrow if your head is ready for bed
14:28 derr: *look*
14:30 derr: nv50 covers nv48 ? think i use nv48 ,,, something,, chipset ?
14:32 karolherbst: quadro 370 should be a g84 which is driven by nv50, quadro 570 should be the same generation just faster
14:32 karolherbst: a little faster
14:33 karolherbst: anyway, cya
14:33 derr: :) i dunno why,, i hoped the 570 would have different chipset i guess ,, ran out this morning
14:33 derr: ok bye
14:34 karolherbst: derr: https://docs.mesa3d.org/install.html#building-with-meson just following "Building with meson" and irnore the install one, and "running against a local build (easy way)"
14:34 karolherbst: but if you have no experience with any of that, might be a bit problematic anyway
14:34 karolherbst: could throw you a script or something tomorrow
14:34 derr: i tried some meson stuff yesterday ,, got in some trouble but,, ill take a look
14:34 derr: ill hang around here trying to bother people as politely as i can waiting for u tomorrow =) thankyou
14:34 soreau: the problem is they have broken system packages, so it will likely take some work to install the deps from apt
14:35 derr: soreau: hi again, nono,, i fixed that,, i just deleted the file it complained about,, was some var/blabla/copywritght
14:35 derr: just rm -rf stuff = fix
14:35 derr: now system think it have v23 again,, and actually have 23,,, i think,, unless meson hidden something somewhere from apt
14:36 derr: libglx-mesa0/mantic-updates,now 23.2.1-1ubuntu3.1 amd64 [installed,automatic] free implementation of the OpenGL API -- GLX vendor library
14:36 derr: soreau: do you dare the argous horrible task of helping me downgrade to 21 ? feel free to break anything policy...
14:39 soreau: well it's pretty straightforward, just follow the link and install and missing deps that are needed, then run with that version of mesa
14:39 derr: looking at the meson build howto now
14:40 derr: dont look like voodoo
14:42 worldlabels: anyways i can not remember the specification but i remember i had suspicion about the 50 50 duty cycles, and flattening the netlists it revealed a long positive clock and short negative edge, and vice versa without external signalling. which i interpreted as interference signalling was accounted on the rails, in other words satellites can take over the voltage rails and clock rails cause it is in the signalling of aggregated clock voltage
14:42 daniels: mairacanal, sima: hey, any chance of getting some review on the configfs-for-vkms series at https://lore.kernel.org/all/20230829053201.423261-1-brpol@chromium.org/ please? it'd be really useful to have for compositor/libliftoff testing - there's also a link from mvlad below to a series which adds support for it to igt
14:44 derr: soreau: i can pass u something in msg ? my log from apt get ? to ask u if u agree that its the library at all that needs upgrading or fixing ? maybe its something else obvious ?
14:45 derr: that its the mesa library at all*
14:45 derr: got a list of 5-6 packages
14:46 soreau: derr: you can pm me, but typically for more than a few lines on IRC, better to post them to a pastebin service and share the link
14:46 derr: just a very few ones :)
14:46 derr: could compile on 1 line but
14:46 derr: second
14:48 worldlabels: since they talk few about gravity of the earth it is very likely that satellite signal is way faster to arrive than anything generated on the chip as defending the bus lines with chips pulling them in low or high impedance than with software this can not be fixed.
14:49 worldlabels: which means that the defense is permanent
14:54 mvlad: mairacanal, sima, re daniels message, configfs-for-vkms might also help out some of the amd folks wrt multiple-plane flexibility: https://www.spinics.net/lists/amd-gfx/msg104649.html.
15:10 worldlabels: in other words FPGA internal very fast units on my algorithms are unlikely to succeed on bypassing any of such defense, since the microcontroller on power lines is not as fast locally than the wireless decibels to arrive.
15:16 worldlabels: than why i stated that mixed mode analog digital would work on 50 50 duty cycle power lines, cause it is very likely it would, but is very hard to build.
15:24 worldlabels: the biggest thing i realized is that miniPOL system amplifiers or diodes on the power lines due to such architecture on the clock lines would end up consuming cosmic and satellite energy, but not on fpga's that have their own custom circuits, so fpga's are clearny much more low power than asics which was not what i thought considering literature.
15:29 Company: dj-death: thinking about systems where GL is preferrable to Vulkan, does that go for the old intel systems that had flaky initial Vulkan support?
15:30 Company: like Broadwell or whatever it was?
15:30 Company: or do those not advertise Vulkan anymore?
15:38 worldlabels: but that is just my take on those things, maybe it's not entirely correct, it is just when low is in more time on complex aggregated systems where the duty cycle would not collide on the satellite, it would end up being very low poer and could not consume any of that energy but take it locally, its lienard wiechert field theory.
15:39 worldlabels: but the controller on the power lines would still be vulnerable and would be spotted by defense systems
15:48 worldlabels: so i decided that it is all about taping out such power controller which has so large complexity that it is almost unreal to get it done or battery controller at least by so called terrorist groups, they can not make it to be threat through the skies.
15:49 worldlabels: it is a chip that could do it but that is very complex to get done.
15:52 worldlabels: its some nuclear technology similar stuff such chip could be anihilation based as well that would do it for sure, but other even more complex but less efficient ways would do too, but none of this can ever me worked out by such men or groups as hamas.
15:53 worldlabels: already when you access such pages or know how you are walking on thin line.
15:58 worldlabels: all this subject is hard to get brain cells at, but we see that there is some aggression involved where some do not want others to live and the market of defense against such is very large, so united states earns also money or those companies such as lockheed martin and such. it's big business .
16:00 zmike: DavidHeidelberg: looks like you and tpalli are getting through it
16:13 zmike: eric_engestrom: did I miss anything or was that it
17:35 worldlabels: in reality i do not also grasp those duty cycle calculations that well due to timely resources shortage, domino clocks or what they described as 50 50 duty cycles were present in core duo range for short while, were they safer on chip from external pulsing i dunno, but they complained about northbridge tendency to ovearheat. so interrupts started to delay and timing was volatile.
17:45 worldlabels: i have had couple of such and indeed there were more problems on the hubs and such things and interrupts and systems were not as reliable as SNB and equivalent amd ones.
17:54 worldlabels: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=406f87cc9553f52e395f7d8e4884e0e375470f7e page 3, paragraph IV skew tolerand domino clocks, common sense says that they can still worm the power controller. which they likely do with the defense systems, but sure i can not guarantee the eligibility or correctness of my theory.
17:57 worldlabels: i try to earn a little bit money with easier methods as playing sports as injured, and hope to do well, since performance and memory efficiency wise my systems work well, security wise i gave up, i can not handle malicious interference probably.
18:08 dwfreed: .
18:50 dj-death: Company: broadwell, ivybridge are not fully compliant and they have their own driver
18:54 Company: dj-death: but if GTK chose Vulkan over GL, we would pick a not fully compliant driver?
18:58 bl4ckb0ne: Company: correct, there's some missing features
18:58 bl4ckb0ne: iirc its compute shaders?
19:00 Company: I have no idea - I'm mainly wondering if we should pick GL over Vulkan on those
19:02 dj-death: Company: yeah
19:02 Company: how do we do that?
19:03 Company: like, do we need to hardcode the driver or is there some generic method we can use to select GL there?
19:04 bl4ckb0ne: check phdev/dev features maybe ?
19:16 sima: airlied, mairacanal, dolphin backmerge pushed to drm-next
19:16 sima: tzimmermann not around it seems, I guess I'll ping tomorrow
19:17 airlied: sima: I thought I did -rc5, not that I mind -rc6 :-)
19:22 sima: airlied, oops I missed that, but the defio reason is still valid since that's in -rc6 only
19:57 Sachiel: Company: you should be checking if the vulkan device you are opening supports the features you need. The hasvk driver won't be announcing support for anything the hw can't do, so if you need something they don't do, then fall back to GL.
19:58 Company: if it's good enough for that, that sounds good to me