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