02:33 airlied: uggh inverted green gear, why you annoying me multisample gears
02:48 imirkin: iirc nouveau had some extra-special issues with heaven at 8x msaa ...
02:48 airlied:thankfully stopped at 4x :-P
02:48 airlied: heaven is broken, but it seems like the same reason gears is broken
02:48 imirkin: i think it was some kind of blit issue in the end
02:48 airlied: which looks like depth testing related
02:48 imirkin: yeah
02:49 imirkin: i see much debugging in your future
02:49 tlwoerner: robclark: ps, thanks for looping me in for the GSoC conversation :-)
02:52 airlied:found I wasn't interpolating depth for the depth test per-sample, but didn't make much difference
02:53 robclark: np
02:59 imirkin: airlied: do you have a screenshot? just curious, not sure i understand "inverted"
03:03 airlied: gimme a sec, the green gear is inside out I suppoes :)
03:05 airlied: imirkin: https://people.freedesktop.org/~airlied/scratch/glxgears.png
03:05 imirkin: cool effect :)
03:06 imirkin: it's not even consistent in itself
03:06 imirkin: note that the red gear also has issues
03:07 imirkin: the "back" face is showing up more than it should
03:07 airlied: heaven looks cool since lost of obscured objects are getting shown through other objects :-P
03:07 imirkin: could it be something to do with not culling things you should be culling?
03:07 imirkin: although that doesn't explain the green one
03:08 airlied: hmm it looks like I'm writing to the depth buffer values I shouldn't
03:10 airlied: hmm maybe not, single sample also has similiar vals
03:10 krh: depth buffers, how do they work
03:10 airlied: multisample depth buffers, even more magic
03:10 janesma: mareko: it looks like you broke the android build
03:10 janesma: ninja: 'out/target/product/celadon_tablet/gen/STATIC_LIBRARIES/libmesa_dricore_intermediates/main/marshal_generated.c', needed by 'out/target/product/celadon_tablet/obj/STATIC_LIBRARIES/libmesa_dricore_intermediates/main/marshal_generated.c', missing and no known rule to make it
03:11 janesma:sees gitlab issue, oops
03:55 airlied: yay found it, non-multisample depth code has some stencil disable optimisations paths, and I copied one execution mask update too closely
03:58 airlied: yay heaven at 4xmsaa
03:59 imirkin: how many spf?
04:00 airlied: 1 :-P
04:31 imirkin: airlied: up the resolution, i'm sure that'll improve the spf!
04:32 airlied: it's already at 1280x800 I should probably reduce further :-P
05:22 mareko: llvmpipe is awfully underthreaded
05:24 airlied: it could definitely do with threading shader compilers
05:24 airlied: compiles
05:26 airlied: I'm not sure how much value it would get from threading the draw module
05:31 airlied: mareko: or is there other areas you think it could be done better?
06:46 mareko: airlied: it's unable to use my 16 threads
06:47 mareko: that said, I never use llvmpipe and never will
06:58 mareko: u_threaded_context for llvmpipe should help
07:07 mareko: I've run out of things to do for glthread, it seems pretty good right now, it has even better vertex upload code than the rest of Mesa, because it doesn't split multidraws
07:41 airlied: mareko: once i hit gl45 i might look at threafs
07:53 mareko: airlied: why llvmpipe?
07:55 mareko: if it's not for "llv"
09:10 tanty: hakzam: do you think I can get, at least, a ACK from you on
09:10 tanty: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4238 ?
12:45 pq: When using legacy KMS API, is userspace supposed to do a modeset every time only the pixel format on the primary plane changes?
12:45 pq: size, stride, etc. remains the same
12:51 danvet: pq, yup
12:52 danvet: well, I think maybe some drivers allowed some changes sometimes in page_flip
12:52 danvet: you could also do an update_plane on the primary plane
12:52 danvet: but given that the number of drivers which support universal planes but not atomic is 0, no point
12:53 danvet: pq, 909d9cda2edfc from 2013 locked that behaviour down
12:54 danvet: iirc the only change every allowed was i915 allowing tiling changes
12:54 danvet: but since tiling might impact on the format struct nowadays with modifiers, even that is a bit iffy
12:54 ickle: and stride at one point
12:55 pq: danvet, right. So I better ensure a modeset and not even try pageflip first.
12:55 danvet: ickle, we still allow that, when the underlying atomic can do it without a modeset
12:55 danvet: pq, yeah there's a lot less you can do with legacy page_flip than atomic without ALLOW_MODESET
12:56 danvet: pq, it should be faster though than an TEST_ONLY commit (since we bail out real early)
12:56 danvet: so if it makes the code easier, it wont hurt at least
12:56 pq: danvet, I'm also running agains a downstream driver that does not fail the pageflip that attempt to change pixel formats, it just results in wrong colors.
12:56 danvet: pq, uh, that's a real old driver ...
12:57 pq: not old, just out of tree: EVDI
12:57 danvet: since since 2013 we should be catching this in core
12:57 pq: oh really...
12:57 danvet: yeah that's the kernel commit I cited above
12:58 pq: then I better check my hypothesis of not having a modeset in there
12:58 danvet: and even if you do an old ADDFB ioctl with the legacy way of specifying pixel formats
12:58 danvet: we do look up the corresponding fourcc format and use that
12:59 danvet: so drm_fb->format should be set correctly
13:00 danvet: and we've done that ever since jbarnes added fourcc style ADDFB2
13:00 danvet: so also not seeing how you'd escape this check
13:00 pq: well, this *is* a confusion between XR24 and XB24
13:00 danvet: ?
13:00 danvet: you mean rgb vs bgr?
13:00 pq: yes
13:01 danvet: so if you do legacy addfb
13:01 danvet: then there's no difference
13:01 pq: but I do believe it should be using AddFB2 - need to verify that too
13:01 danvet: driver picks what it feels like
13:01 danvet: yup, you definitely need addfb2 for this case
13:01 danvet: driver picks what it feels like = mostly standardized, except some things because can't break existing userspace
13:02 pq: it's just that all symptoms would fit perfectly with a legacy pageflip changing the pixel format, but since you say that should be impossible...
13:02 danvet: exceptions are: host byte order (instead of le for everyone) for bochs and virtgpu
13:03 danvet: and bgr101010 instead of rgb101010 for nouveau
13:03 danvet: this is the exhaustive list
13:03 danvet: so addfb1 can only give you rgb, never bgr
13:03 danvet: for what you're doing
13:04 pq: ok, so it cannot be addfb1
13:04 pq: need to dig deeper...
13:05 danvet: I think it is addfb1
13:05 danvet: since both your rgb and bgr buffer map to rgb in the kerenl
13:05 pq: but if I force a modeset, then the colors pop back right
13:06 danvet: huh
13:06 pq: force = re-hotplug the monitor
13:06 danvet: yeah that part doesn't make sense
13:06 danvet: if it's bgr vs rgb
13:06 pq: yeah
13:07 pq: so I'll check if a modeset indeed happens or not, and is pageflip actually changing pixel format or not
13:07 pq: EVDI debug prints hints to the direction of pageflip changing the format, causing the issue
14:57 pq: is there an easy way to get drm.debug kind of output but for just one DRM device at a time?
14:58 MrCooper: daniels: "It seems like [unit tests] aren't currently run for Linux either" which ones? The Linux build jobs do run the meson unit tests
14:58 MrCooper: (before ninja install)
14:59 daniels: MrCooper: ah, I didn't see that -Dbuild-tests=true was set in .gitlab-ci/meson-build.sh - I was looking in the main .gitlab-ci.yml for the options
14:59 vsyrjala: pq: bunch of work has been done recently in i915 to convert the debugs to be per device. the core/helpers will hopefully follow once people run out i915 things to convert
15:00 vsyrjala: with that one could use grep/etc. to filter for a specific device
15:00 vsyrjala: dunno if anyone has thought of a knob to only emit debugs for a specific device
15:01 pq: vsyrjala, heh, in my case, it is the intel device I want to ignore. :-)
15:03 vsyrjala: if we had converted everything in i915 you could filter those out. but still seeing ~500 plain DRM_DEBUG* in i915 so not quite there yet
15:03 vsyrjala: also wouldn't help with the debugs coming from the core/helpers
15:04 vsyrjala: though i suspect many i915 debugs will have something intel specific in the function name so could also use that when filtering
15:08 alyssa: Could someone take a peak at patch 3 of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4292.patch ? mesa/st change adding some fallback formats for R3_G3_B2
15:08 alyssa: Thank you :)
15:47 agd5f_: airlied, danvet: for the drm-prime sg length fix, should I land that in drm-misc-fixes or send a separate PR myself. Not sure if there will be another drm-misc-fixes or not at this point.
15:48 danvet: agd5f_, drm-fixes happens when needed
15:48 agd5f_: ok. I'll push there then
15:48 danvet: at most just ping mlankhorst_ (or whomever does -fixes that release) to make sure it goes out
16:20 mlankhorst_: I'll do it tomorrow :)
16:20 mlankhorst_: bb
16:50 robclark: janesma: I don't suppose you had a chance to look at https://gitlab.freedesktop.org/majanes/frameretrace/-/merge_requests/1 ?
16:52 janesma: robclark: sorry I didn't notice it until now! My gitlab notification settings must need some adjustment.
16:53 janesma: I will take a look today.
16:53 robclark: ahh, thx.. maybe notif settings is per project?
17:03 imirkin: robclark: yay for supporting amd counters!
17:04 robclark: tbf, there was already some support.. just not enough to capture counters from multiple different groups..
17:04 imirkin: ah
17:04 imirkin: still yay :)
17:04 robclark:needed to be able to correlate CP_ALWAYS_COUNT to various other things in other groups
18:05 anholt: there's a mesa-ci-lava-baylibre shared runner that didn't have a tag on it and was failing general jobs. I've paused it for now
18:06 airlied: mareko: why work on llvmpipe? fastest path to a sw vulkan impl
18:11 karolherbst: airlied: btw, how is you libclc stuff going? I think there might be a bigger push for that soonish
18:12 airlied: karolherbst: just needed tstellar to push it I think, should cycle back around to it soon
18:12 karolherbst: ahh cool
18:12 karolherbst: how about the mesa patches?
18:12 karolherbst: might make sense to create an MR so we can already play around with it
18:13 karolherbst: dunno if you saw !4318 already
18:13 agd5f_: drm-misc-next-fixes for 5.7?
18:14 airlied: karolherbst: nope not yet
18:14 airlied: I'll do an MR otday
18:19 karolherbst: cool
18:30 danvet: agd5f_, yup
18:32 danvet: I guess mripard will do the next pull for that one any day now
18:32 danvet: mripard, drm-misc-next-fixes for context
18:59 mripard: danvet: yep, it was on my todo-list for tomorrow
19:13 bnieuwenhuizen: airlied: I think technically swiftshader is the fastest way to a sw vulkan impl :)
19:21 ajax: bnieuwenhuizen: well yes, but if you have something that's broken in radv, knowing it works in swiftshader is less useful than knowing it works in llvk
19:22 ajax: (potentially)
19:25 bnieuwenhuizen: yeah
19:44 airlied: bnieuwenhuizen: have you tried shipping swiftshader :-)
19:45 airlied: karolherbst: also clc work requires.working switch and structurizing
19:46 karolherbst: already done :p
19:46 karolherbst: switch even
19:46 karolherbst: I just had nothing serious to test it on
19:46 airlied: karolherbst: in master?
19:46 karolherbst: ahh, no
19:46 karolherbst: the structurizing would need a proper review
19:46 karolherbst: but it seems to work very nicely
19:46 karolherbst: airlied: the ms stuff also uses the same
19:47 karolherbst: so we might actually see a bigger push here
19:47 airlied: so i cant test my mr without it, so was just being lazy
19:47 karolherbst: sadly the original author isn't really responsive anymore, so dunno
19:47 karolherbst: airlied: well, I will give it some proper testing over the next few days
19:47 karolherbst: would be cool to get at least the core stuff working
19:49 airlied: ill make an mr saying it needs your mr i suppose
19:50 karolherbst: well, it's not mine, but karolherbst/mesa/1
19:50 karolherbst: :p
19:50 karolherbst: I plan to push that stuff to my MR though I guess
19:51 karolherbst: and probably I will end up cleaning up the code as well
19:51 karolherbst: airlied: yeah.. link to the mesa/mesa structurizer MR and I will force push updated patches there
19:57 karolherbst: kusma: the CL opcodes are annoying aren't they? (inf + nan handling)
20:02 kusma: karolherbst: ugh, yeah :-P
20:04 karolherbst: ahh, I don't think that through right now, round returns an int, not float
20:04 airlied: kusma: https://gitlab.freedesktop.org/airlied/mesa/-/commits/libclc-spirv-wip/
20:04 karolherbst: so nan_check does the wrong thing
20:04 airlied: is my old tree
20:04 airlied: I need to rebase the patches out
20:04 karolherbst: I think round needs to return 0 for both inf and nan
20:04 karolherbst: at least the CTS expects 0 for inf
20:04 airlied: top 7 patches are the clc stuff
20:05 kusma: airlied: thanks
20:05 karolherbst: airlied: why the fast variants though?
20:05 karolherbst: or can't we be crappy here
20:06 airlied: I think i was leaving crappy for later
20:06 karolherbst: fair enough
20:06 karolherbst: but I thought I already implemented those...
20:06 airlied: but libclc has fast version itself
20:07 karolherbst: so? I prefer to use vtn/nir stuff over libclc :p
20:07 airlied: should be no real difference if the spirv is the same
20:07 karolherbst: maybe
20:07 airlied:needs to page back in native vs fast
20:08 karolherbst: I would still assume the translation to be a bit faster if we emit the stuff at vtn time
20:08 karolherbst: but yeah.. maybe it doesn't make a difference
20:09 airlied: yeah maybe we can leave fast to mesa
20:09 karolherbst: ohh, fast have a different calcuation mhhh
20:09 karolherbst: *has
20:09 airlied: the clc impls are pretty small
20:10 airlied: or maybe not, half_sqrt
20:10 karolherbst: yeah... maybe it really doesn't make much of a difference when we do the conversion really
20:10 karolherbst: but yeah
20:11 karolherbst: airlied: we can do hw sqrt simply
20:11 karolherbst: 8192 ulps is quite far away.. but maybe some hw have a faster way of calculating sqrt
20:12 mareko: labbott: rsq + mul
20:12 mareko: I mean karolherbst
20:12 karolherbst: we have sqrt in hw actually :)
20:12 karolherbst: since 2nd gen maxwell
20:12 mareko: with the same execution rate?
20:12 karolherbst: sqrt is same as rsq afaik
20:13 karolherbst: anyway, nvidia prefers using sqrt over rsq+mul
20:13 karolherbst: so...
20:14 karolherbst: also why would they put it in hardware that late if it's not faster
20:14 mareko: precision
20:14 karolherbst: no, that's not argument for nvidia
20:14 karolherbst: *no
20:14 karolherbst: they rather implement precision in sw
20:15 karolherbst: wait.. I even benchmarked it
20:16 karolherbst: mareko: https://gitlab.freedesktop.org/mesa/mesa/-/commit/6f98a3065bce
20:17 karolherbst: close to 10% more perf in pixmark piano
20:18 karolherbst: but we also implement sqrt as rcp
20:18 karolherbst: rcp+rsq
20:19 karolherbst: ah, nice does the same
20:19 karolherbst: *nir
20:20 mareko: karolherbst: did you benchmark sqrt = x * rsq(x) ?
20:20 imirkin: mareko: that breaks stuff =/
20:20 imirkin: blob does it as rcp+rsq
20:21 karolherbst: and I am sure there is a reason we do the same in nir as well
20:21 imirkin: karolherbst: also later gens have a native sqrt, right?
20:21 karolherbst: later than 2nd gen maxwell?
20:21 karolherbst: well pascal for sure
20:21 karolherbst: no idea about volta+
20:21 imirkin: SM50+ i figured
20:21 imirkin: oh yeah, dunno
20:22 imirkin: mareko: we used to do x*rsq(x) originally
20:22 imirkin: and we used the zero-wins variant of * to make it work for 0
20:22 imirkin: but there were still issues.
20:23 imirkin: unfortunately i don't remember what they were
20:23 imirkin: it was ages ago. i gave up and moved to rcp(rsq()) after i saw that blob was doing it
20:23 karolherbst: imirkin: https://gitlab.freedesktop.org/mesa/mesa/-/commit/c1e4a6bfbf015801c6a8b0ae694482421a22c2d9
20:24 imirkin: ah infinity. fun.
20:24 karolherbst: aynway, with a native sqrt all this doesn't matter all that much anyway
20:24 karolherbst: it seems to be fast enough
20:26 imirkin: did we since gain a sqrt() library function for fp64? or do we still do x*rsq(x) for fp64?
20:26 karolherbst: dunno
20:26 imirkin: nvidia has dedicated rsq64 and sqrt64 functions - i think 1/rsq64 is too far off, even with smoothing interations
20:27 airlied: karolherbst: okay MR in place, will see about testing it today/tomorrow
20:29 karolherbst: cool
20:51 mareko: jekstrand: is there somebody at Intel who can bisect the i965 primitive restart regression in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4314 , broken tests: https://mesa-ci.01.org/mareko/builds/15/group/63a9f0ea7bb98050796b649e85481845
20:52 jekstrand: Ugh... IVB is the latest affected platform....
20:53 jekstrand:pulls out a laptop
20:53 imirkin: prim restart was in software on those platforms, no? (in at least some cases)
20:54 jekstrand: Arbitrary prim restart, yes.
20:54 jekstrand: IIRC, it's hard-coded to 0xffffffff until some gen
20:54 imirkin: presumably gen7.5 :)
20:56 jekstrand: presumably. :-P
20:59 jekstrand: mareko: You might want this: https://paste.centos.org/view/b612eb70
21:01 mareko: jekstrand: thanks, I see the problem
21:01 jekstrand: mareko: Still need a bisect?
21:04 mareko: jekstrand: yes
21:05 jekstrand: 3 steps left
21:08 jekstrand: mareko:
21:08 jekstrand: 07d59598ec13151024e30b82d90dd4d5c73c225d is the first bad commit
21:08 jekstrand: commit 07d59598ec13151024e30b82d90dd4d5c73c225d
21:08 jekstrand: Author: Marek Olšák <marek.olsak@amd.com>
21:08 jekstrand: Date: Sat Mar 21 22:49:03 2020 -0400
21:08 jekstrand: mesa: don't ever bind NullBufferObj for glBindBuffer targets
21:08 jekstrand:
21:08 jekstrand: Since VAOs don't use NullBufferObj for vertex attribs anymore, let's remove
21:08 jekstrand: more uses of NullBufferObj.
21:08 jekstrand: mareko: I'll leave my ILK running if you have other issues
21:08 mareko: great, thanks!
21:10 jekstrand:hopes to delete i965 from the tree one day....
21:14 emersion: please don't ;_;
21:15 jekstrand: Don't worry, we won't do it until things are clearly EOL and we have a plan for distros to continue shipping it.
21:15 emersion: thanks :)
21:16 jekstrand: But I'd really like mareko to be able to make changes without worrying about breaking SW primitive restart and other similar absurdities.
21:16 mareko: that basically means forking mesa
21:16 jekstrand: Yeah, I know.
21:16 jekstrand: I want to one day but I can't say that I have a feasible plan yet
21:34 mareko: or forking src/mesa to src/mesa_classic
21:35 karolherbst: well, what happens if a new generation of drivers gets EOLed
21:35 mareko: in mesa? nothing, most classic drivers are EOLed
21:35 jekstrand: I wish we had a good plan for that
21:37 kisak: considering the size of mesa overall, it wouldn't be too terribly painful if the fork lived in a subfolder
21:38 karolherbst: kisak: the problem is it wouldn't be the only fork probably
21:38 karolherbst: maybe that issue won't come up in the next months, but maybe in 10 years somebody wants to do something similiar
21:38 karolherbst: do we have src/mesa_classic2 then or so?
21:39 emersion: rename mesa_classic to mesa_prehistory
21:40 kisak: karolherbst: is there a problem there? the point would be that the random blue-moon contributor could still go through the same review process regardless of which legacy frok
21:40 kisak: *fork
21:41 kisak: and legacy doesn't need to mean completely frozen in time, never to get another point release
21:41 karolherbst: yeah.. that's probably fine then
21:53 mareko: 1) nobody should add a new classic driver 2) development can continue happening in src/mesa_classic
21:57 mareko: it's a great solution, because nothing changes from the packaging and compatibility perspective
22:01 karolherbst: mhh, right and gallium drivers can also be simply forked
22:02 mareko: karolherbst: neither is forked, it's really a separation of classic and gallium
22:03 karolherbst: I meant to copy the gallium driver
22:03 mareko: karolherbst: neither is copied, classic drivers would be *moved* to src/mesa_classic
22:07 mareko: mesa/main would be forked, but the whole reason to fork it is to *preserve* classic drivers and keep them functional
22:12 ajax: jekstrand: just write crocus already
22:13 ajax: the only meaningful gap in gallium's coverage at this point is gen4-7
22:14 ajax: the only things left in classic of any real interest are vieux and radeon and son of radeon
22:14 ajax: both of which i am entirely fine with supporting through the "this is what a DRI driver looks like" interface and not trying to keep abreast of modern GL
22:15 ajax: i'll build old mesa for that. did that once already for dropping the DRI1 drivers between 7.11 and 8.0 (which, also, hooray)
22:16 ajax: but the only people at all interested in pre-dx9-class hardware, at this point, are hobbyists.
22:17 ajax: nothing wrong with being a hobbyist, of course. but it's not what mesa seems to be interested in.
22:31 mareko: ajax: what is crocus?
22:32 bnieuwenhuizen: wordplay on iris?
22:32 mareko: I don't get it
22:34 ajax: yes, wordplay on iris. as flowers they're closely related species, and the crocus in folklore is one of the earliest to flower in the spring.
22:34 ajax: so since these gens are older, came into the world before, the ones supported by iris...
22:35 mareko: there was the ilo driver at one point
22:36 ajax: so: write a gallium driver for the chips supported by i965 not supported by iris. fork at that point and you've forked at a meaningful difference in hardware capability that makes sense.
22:36 ajax: true!
22:36 mareko: it seems to have gen6-7: https://cgit.freedesktop.org/mesa/mesa/commit/?id=38794259175852084532499a09dec85b6c6a4321
22:36 mareko: jekstrand: ^^
22:42 ajax: not sure whether it'd be easier to start just before that was removed and forward-port it continuously from there, or write a new one whole.
22:45 mareko: or move classic drivers to src/mesa_classic
22:46 mareko: even if i965 wasn't needed, there would be a lot of resistence to removing the other classic drivers
22:47 ajax: i'm... not sure that's true.
22:48 mareko: do you know who inspired the creation of iris?
22:48 mareko:<-- this guy
22:49 imirkin: i think as long as there's a way to make the old stuff work with new mesa, nobody cares that nouveau_vieux isn't getting the very latest and greatest exts (or optimizations)
22:49 ajax: good on you, i'm very happy about it, but i don't get your point.
22:49 imirkin: my point is that it'd be fine to remove
22:50 imirkin: and leave frozen ala dri1
22:50 ajax: (not your point imirkin, marek's.)
22:50 imirkin: oh
22:50 mareko: nevermind
22:50 imirkin: mareko's point is that he's the master of the known universe :p
22:51 imirkin: (jk)
22:51 ajax: it was well true already, but iris made it pretty official to me that every classic driver is a liability
22:52 ajax: the only reason i would resist removing them is i maybe kinda vaguely care about that range of intel gpus.
22:53 mareko: if people are OK with it, we could remove the classic drivers now: r100, r200, nouveau
22:53 ajax: but... gen4 was 15 years ago. gen7 was 8.
22:54 ajax: i was a broke student, i know what an eight year old machine is worth (plenty), we should keep it working if we can, and we can.
22:54 imirkin: GeForce4 MX was ... 18. wow.
22:54 ajax: but doing that in the branch of mesa that is the future? enh.
22:54 ajax: we have git, we know how to cherry pick, we're good at this.
22:55 ajax: and at some point for that class of hardware ceasing to mess with it is a virtue
23:00 mareko: ilo has gen6-7, maybe not as fast as i965, but do you really care
23:01 ajax: ilo can be taught whichever performance tricks it was made iris faster than i965, if it comes to matter
23:02 imirkin: probably a bit more important was that ilo never gained any GL4 features
23:03 ajax: but fwiw rhel8 already doesn't really technically support ivybridge. so the part of me that gets paid to care doesn't care about i965.
23:03 imirkin: what about haswell?
23:03 imirkin: and that weird gen8 which isn't supported by iris (cherryview? something like that)
23:04 ajax: i think hsw was the baseline that we said we might support, but i'm not aware of that ever happening. not that i'd be aware, necessarily.
23:05 ajax: ivb the kernel will complain at you and maybe taint, hsw i think is in bounds
23:29 airlied: ilo isn't the answer, just fork iris
23:29 airlied: since you really want to use all the sharedi ntel code
23:29 airlied: like the compiler
23:48 karolherbst: airlied: I pushed the updated structurizer stuff in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2401/commits
23:49 jekstrand: mareko: Yeah, I don't think ILO is a good plan. It doesn't have surface compression, piles of features are missing, has a garbag compiler, etc.
23:50 jekstrand: It'd probably be easier to mash i965 and iris together
23:51 mareko: or separate classic from gallium