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