00:06 Kayden: 2+ hours to merge patches is kinda brutal
00:08 airlied: Kayden: as long as we can trust the bot, does the time matter that much?
00:09 anholt_: it'll definitely clear out over north america night
00:09 anholt_: but we could really use some more capacity. not having any dedicated to mesa is unreasonable given the scale of investment we have in developers.
00:15 Kayden: it doesn't really, just landing some bug fixes and having people ask where they can get them, and....would be able to say 'everything is in master' and instead I have to tell people to cherry-pick random things for a bit longer
00:21 tarceri: anholt_: marge bot can take 6 hours to merge?
00:22 anholt_: tarceri: if an unblocked CI run takes 20 minutes, that would be a whole lot of MRs approved at once. but if that was happening, I would assume that fd.o is just lacking runner capacity
00:24 tarceri: the last few mr say they were added to margebot 6 hours ago
00:26 anholt_: yep. fd.o is strapped for runner capacity and we desperately need our own pool so we can get the (looking at marge's activity) 30 minute turnaround time down.
00:27 anholt_: if someone can make sense of how to deploy https://gitlab.com/andreasmk2/sisyphus I'll try that and have google give us several large machines' worth of capacity.
00:27 anholt_: but I would also love to see this overhead spread across companies.
00:29 anholt_: the alternative to that one that we should look at is the deprecated but suspiciously-still-used-by-gitlab.com docker-machine mode.
00:29 anholt_: the autoscaling docker-machine mode means more lukewarm ccaches, unfortunately.
00:30 anholt_: oh, docker-machine was no good for preempt, though. so 4x the cost.
00:31 imirkin: feels like there might be irony in a project called sisyphus being difficult to deploy...
00:32 imirkin: just as you think you got it, the rock just rolls down the mountain again
03:54 anarsoul: anholt: so you actually were right yesterday, I compared shaders myself and there's difference in VS
03:54 anarsoul: and it starts after nir_opt_constant_folding()
03:55 anarsoul: which incorrectly folds 1(int) * 4.0(float) into 0 instead of 4 (int)
03:55 anarsoul: sailfish folks are using ancient gcc - 4.9
03:55 anarsoul: I wonder if some builtins are not implemented in gcc-4.9 and our fallback is buggy
03:56 anarsoul: jekstrand: ^^
03:59 jekstrand: anarsoul: Weird
03:59 anarsoul: jekstrand: compare nir_print.txt and out.notabs from here: https://gitlab.freedesktop.org/lima/mesa/issues/127#note_390392
03:59 gitbot: Lima issue 127 in mesa "Lima fails with white screen in master. 19.1 is ok" [Opened]
03:59 jekstrand: anarsoul: Can you show me the actual NIR? That operation isn't possible.
03:59 anarsoul: jekstrand: see above
04:00 anarsoul: nir_print.txt is broken, out.notabs is working
04:01 anarsoul: line 8908 is the first difference besides whitespaces
04:01 anarsoul: (use vimdiff :P)
04:02 jekstrand: anarsoul: I see the mul. The fact that you ended up with 1u * 4f is bogus
04:02 jekstrand: anarsoul: Likely something trying to get rid of integers too soon
04:02 anarsoul: but it didn't get yet to int_to_float pass :\
04:02 anarsoul: it's way below
04:03 jekstrand: Yeah
04:03 jekstrand: Something's going sideways though
04:03 jekstrand: Maybe some pass is generating floats when it shouldn't be?
04:03 anarsoul: let's check where ssa_126 is coming from...
04:04 anarsoul: ah, lima_nir_lower_uniform_to_scalar
04:04 anarsoul: turns out to be my bug
04:04 anarsoul: :)
04:06 anarsoul: jekstrand: thanks!
04:07 jekstrand: heh :)
04:09 anarsoul: I wonder why it works with newer gcc though
04:09 jekstrand: I recommend valgrind
04:10 anarsoul: jekstrand: already did last weekend, nothing suspicious
04:11 jekstrand: :(
04:13 anarsoul: ouch, now I need to get rid of ishl :\
04:13 jekstrand: What's wrong with ishl?
04:14 anarsoul: looks like it tries to optimize imul via ishl, we don't support shifts (nor integer) in lima
04:14 anarsoul: I wonder where it's coming from...
04:16 anarsoul: aha, that's from _nir_mul_imm()
04:17 anarsoul: which shouldn't probably emit nir_ishl if we have lower_bitops set
07:26 MaxLeiter: imirkin_: I do think it's a GL bug; DESTDIR isn't including the DRI so file
07:27 MaxLeiter: it creates a package config file for it but the file the config points to doesnt exist
07:36 MaxLeiter: the dri drivers are moved by a custom script, but im not sure if its intentional or not to not run
08:25 cheakoirccloud: I keep getting lockups on my 2700u vega10. About 2/3s the time booting is halted prior to the text "flashing"
08:26 cheakoirccloud: Magic sysreq works, but the logs end prior to showing anything important.
08:26 cheakoirccloud: For both lockups.
08:27 cheakoirccloud: I can't upgrade kernels or I loose networking.
08:29 cheakoirccloud: Running the latest ~mid Nov bios.
08:30 cheakoirccloud: Thinkpad E585
08:50 Venemo: cheakoirccloud: I recommend the #radeon channel if you believe this is a graphics problem.
13:10 imirkin: MaxLeiter: libGL has a built-in assumption about where the foo_dri.so drivers are
13:10 imirkin: this used to be easily controllabel with autoconf, iirc a request to make it configurable for meson was also implemented
13:20 MrCooper: imirkin MaxLeiter: meson configure <build directory> -Ddri-drivers-path=<path> (defaults to <prefix>/lib/dri)
14:13 notafile: not sure if this is the right place to ask (last message in #dri was march...), but is there any way to tell a connector to rescan it's edid from userspace for debugging?
14:21 agx_: I have a DSI LCD panel with an integrated I2C touch controller. Unfortunately those two share the reset line so the panel can't be reset without messing up touch and vice versa.
14:23 agx_: is there another way to sync those two besided using mfd?
14:23 agx_: and would that even be possible when the panel is mipi_dsi_device (and not a platform_device)?
14:25 mripard: agx_: the reset controller framework has support for shared reset lines
14:26 mripard: so you probably want to expose that constraint through that framework somehow
14:33 robher: sravn: are you going to commit the big schema conversion or want me to?
14:41 agx_: mripard: good idea, i'll try that.
14:42 agx_: mripard: thanks!
14:51 hakzsam: daniels: https://gitlab.freedesktop.org/hakzsam/mesa/-/jobs/1438245 seems stucked?
14:52 mripard: agx_: you're welcome :)
14:54 agx_: seems reset-controller does not seem to give me enough rope. Issue is that things need to be ordered: bring up lcd, bring up touch and shut down touch, shut down lcd.
14:54 agx_: so e.g. when we disable the screen we'd need to bring down touch first to make that part not go crazy.
14:55 mripard: I guess you need an mfd then :/
14:55 agx_: if lcd/dsi basically has the master reset line that is needed to initialize the panel but also resets touch.
14:56 mripard: and it's not even on the same bus?
14:57 mripard: I guess the panel is using DSI / DCS, while the touchscreen i2c?
14:57 agx_: mripard: no, touch is i2c while the panel is all dsi
14:57 agx_: so yes, not even on the same bus ;)
14:57 notafile: (I answered my own question by finding echo "detect" > /sys/class/drm/card0-DP-2/status. Sidenote, bless btftrace)
14:58 agx_: mripard: they only seem to share regulators and gpio for reset
14:58 daniels: hakzsam: thanks for the heads-up - one of the controllers was having some issues earlier so it's only just come back online
14:58 mripard: agx_: so an mfd device won't help i guess
14:59 mripard: iirc it's based on the assumption that the device is on the same bus
14:59 mripard: didn't the RPI had something somewhat similar?
14:59 hakzsam: daniels: should I restart that job?
15:00 daniels: hakzsam: no, it's queued in lava and will come back in very soon
15:00 hakzsam: okay, thank you
15:03 ajax: notafile: # echo detect > /sys/class/drm/<blah>/status
15:04 ajax: notafile: where <blah> is the card/output combo you want to reprobe
15:08 mripard: agx_: that's what I had in mind
15:08 mripard: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c
15:08 mripard: so it's pretty different from what you were describing still
15:09 agx_: mripard: i just looked at that, it gave me some ideas that i can try, thanks!
15:09 agx_: i'll see if it works out.
16:26 sravn: robher: on my todo list for tonight, together with a few other pending patches
16:27 sravn: robher: and thanks for feedback on panel-timing. The proposal you made did not fly but I will experiemtn a bit more. And in the meantime the license is sorted out
16:32 robher: sravn: The 'not' proposal I assume? What you had is probably a bit clearer anyways.
16:33 sravn: robher: yep. My examples did not pass - but have not looked to much into it yet. Also need to address feedback from mripard before I resubmit
16:58 MrCooper: tomeu: hrm, the arm build jobs are taking >= 10 minutes now, delaying the corresponding test jobs...
18:07 kisak: robclark: friendly note that https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3514 does not have your r-b in the commit message, that needs to be added manually
18:07 gitbot: Mesa issue (Merge request) 3514 in mesa "freedreno/drm: Don't miscalculate timeout" [Freedreno, Opened]
18:08 krh: cwabbott: super interesting MR
18:08 robclark: kisak: yeah, we're not doing that ;-)
18:09 robclark: re-pushing seems to re-trigger CI, plus it is a manual step.. so until someone figures out how to make marge-bot do it, we just rely on the link back to the MR
19:08 dcbaker: flto: I'm looking at patches nominated for stable that don't apply, and your "Don't lower YUV" patch is on that list
19:28 flto: dcbaker: did you see https://gitlab.freedesktop.org/mesa/mesa/issues/2376? I think you should just not include the patch in 19.2/19.3 (etnaviv users who care about the patch are already aware of it/using it)
19:28 gitbot: Mesa issue 2376 in mesa "!1896 broke ext_image_dma_buf_import piglit tests with radeonsi" [Radeonsi, Regression, Util, Opened]
19:28 dcbaker: flto: I didn't see it, but thats an easy resolution
19:32 Sesse: hi. I'm trying to track down an ABI break in a library. is it possible that GLsizeiptr chaned definition in some fairly recent mesa version?
19:32 Sesse: changed
19:33 imirkin_: sounds familiar, actually
19:33 imirkin_: but it would have been between two semi-identical types
19:33 Sesse: yes
19:33 Sesse: but from ptrdiff_t to long
19:33 Sesse: and ptrdiff_t is defined as int on i386
19:33 Sesse: => different C++ name mangling...
19:33 imirkin_: delightful
19:34 Sesse: seemingly affects arm, too
19:35 Sesse: and mipsel, but well, who uses mipsel anymore :-)
19:35 imirkin_: you're right - mipsbe -- much more popular :p
19:35 Sesse: =)
19:35 Sesse: I'm actually writing mipsel assembler these days, but for retrocomputing
19:35 Sesse: so not really comparable
19:36 Sesse: so is there anything I can do about this, short of rebuilding the library with a different soname, and then recompile all dependencies?
19:36 Sesse: can I file a mesa bug and get it changed back?
19:37 Sesse: (which would then presumably break libraries compiled in the meantime)
19:37 imirkin_: Sesse: so ... here's what i see
19:37 imirkin_: include/GL/glext.h:typedef khronos_ssize_t GLsizeiptr;
19:37 Sesse: yes, that's the new definition
19:37 imirkin_: typedef signed long int khronos_ssize_t; except for _WIN64
19:37 Sesse: let me try to git blame
19:37 Sesse: f7d42ee7d319
19:38 Sesse: include: update GL & GLES headers (v2)
19:38 Sesse: v2: use correct files
19:38 Sesse: used to read
19:38 Sesse: -typedef ptrdiff_t GLsizeiptr;
19:38 imirkin_: right.
19:38 Sesse: so I guess the real commit lies elsewhere
19:38 Sesse: this was just the import into mesa
19:38 imirkin_: these are KHR-controlled files.
19:38 imirkin_: yes
19:38 Sesse: the date of july 2018 confuses me, though
19:39 Sesse: this entered debian at some unknown point in second half 2019, I'm quite sure
19:39 imirkin_: well, commit date != date that debian picks up the code
19:39 imirkin_: in my head, debian is like 10 years behind, so this seems way ahead of schedule
19:40 Sesse: dunno, 19.3.2 now :-)
19:40 Sesse: so 14 days behind at most
19:40 karolherbst: mhhhh, if that's an ABI breakage, it has to be reported to khronos
19:40 Sesse: karolherbst: if it's not an ABI breakage, it causes ABI breakages
19:40 Sesse: which could be argued to be a different thing, of course
19:41 imirkin_: moral of the story is ... don't use GL types for your C++ functions :p
19:41 karolherbst: the OpenGL ABI has to be stable for obvious reasons
19:41 Sesse: karolherbst: yes, but the OpenGL ABI is C, so it only cares about the underlying type being the same amount of bits
19:41 karolherbst: changing type definitions aren't that uncommon, but usually the data size stays the same
19:42 karolherbst: Sesse: doesn't change the fact that if khronos change something which breaks on some platforms it's a bug caused by khronos
19:42 Sesse: I guess
19:42 Sesse: do they have a bug tracker, or do you need to be a member?
19:42 karolherbst: imagine the ABI breaks and every game keeps crashing ;)
19:44 Sesse: maybe I should just add an overload for both int and long, and then we're done with it...
19:45 imirkin_: the GL abi didn't chagne though
19:45 imirkin_: the bug is that someone imported this, and then used it for *their* ABI
19:45 imirkin_: "don't do that"
19:46 karolherbst: imirkin_: is sizeof(ssize_t) == sizeof(ptrdiff_t) always true?
19:47 imirkin_: ssize_t? probably not. but khronos_ssize_t? yes.
19:47 imirkin_: but c++ sticks type names into their abi's
19:47 karolherbst: ohhhh
19:47 karolherbst: signed vs unsigned
19:47 karolherbst: ufff
19:48 Sesse: not signed, just that int and long are distinct types
19:48 imirkin_: while C is like "you even have a type? go you! i'll go right ahead and ignore it"
19:48 Sesse: even on platforms where they are the same length
19:48 karolherbst: ufff
19:48 karolherbst: ufff
19:48 imirkin_: which goes back to ...
19:49 imirkin_: "don't use other people's headers to define your own ABI"
19:49 karolherbst: right
19:49 karolherbst: use stdint.h :p
19:49 imirkin_: right. i mean if stdint.h changed, i could see a reasonable argument for complaining
19:49 karolherbst: yeah
19:49 karolherbst: I have no pity for devs using non stdint.h types in their APIs for ints ;)
19:50 imirkin_: (and non-core types, presumably)
19:50 Sesse: imirkin_: so this function is a utility function for “please create a VBO for me”
19:51 Sesse: it's not easy to say what the size of a VBO should be, if not GLsizeptri
19:51 Sesse: GLsizeiptr, sorry
19:51 imirkin_: Sesse: ssize_t? :)
19:51 Sesse: imirkin_: is GLsizeiptr signed or unsigned?
19:52 imirkin_: Sesse: signed, it woudl seem
19:52 imirkin_: for reasons that aren't clear to me
19:52 Sesse: :-)
19:52 imirkin_: but none of that matters, it's just a pointer-width integer
19:52 imirkin_: however you want to represent that in your ABI is fine
19:52 imirkin_: note that some of this stuff also varies by platform
19:52 Sesse: ick
19:53 imirkin_: e.g. it's one thing on apple, but another thing on ... not-apple
19:53 imirkin_: i forget what. maybe even GLsizeiptr :)
19:55 imirkin_: i think there have been some changes to how those headers work
19:55 imirkin_: they used to include a driver-supplied glplatform.h file or whatever, but now there's the KHR-supplied khrplatform.h
19:55 Sesse: mm, ok
19:55 imirkin_: heh. #ifndef WIN32_LEAN_AND_MEAN
19:55 Sesse: :-D
19:56 imirkin_: although ....
19:56 imirkin_: yeah, no, nevermind.
19:58 imirkin_: Sesse: put it this way ... let's say you #include libxml.h, and they define a XMLfootype, and then you use that in your ABI, and then they change it (even potentially bumping up their internal APIs), would you complain?
19:59 imirkin_: it is an interesting question as to what libxml++ should do though
20:04 Sesse: imirkin_: probably not for any random XMLfootype, but integer typedefs are sort of a special case -- they are meant for portability, and it's generally intended that you will use them where you can
20:06 Sesse: imirkin_: but GLsizeiptr is one thing; what if GLenum changes the same way? surely I must be able to make OpenGL wrappers that take in GLenum?
20:07 imirkin_: Sesse: yeah, the wrapper thing is an interesting question, where you want the wrapper to use the original types
20:08 imirkin_: i don't have a strong idea of what should be recommended there
20:08 imirkin_: maybe "live with the abi breaks"
20:08 Sesse: maybe
20:08 imirkin_: "rev early, rev often"
20:09 imirkin_: it's really the c++ name mangling that's the unfortunate thing here
20:09 imirkin_: since there's no _real_ abi break
20:09 Sesse: yes, this is an unfortunate thing
20:09 Sesse: my personal take on this is that you should never, ever use the “long” type
20:10 imirkin_: unless followed by "double" :)
20:10 Sesse: :-)
20:10 imirkin_: yeah, there's obviously some history there
20:10 imirkin_: but nowadays, stdint.h works well
20:10 Sesse: yes
20:10 Sesse: _finally_ msvc started supporting it
20:10 Sesse: but that's only, like, 3 years ago
20:10 imirkin_: yeah
20:11 Sesse: that doesn't solve name mangling, though
20:11 Sesse: int64_t could easily become long below
20:11 karolherbst: pro tip: don't use broken compilers :p
20:11 imirkin_: or broken languages :p
20:11 imirkin_: is the c++ name mangling thing mandated by standard?
20:12 karolherbst: of course not
20:12 Sesse: overloading is
20:12 imirkin_: or did that just become the thing on linux?
20:12 Sesse: and there's no reasonable way to do overloading unless you do some form of name mangling
20:12 imirkin_: hmmm
20:12 Sesse: I mean, even C has adopted overloading now
20:12 karolherbst: imirkin_: the way you mangle is vendor specific ;)
20:12 Sesse: just in a very hackish, incomplete way
20:12 karolherbst: that's why icc has a gcc mode
20:12 imirkin_: and you can have foo(signed) and foo(unsigned), right?
20:12 Sesse: yes
20:12 Sesse: just like C now has a sin(float) and a sin(double)
20:12 imirkin_: can you have foo(GLsigned) if it's a typedef to signed?
20:12 Sesse: yes
20:13 Sesse: so what matters for overload resolution is the underlying type
20:13 imirkin_: and it's separate from foo(signed)?
20:13 Sesse: no
20:13 Sesse: overload resolution looks through typedefs
20:13 imirkin_: ah ok
20:13 karolherbst: it decodes the sign + size essentially on gcc
20:13 Sesse: karolherbst: no
20:13 Sesse: int is distinct from long
20:13 Sesse: even if they're the same size
20:14 karolherbst: mhhh, right, I forgot
20:14 imirkin_: there's a lot of "unfortunate" going around there
20:14 imirkin_: coz you can't make them the same, since then you'd break real code
20:14 Sesse: yes
20:14 imirkin_: which might have long/int specializations
20:15 imirkin_: moral of the story - you want graphics? use turtle.
20:15 imirkin_: (or what was that thing called... logo)
20:15 imirkin_: no linkage issues there :)
20:16 Sesse: what can I say, I have used logo
20:16 karolherbst: ahhhh.. right turtle..
20:16 karolherbst: even I remember that
20:17 Sesse: but OK, I went with the “implement both ABIs” option:
20:17 Sesse: klump:~/nmu> nm --dynamic --demangle /usr/lib/x86_64-linux-gnu/libmovit.so.8 | grep generate_vbo
20:17 Sesse: 0000000000024940 T movit::generate_vbo(int, unsigned int, int, void const*)
20:17 Sesse: 0000000000024840 T movit::generate_vbo(int, unsigned int, long, void const*)
20:17 Sesse: which can stay until the next soname bump
20:18 karolherbst: int/long/... was a mistake
20:18 karolherbst: still is
20:18 Sesse: long was the biggest mistake
20:18 Sesse: a type that might be longer than int, but not always is, and isn't even guaranteed to hold a pointer
20:18 karolherbst: then int is a mistake as well
20:19 Sesse: int at least used to mean something useful (the fastest type on the system)
20:19 karolherbst: actually
20:19 karolherbst: long is bigger than int
20:19 karolherbst: int can be the same as short
20:19 karolherbst: long has to be 32 bit at least
20:19 Sesse: long does not need to be bigger than int
20:20 karolherbst: int can be 16 bit
20:20 Sesse: it can be bigger, and it can be the same size if int is 32 bits
20:20 karolherbst: sure, but long is at least 32 bit ;)
20:20 Sesse: sure
20:20 karolherbst: short and int are at least 16 bit
20:20 karolherbst: long long is at least 64 bit
20:20 karolherbst: so.. which type is the mistake now ;)
20:20 Sesse: which is exactly what I said: “a type that might be longer than int, but not always is”
20:21 karolherbst: well, that's what C says for every int type except char
20:21 Sesse: int might not be longer than int =)
20:21 Sesse: neither might short
20:22 Sesse: but the C standard is one thing, there are real platforms where it's not
20:22 Sesse: for windows, long is 32
20:22 karolherbst: which is valid
20:22 Sesse: sure
20:22 karolherbst: and what the standard mandates to be the minimum
20:24 karolherbst: the most broken type is still char by far
20:24 karolherbst: everything is broken there
20:28 imirkin_: Sesse: when is long not guaranteed to hold a pointer?
20:28 Sesse: imirkin_: on windows
20:28 imirkin_: srsly??
20:28 Sesse: yes
20:29 Sesse: long is 32, pointers are 64
20:29 imirkin_: in win64, long = 32?
20:29 Sesse: yes
20:29 Sesse: it's P64, not LP64
20:29 Sesse: because that's how alpha was and that's the first 64-bit windows port, or something
20:29 imirkin_: i'll try to remember that ... i see this sort of thing taking me ages to figure out on my own when debugging
20:29 imirkin_: kinda like how "byte" in java is actually signed.
20:30 urjaman: or more like "people wrote a lot of code assuming long=32 so we'll keep it"
20:30 urjaman: (i think that's how it has been all the way from 16-bit windows...)
20:31 urjaman: where it makes sense
20:31 imirkin_: ah the good ol' days. word = int = 16, dword = long = 32
20:32 imirkin_: and typeof(void *) != typeof(void far *)
20:32 karolherbst: well, it's a different pointer :p
20:32 Sesse: and function pointers can have distinct sizes
20:33 imirkin_: i still remember discovering farmalloc - that was huge. i had all kinds of things that needed like ... a little more than 64K
22:40 ParkerR: So Im testing out Zink. Some programs Im testing (Steam games) refuse to work via terminal so I could see if its being used/working. I tried enabling the mesa vulkan overlay to see stats but that isnt working. I assume these just don't work together?
22:40 ParkerR: MESA_LOADER_DRIVER_OVERRIDE=zink VK_INSTANCE_LAYERS=VK_LAYER_MESA_overlay VK_LAYER_MESA_OVERLAY_STATS=submit,draw,pipeline-graphics glxgears
22:40 ParkerR: *so I can't see
22:41 ParkerR: This is with mesa aco from master