00:00imirkin: no
00:00karolherbst: the code is a bit differently optimized but that shouldn't matter
00:01karolherbst: and the headers are also equal.. strange
00:02karolherbst: maybe something else is broken ..
00:17jekstrand: robclark: I may have only run it on Vulkan. :-(
00:19robclark: jekstrand: if you or ngcortes can get me the nir_validate outputs for any other fails, I can fix those up too.. the fix is usually pretty simple and involves deleting code most of the time ;-)
00:19robclark: those are the best kind of fixes
00:19karolherbst: still wondering why that test fails...
00:22karolherbst: ohhhh wait...
00:22ngcortes: robclark, all the other failures we identified can be found here:https://mesa-ci.01.org/mesa_master/builds/21305/group/63a9f0ea7bb98050796b649e85481845
00:22karolherbst: gbm was stupid
00:22robclark: ngcortes: thx, will have a look thru that to see if they are all the same or if some other fixups needed
00:23ngcortes: robclark, definitely. it looks like the first few lines are identical in the tests I've sampled fwiw
00:25robclark: looks like there are some more glsl_to_nir fixups needed..
00:25robclark: I guess unsurprisingly in things we don't have coverage of in gitlab CI
00:26robclark: I'll update existing MR..
00:33airlied:is trying to get gl4.5 driver in there :-P
00:34karolherbst: airlied: llvmpipe?
00:34airlied: yup, the patches to 4.5 are nearly manageable now
00:34karolherbst: hey.. :D
00:34karolherbst: you are passing the CTS I guess as well?
00:35airlied: lols I just hit the above issue running CTS :-P
00:35airlied: that's what I get for rebasing too much
00:35karolherbst: :D
00:35airlied: KHR-GL45.shader_group_vote.availability
00:35karolherbst: :D
00:36airlied: karolherbst: I was passing all of CTS 4.5 a couple of weeks ago, I think a few regressions have crept in, in my rebasing
00:36airlied: with one more branch I'm passing all of GLES 3.1 CTS
00:40robclark: looks like it is mostly vote_any/vote_all..
00:41robclark: just going thru the rest of intel CI logs to see if there is anything else
00:49robclark: ngcortes, jekstrand, airlied: pushed a couple more fixes to !5505 .. I *think* that should cover everything intel gl ci covered.. would appreciate if someone could feed that branch to intel ci
01:17karolherbst: robclark: at least looking over my piglit run you caught everything
01:18jekstrand: robclark: Just kicked it to CI
01:21ngcortes: robclark, I just responded to #3141. need to step out, but will check back later
01:34airlied: bleh bunch of xfb regressions in my last set of rebases, ah well shouldn't be too hard to nail down
02:58airlied: jekstrand, karolherbst : https://paste.centos.org/view/ee1e350b
02:59airlied: I ported piglit CL program tests to l0, and yes that is running on anv
03:01airlied: though it may also be lying about passing, it's at least executing kernels :-P
03:23jekstrand: airlied: nice!
07:40pq: DPA, I thought that Xorg had the facilities to copy from the huge GPU framebuffer shared by all outputs to per-crtc framebuffers when necessary, so that e.g. scanout-able memory requirements would work across devices?
07:42pq: onox, yeah, you're not "allowed" to call any EGL function unless the EGL version and/or extension strings tell you it is supported, even you happen to link it or eglGetProcAddress() it just fine.
07:51pq: *even if you happen
09:06DPA: pq: It looks like xorgs modesetting code has indeed a codepath for that if rendering is offloaded to a different xscreen using prime, and when rotating a crtc. I'll have to take a closer look at that. But I remember that rotating a crtc in xorg made things almost unusably slow last time I tried (that was without using the gpu, though), due to memory bandwith limitations on my system. I hope copying in this scenario doesn't end up being as slow as that.
09:06DPA: ow xorg renders things, and that would be a lot more difficult to do...
09:08DPA: Otherwise, I may have to change how xorg renders things, and that would be a lot more difficult to do...
09:09MrCooper: DPA: yeah, the generic code for that in the xserver tree is rather inefficient, xf86-video-amdgpu/ati have more efficient code for this
09:15MrCooper: DPA: do you absolutely need to use Xorg, or could a Wayland compositor work?
09:22DPA: There are still some X11 applications that don't work well on Wayland.
09:22DPA: In addition to that, I've been working on a Window Manager for X11 for almost a year now: http://projects.dpa.li/git/?p=dpaw.git;a=tree;f=wm;h=52cb92bdf2da8ec381db4236d5d0637e565e5632;hb=HEAD
09:22DPA: MrCooper: ^^^
09:24MrCooper: are there bug reports about those applications?
09:34DPA: MrCooper: I don't know. I don't believe in the future of wayland anyway, I think X11 is way easier to use and I really like the network transparency aspect of X11.
09:34DPA: At this point, maybe I should just start writing my own display server...
09:34MrCooper: Wayland is here now, it's not "the future" anymore
09:37emersion: DPA: have you seen waypipe
09:39MrCooper: in the worst case, network transparency works as well with Xwayland as with any other X server
09:44MrCooper: (I'm using that for Emacs' GTK UI every day)
09:52malice: Can you disable wayland's mouse accel and input lag yet?
09:53MrCooper: those are compositor issues, not Wayland protocol ones
09:53DPA: MrCooper: I know that it is here now. That doesn't mean it has a future / it'll stay relevant, though. I'm not interested in it. I'll just skip it.
09:54malice: MrCooper: Fair enough, but it still effectively means it's unusable for me :P
09:54MrCooper: which compositor is?
09:55emersion: on sway, `input * accel_profile flat`
09:55malice: Well, all of them kinda, as they all use libinput
09:55malice: emersion: flat accel isn't disabled
09:55emersion: then it's a libinput issue?
09:55emersion: in which case, x112 with libinput has the same issue
09:55malice: Unless it should be and it's broken, cuz I definitely get some garbage with flat
09:55emersion: x11*
09:56malice: emersion: Which is why I use evdev :P
09:56emersion: report libinput bug?
09:56malice: Noone cares, long time known issue by many people
09:56emersion: you care
09:57emersion: it's open-source: people who care write patches
09:57malice: Well, many do, just noone that would do anything about it cares
09:58malice: Or just use xorg
09:59emersion: sure, nobody stops you from using xorg
10:03malice: Well, yeah, for now
10:12tango_: talking of which, I'm experiencing some hard lockups when using the touchscreen in my laptop extensively, and I would like to debug the issue to make at least a proper report upstream, but I don't know where to start, because the hard lockups make it very hard to see what goes wrong
10:12tango_: but this is the wrong channel I think
10:16MrCooper: anyone brave enough to review https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5368 ? :)
10:17emersion: warning, involves x11 :P
10:21karolherbst: airlied: nice
13:16kallisti5: airlied: libpciaccess isn't going away anytime soon is it?
13:16kallisti5: airlied: begining the work to add raw PCI bus access on Haiku.. wanna make sure my work isn't for naught :-)
13:17kallisti5: https://pastebin.com/LqvdcyYy so far so good :-)
13:36kallisti5: https://pastebin.com/21arLRNA even better.
13:48kallisti5: actually.. I don't get why libpciaccess is even involved. I would think that the individual GPU drivers would handle memory mapping, getting VGA ROM's, etc. I must be missing something :-)
13:53imirkin: kallisti5: probably for DRI1-type things?
13:54kallisti5: imirkin: /Data/drm/intel/intel_bufmgr.c:#include <pciaccess.h>
13:54kallisti5: seems like the only consumer is "pciaccess.h" is intel buffer management
13:54imirkin: huh ok.
13:54imirkin: intel doesn't use libdrm_intel :)
13:54jadahl: can I get the driver (e.g module name) from a /dev/dri/cardN or open fd some how?
13:55kallisti5: imirkin: oh.. hell. So why does drm still require pciaccess?
13:55jadahl: or do I have to go via sysfs
13:55imirkin: jadahl: there's a info-style drm ioctl i think
13:56jadahl: hmm, ok, i'll see if I can find them
13:57imirkin: hm... i take that back
13:57imirkin: there's a "unique" value, but that's not the driver name
13:57imirkin: pretty sure modeset figures it out
13:57imirkin: probably using libdrm
13:58imirkin: see how it does that?
13:58imirkin: s/modeset/modetest/
13:58emersion: > jadahl | can I get the driver (e.g module name) from a /dev/dri/cardN or open fd some how?
13:58emersion: drmGetVersion gives you this info
13:59imirkin: right, yes.
13:59jadahl: emersion: alright, thanks, that's what I was going to see if it did
14:00emersion: you can see what kind of info it gives with drm_info
14:00emersion: for me: Driver: amdgpu (AMD GPU) version 3.37.0 (20150101)
14:00emersion: the actual version and date is pretty meaningless
14:01emersion: if you want a list of possible values: https://drmdb.emersion.fr/drivers
14:04vsyrjala: looks like libdrm only uses pciaccess to get the mappable aperture size
14:04vsyrjala: i thought we had a getparam for it, but looks like we do not
14:04jadahl: emersion: the one I needed to compare against was not in that list
14:04jadahl: i'll submit it though
14:08emersion: ahah, thanks :)
14:09jadahl: emersion: should be in some inbox somewhere
14:10jadahl: ah already there
14:12emersion: which driver is it?
14:12jadahl: qxl
14:14emersion: ah, this one :) https://drmdb.emersion.fr/devices/ac253e19900c
14:14jadahl: yepp
14:15kallisti5: imirkin: I opened https://gitlab.freedesktop.org/mesa/drm/-/issues/44 for feedback. That would completely drop the libpciaccess requirements from drm
14:22kallisti5: imirkin: ok.. that seems like a half-truth. i915 uses libdrm_intel :-)
14:23imirkin: yeah, but no one uses i915, so ... :p
14:23kallisti5: lol
15:08seanpaul: narmstrong: would you mind taking a look at the ti-sn65dsi86 bridge patches on the list from Doug Anderson?
15:09narmstrong: seanpaul: yep on my todolist
15:09seanpaul: narmstrong: thanks!
15:48kallisti5: unpopular opinion: Mesa should drop i915 :-)
15:51kisak: kallisti5: want it to happen? build a better driver, with all the annoying bits removed and otherwise has feature parity
15:54kallisti5: kisak: sure.. but i915 devices are Pentium 4 era
15:54kallisti5: They're really not even useful in modern workloads.
15:54kallisti5: so.. why?
15:58vsyrjala: my "modern" workloads work pretty well on those. also i think you can have even core2 cpus on gen3 chipsets
15:59kallisti5: vsyrjala: Core 2 was i965
15:59kallisti5: was -> is
16:01vsyrjala: i think there are 945 things which support core2
16:02vsyrjala: also there is bearlake, which i think is even core2+
16:02vsyrjala: or rather core2 only
16:03kallisti5: ugh. yeah. Seeing i965 in the i915 drm code as well.
16:05kallisti5: i'm still under the opionion that a $2 graphics card from a goodwill can provide more horsepower, but yeah.. reaching into core 2 generation is problematic for dropping i915
16:08imirkin: kallisti5: i965 used to use libdrm_intel
16:08imirkin: but afaik does not anymore
16:09kallisti5: imirkin: you know if there's a trend of moving away from libdrm across the board? I see all the other modern drivers still depend on it
16:10imirkin: i think amdgpu doesn't use it either
16:10imirkin: and freedreno dropped it?
16:10imirkin: to be clear, i mean libdrm_*
16:10imirkin: libdrm itself is still used
16:10imirkin: since it has nice wrappers for stuff
16:11imirkin: i really want to move away from it for nouveau too
16:11imirkin: but -ENOTIME
16:11imirkin: (plus it's hard)
16:16agd5f_: we still use some of the stuff in libdrm_amdgpu
16:17kallisti5: agd5f_: yeah, the other stuff is fine. I mostly singled out i915 due to it being the sole consumer of libpciaccess
20:44anholt_: daniels: getting a lot of ooms from windows today
21:26kusma: anholt_: I guess I should send out my patch that swithes to release-builds... it seems writing PDB-files is usually what OOMs...
21:26kusma: (well, release but with asserts enabled etc)
21:27kusma: https://gitlab.freedesktop.org/kusma/mesa/-/commit/dddbbe194c1f7b3c92c59b789225247deee96ce5
21:29kusma: hmm, seems we already got that on master
21:30kusma: Then I guess the only option is to buy bigger internet clouds.
21:40karolherbst: imirkin, pepp: imageAtomicIncWrap seems to be defined as it if it would return the stored value + 1, is this correct?
21:40karolherbst: because normally atomic operations return the old value
21:42imirkin: i just remember it's confusing.
21:42imirkin: that's all i can say for sure
21:42karolherbst: and it seems we have no test checking the return value
21:49pepp: karolherbst: there is piglit/tests/spec/ext_shader_image_load_store/image_functions.c
21:49karolherbst: pepp: I was refering to the return value of that operation. this test only checks the in memory value, no?
21:50pepp: karolherbst: ah sorry, misread your msg
21:50airlied: karolherbst: if I say structurize do you run away? :-)
21:50karolherbst: airlied: yes
21:50karolherbst: :p
21:50karolherbst: It's on my todo list...
21:51karolherbst: _but_ it's also publicly available and everybody is free to take care of the reviews :p
21:52airlied:only asks because lots of my lvl0 fails mention cfg :-P
21:52pepp: karolherbst: the spec says " and returns the original value read."
21:52karolherbst: pepp: yep
21:52karolherbst: but the TGSI doc say somethign differently
21:55pepp: karolherbst: you're refering to "dst_x = resource[offset] + 1"?
21:56imirkin: karolherbst: i just wrote stuff in the tgsi doc based on my understanding
21:56karolherbst: pepp: yes
21:56imirkin: and/or based on copy/paste :)
21:56karolherbst: imirkin: yeah.. I mean.. we don't know it anyway :p
21:56karolherbst: because nobody tests it
21:57karolherbst: just wondering _if_ somebody actually tested it or if it's just written there
21:57pepp: karolherbst: the dst_x is supposed to be the return value?
21:58karolherbst: normally we write "dst.x" but yes
22:00pepp: ok, I wasn't aware of this. So this is my mistake when I wrote this doc :-/
22:00karolherbst: okay.. I was just a bit confused as it could have been that all hw returns the old value + 1 indeed
22:01karolherbst: which then... makes the doc look very nice if fixed
22:01karolherbst: resource[offset] = dst_x < src_x ? dst_x + 1: 0
22:01karolherbst: sameish as dec_warp
22:12karolherbst: pepp: I am not even convinced the piglit test is correct
22:13karolherbst: so uhm.. why does imageAtomicDecWrap do value = wrap; and not value = wrap - 1;?
22:21karolherbst: ehh..
22:21karolherbst: it even fails to compile with the nvidia driver
22:21karolherbst: Failed to compile fragment shader: 0(6) : error C1115: unable to find compatible overloaded function "imageAtomicIncWrap(struct iimage1D1x32_bindless, int, int)"
22:32karolherbst: pepp: yeah.. so all of the incwrap and decwrap tests fails with the nvidia driver
22:32karolherbst: (don't even compile, but that's a minor problem: signed vs unsigned
22:40karolherbst: mhhh
22:40karolherbst: I am trying to fix it all
22:49karolherbst: ehh..
22:50karolherbst: with nvidia I get always 0 returned ...
22:55karolherbst: imirkin: any idea why in the ./bin/ext_shader_image_load_store-image_functions test I only get 0 as a result from the shaders?
22:55karolherbst: with the nvidia driver that is
23:00imirkin: no, and can't look at it now, sorry
23:23karolherbst: hehe.. nvidia isn't 4.5 compliant
23:23karolherbst: don't support imageAtomicExchange (float data)
23:23imirkin: more likely our tests are subtly busted
23:24karolherbst: maybe...
23:24karolherbst: error C1115: unable to find compatible overloaded function "imageAtomicExchange(struct image2D1x32_bindless, ivec2, float)
23:24imirkin: that came in via ES3_1_compatibility, right?
23:24karolherbst: 4.5
23:24imirkin: right, which is part of 4.5
23:24imirkin: try enabling that ext, see if nvidia changes its tune
23:25imirkin: i.e. #extension GL_ARB_ES3_1_comptability: require
23:25imirkin: but spelled correctly =/
23:25karolherbst: nope
23:25karolherbst: ahhh
23:25karolherbst: still nope
23:26karolherbst: but still
23:26karolherbst: "#version 450" should be enough
23:27karolherbst: anyway.. just wanted to abuse this file for the wrap testing :D
23:27karolherbst: just noticed it doesn't compile
23:28karolherbst: imirkin: normally nvidia also tells which ext to enable
23:29imirkin: heh
23:29imirkin: that's weird
23:30imirkin: can i see the full shader?
23:30karolherbst: imirkin: https://gist.github.com/karolherbst/c27b428d582b16012191207f7a2d1a3f
23:31imirkin: seems right!
23:31karolherbst: they are happy with the int version :p
23:31karolherbst: yeah
23:31karolherbst: I guess I found a bug :p
23:31imirkin: i forget if atomic images have to be declared somehow differently
23:32karolherbst: if I change it to iimage nvidia accepts it
23:33karolherbst: I am still more annoyed by the fact that the atomic tests don't to anything
23:33imirkin: fun.
23:33karolherbst: yeah.. image reas 0
23:33karolherbst: even though I put an imageStore with a constant value into the shader
23:33karolherbst: probably some missing barrier or flush or.. something super subtle
23:34karolherbst: dhajsdajkdhjkwhdkjhfsk!
23:34karolherbst: the heck
23:35karolherbst: at least now I get random values
23:35karolherbst: :D