00:09 imirkin: piglit + libcaca = awesome. just want to say that for the record.
00:13 robclark: heh, now that's a unique workflow
00:13 imirkin: i'm ssh'd in, want to see what it looks like, don't want ot mess with fancy graphics
00:15 robclark: yeah, it would be nice if piglit had something like testlog_to_xml with result imgs and deltas.. that plus 'python -m http.server' is a good way to work remotely
00:15 imirkin: could it be better? https://i.imgur.com/f5xKDJF.png
00:15 imirkin: "the clipping works"
00:15 imirkin: what more do i need to know
03:00 Kayden: piglit+libcaca has been surprisingly useful
03:00 Kayden: piglit does have a -png option to write a .png file if you need one of those, too. but if the test draws 0 in the alpha channel it's kind of hard to see. :)
04:10 anholt__: sphinx, really? https://stackoverflow.com/questions/40032601/why-is-toctree-not-updating-with-rtd-theme
04:12 anholt__: (basically, you need to clean build every time or you'll have broken table of contents on files not involved in the change)
05:25 daniels: ajax: have you seen the Weston vkms CI?
05:34 danvet: daniels, uh what where?
05:34 danvet: aside from "yuahhaaaa!" :-)
05:35 daniels: https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/436
05:38 danvet: nice
05:38 danvet: ivyl, mupuf ^^ for igt too?
05:41 mupuf: Same reaction as daniel on my side!
05:42 daniels: :)
05:42 daniels: we ultimately want to get to the full flying-car future of error injection, which I think probably involves ebpf
05:42 daniels: but today is not (quite) that day
07:27 MrCooper: tomeu: not offhand; I'd try comparing the list of installed packages between working & broken image
07:45 danvet: daniels, so you'll have someone working on adding more features to vkms?
07:45 danvet: with maybe something like configfs to set up the fake hw, and ebpf for atomic_check lolz?
08:14 daniels: well, that's the plan, but I'm not sure when we'll get to it tbh. the internship is mostly around testing planes through WB connectors
08:23 MrCooper: mattst88: note that this likely isn't just a one-time issue; even if a full xserver release works out this time, we don't want to wait another 2+ years for the next major Xwayland release
08:45 mripard: narmstrong: it looks e860785d5730665e04e0ac301aa14ed3779c4d92 has broken the build
08:56 dj-death: is there a reason that we don't allow nir_lower_io_explicit_io() to operates on derefs of uniform variables?
09:01 MrCooper: tomeu: actually, I think it's likely due to "Mesa 20.2.0-devel\$" not matching anymore, because git is now installed for the builds
09:01 MrCooper: best fix would be to match the commit hash as well
09:01 tomeu: ooh, I think that happened to me once
09:02 tomeu: thanks, you saved me quite some time
09:02 tomeu: will look at that
09:02 MrCooper: no worries, glad I thought of that :)
09:08 narmstrong: mripard: hmm, I only have an error in libfdt.... can you share the build issue ? maybe a more recent compiler triggers it ?
09:11 MrCooper: tomeu: I guess for next time something like this happens, it would be nice if that failure produced explicit diagnostics...
09:11 tomeu: yeah, will look at that
09:12 MrCooper: awesome, thanks
09:16 mripard: narmstrong: https://pastebin.com/BaZYmiZ7
09:18 mripard: with gcc 9.2
09:27 narmstrong: mripard: interesting, it's an error on 9.2
10:01 narmstrong: mripard: can you share your drm-misc-arm_defconfig ? multi_v7_defconfig with `arm-none-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 9.2-2019.12 (arm-9.10)) 9.2.1 20191025` doesn't fail
10:04 mripard: narmstrong: you have it already :)
10:04 mripard: drm-rerere/drm-misc-arm_defconfig
10:12 narmstrong: mripard: hmm still can't reproduce
10:50 mripard: narmstrong: I don't really know what is going on here, I don't know the meson driver, but it looks like the value you put in AFBC_DEC_PIXEL_BGN_H and VD_H_START is too large for 13 and 12 bits
10:50 mripard: this looks it depends on runtime stuff though, so I'm not sure how it can make that check at compile time
10:59 narmstrong: mripard: yep I looked the issue and I don’t understand how this check gives this error at compile time, the value is strictly dynamic
10:59 narmstrong: mripard: I’ll try to fix ASAP
11:03 mripard: thanks :)
11:06 pq: eh, Linux 'make htmldocs' just DoS'd my workstation, ate all 8 GB RAM plus another 8 GB or swap before I killed it. How is it supposed to be run?
11:07 pq: *of swap
11:07 karolherbst: pq: make -j1 maybe?
11:07 pq: I'll try that after this machine stops swapping...
11:08 karolherbst: yeah.. and from personal experience, the disc swap is close to useless, due to those DOS issues
11:08 karolherbst: something like zram or zswap are better here
11:08 pq: yes and no... it usually gives me time to kill the offender before OOM-killer starts killing random things
11:09 pq: exactly because it's on spinning rust
11:09 karolherbst: if you are still able to use the machine
11:09 karolherbst: I had situations where processes used up all my available RAM in seconds
11:09 karolherbst: and in this case having a spinning disc is even worse because your machine doesn't react to anything anymore
11:10 pq: I find it contrary
11:10 karolherbst: maybe with a full preemptive kernel it would work out.. dunno
11:11 pq: it still reacts a little bit every few seconds
11:11 karolherbst: mhh.. maybe it's worse with a disc swap on an SSD
11:11 pq: I could imagine that, I never tried
11:12 karolherbst: but yeah.. I don't use any disc swaps anymore because those are just causing more problems than they are worth
11:12 pq: a spinning disk slows things down enough to get some say in between :-)
11:12 karolherbst: and with zram you can still have around twice as much swap as your main RAM
11:12 linkmauve: mattst88, MrCooper, fyi I’ve been running Xwayland master as my daily driver for many months, with no regression that I could see.
11:13 pq: if there was no swap, then IME the machine will be totally stuck, because it will be busy re-reading text portions of programs, so process context switches will never make progress anymore
11:13 karolherbst: pq: but the oom killer never really killed the wrong thing, I think it got really better over the years, but yeah.. with 8GB RAM you are quite limited anyway :/
11:14 pq: something is wrong with the world if 8 GB is "limited" :-/
11:14 karolherbst: for me 16 GB is already limited :p
11:14 HdkR: and here I have 32GB in my low end Intel Ice Lake device :P
11:14 karolherbst: like if you compile llvm with ninja you need more than 16GB to compile it
11:15 karolherbst: or you disable threaded linker jobs :p
11:16 pq: looks like -j1 does not limit sphinx processes
11:17 karolherbst: but I also do a lot of RAM because of file caching mainly, half the RAM should always be the file cache :p
11:17 karolherbst: especially on systems with HDDs having more RAM makes the machine indeed faster
11:17 pq: I think half of my RAM normally *is* file cache :-)
11:17 karolherbst: that's surprising on a 8GB system :p
11:18 karolherbst: I have 8.5GB in active use right now :D
11:18 pq: well, I'm a dev, not an end user
11:18 karolherbst: huh.. why did something get swapped :O
11:18 pq: because running 'make htmldoc' is not normal
11:19 karolherbst: well.. developer use cases usually use less RAM than "end user" stuff :p
11:19 karolherbst: except compiling llvm
11:22 mszyprow|home: danvet, airlied: hi, how would you like to process the "v7 DRM: fix struct sg_table nents vs. orig_nents misuse" patchset ( https://lore.kernel.org/dri-devel/20200619103636.11974-1-m.szyprowski@samsung.com/ )?
11:24 pq: funnily enough, I was totally fine running simply 'make htmldocs' just a few weeks ago.
11:25 pq: ahha, cf08508d21ffae5aea6c7dcb771ebd28612c6120 says to use 'make SPHINXOPTS=-j1 htmldocs'
11:26 karolherbst: pq: ehh... make is so terrible :p
11:27 pq: 29efbb24d992564db4bbb808597719934ed9ac9f implies 'make -j1 htmldocs' should have done the right thing, but I still saw -jauto
11:29 pq: maybe what saved me before was Sphinx being old enough to not implement -jauto
11:31 pq: and it finished building! That was fast.
12:08 danvet: mszyprow|home, haven't much followed it tbh, can the different parts be merged independently?
12:08 danvet: if yes for that, I guess just smash the drm&dma-buf bits into drm-misc
12:09 danvet: well maybe check with amdgpu and i915 maintainers whether that's ok or whether they want to merge to their own tree
12:14 mszyprow|home: danvet: some drivers depends on the drm prime change
12:15 mszyprow|home: danvet: how to process it via drm-misc? should I send a pull-req?
12:16 danvet: mszyprow|home, we have commit rights for that, but looks like you're not in there yet
12:16 danvet: if you want to do a pull and it's all acked already, then that would be direct to airlied&me
12:17 danvet: but imo just smashing it all into drm-misc is usually the easiest
12:17 mszyprow|home: danvet: hmm, the drm prime stuff didn't get any review/comments :/
12:17 mszyprow|home: danvet: and also not all patches got acks
12:18 danvet: do a bit of review trading and done, there's a pile of -misc maintainers around here usually
12:19 mszyprow|home: okay
12:20 pq: danvet, v5 is my final of the device hot-unplug doc. I'll be disappearing for three weeks now.
12:24 danvet: pq, do you have someone to push it to -misc?
12:24 pq: I can probably find someone, if that's what I should do.
12:25 danvet: yeah if you can volunteer someone at collabora that'd be awesome, so I can immediately forget about this :-)
12:25 pq: ok
12:26 pq: so is it ready to be pushed to -misc?
12:36 pq: I suppose, then.
12:44 danvet: yeah that's ready I'd say
12:44 danvet: it's not going to get better outside I think
12:57 danvet: narmstrong, e860785d57306 fails to compile here
12:57 danvet: which kinda sucks
12:57 danvet: no idea what's going on, just gcc is unhappy and I'm confused
12:57 mripard: danvet: welcome to the club :)
12:58 danvet: is there a patch somewhere?
12:58 mripard: we discussed it this morning, and he said he would look into it but he can't reproduce at the moment
12:59 danvet: FIELD_PREP: value too large for the field
12:59 danvet: mripard, you get the same thing?
12:59 mripard: yep
13:02 danvet: mripard, any idea how to coax gcc into printing what it thinks should be there?
13:02 MrCooper: anholt__: can 'export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib' be removed from .gitlab-ci/deqp-runner.sh now that we're patching VK-GL-CTS to not link libkms? (We're also setting the target triple libdir for the libdrm build now)
13:02 mripard: danvet: I have no idea :)
13:03 mripard: what's even weirder to me is that those value are computed at runtime
13:03 mripard: so I don't really know how it can make that check at compile time
13:03 danvet:hacked it up
13:04 danvet: mripard, narmstrong https://paste.debian.net/1155467/
13:04 danvet: I have no idea what gcc is smoking, but at least it's quiet about it now
13:04 danvet: mripard, or do you have a different set of complaints?
13:04 danvet: gcc 9.3 here from debian
13:04 mripard: my favourite part is the commit log :)
13:05 mripard: danvet: I had the same one, with gcc 9.2 from Fedora
13:05 danvet: ok, so at least consistently confused
13:05 narmstrong: danvet: yeah kind of a solution
13:05 narmstrong: danvet: let me do a proper one
13:06 danvet: bbrezillon, atmel is still using it's hand-rolled atomic commit!!!!
13:06 mripard: narmstrong: that will be determined by a jury of your peers :)
13:08 narmstrong: mripard: same hack, but prettier (R)
13:08 narmstrong: danvet: I can't reproduce it with ARM's GCC 9.2, which is weird
13:11 narmstrong: mripard: danvet: https://termbin.com/25rf
13:12 mripard: it's really weird that you only need it for those two though
13:17 danvet: narmstrong, glorious
13:17 danvet: a-b: me
13:19 narmstrong: I assumed FIELD_PREP and GENMASK would never trigger this, but the good ol' masking always worked fine...
13:19 narmstrong: danvet: thx
13:46 bbrezillon: danvet: ping sravn :P
13:47 bbrezillon:should remove myself from the ATMEL HLCDC entry
13:53 TheRealJohnGalt: Over last day any major shader compilation hang radeonsi issues reported on here?
13:53 TheRealJohnGalt: Otherwise I'll bisect myself.
14:08 xuxing: Hi, I just synced mesa code, and found that there is't any code about DRI2SwapBuffers. Do you have any hints about this?
14:13 MrCooper: xuxing: git grep xcb_dri2_swap_buffers
14:18 xuxing: Thanks a lot. It seems the name changed.
14:18 xuxing: MrCooper: It seems the name changed.
14:18 xuxing: MrCooper: thanks a lot!
14:18 MrCooper: XCB is always all lower case, CamelCase is libX11 style
14:28 xuxing: Is there any standalone dri2 example? I noticed that there is Dri2-race.c in xorg-xf86-video-intel package. Do you have any ideas race means what?
14:30 ickle: pretty much CloseWindow vs DRI2 event processing
14:31 ickle: of that set, dri2-test.c is the more understandable
14:31 ickle: and comparable to present-test.c if you want dri3
14:32 xuxing: Thanks. Does DRI3 shipped?
14:33 ickle: yes? was the final vision completed? no. one day maybe XWayland will complete the passthrough
14:34 ickle: but the crystal ball says everything will talk native Wayland long before then
14:34 imirkin: ickle: ouch, so you don't expect the vision to be completed in the next 20 years?
14:35 daniels: xwl does pass through dri3
14:35 MrCooper: ickle: what's "the passthrough"?
14:35 ickle: then I'm mistaken
14:35 MrCooper: xuxing: I'd recommend forgetting DRI2 in favour of DRI3/Present if you can :)
14:36 daniels: looks like that support landed in March 2018
14:37 MrCooper: yeah, shipping in 1.20 and pretty solid by now
14:37 ickle: the plan was that given a compositor, the present request would be forwarded to the compositor
14:38 daniels: which is what it does
14:38 MrCooper: right, that's working if the X11 window geometry allows it
14:38 xuxing: MrCooper: Thanks! I will look into it.
14:39 ickle: daniels: still have the commit id handy?
14:40 xuxing: So DRI3 is OK in X Server? Even buggy
14:40 ickle: less buggy now than the alternatives
14:41 ickle: [within X, before daniels points out that weston has no bugs]
14:41 daniels: ickle: no sorry, but you can look at the history of hw/xwayland/xwayland-present.c
14:41 imirkin: DRI3 allows for some efficiencies, but i don't think DRI2 was ever buggy?
14:42 MrCooper: must be a nice rock you're living under ;)
14:42 xuxing: And the whole stack is implemented? from DRI3 client, DRI3 protocol, DRI3 in X server ?
14:43 imirkin: MrCooper: what were the (long-standing) bugs in DRI2? or do you just mean it didn't support certain things that DRI3 supports?
14:44 imirkin: only thing i can think of that comes close is secondary gpu render offload without a compositor
14:44 karolherbst: imirkin: don't you have to setup prime on the server side with dri2? or is the reason you do those annoying xrandr commands something else?
14:45 MrCooper: pretty much anything is easier & works better with DRI3
14:45 imirkin: karolherbst: sure, but that's not a DRI2 bug, is it?
14:45 MrCooper: more of a design flaw
14:45 imirkin: sure
14:46 imirkin: buggy implies "doesn't work as designed"
14:46 imirkin: anyways, wtvr
14:46 karolherbst: imirkin: well... it also requires you to have the driver loaded before starting X
14:46 imirkin: ok...
14:46 karolherbst: or the device being visible
14:46 imirkin: still not buggy
14:46 karolherbst: like think of eGPUs
14:46 karolherbst: how do you do offloading with a hot plugged GPU under DRI2?
14:46 imirkin: i didn't say DRI3 didn't have advantages over DRI2
14:46 imirkin: i was questioning the claim that DRI2 is buggy
14:46 karolherbst: well.. this sounds like a bug to me :p
14:47 karolherbst: plugging in eGPU, can't use it for rendering -> bug
14:47 FireBurn: How do usb docks with video out ports work?
14:47 imirkin: that's ... not the definition of a bug
14:47 karolherbst: imirkin: why not?
14:47 imirkin: that's the definition of a usability issue
14:47 karolherbst: meh.. same thing
14:47 MrCooper: karolherbst: actually that can work in theory, though currently hot-plugging the GPU will crash in glamor if that wasn't already initialized at server startup
14:47 karolherbst: software doesn't meed my expectation -> bug in the broader sense
14:47 imirkin: ok, but the software in question isn't DRI2
14:48 imirkin: it's X
14:48 imirkin: or whatever
14:48 karolherbst: MrCooper: if the device appears after X started?
14:48 karolherbst: mhhh
14:48 karolherbst: right. X can claim the device still, true
14:48 MrCooper: yeah, via udev
14:48 imirkin: DRI2 is a protocol, and there are implementations of it in both server and client. buggy would imply that those implementations have bugs. not that some high-level end-user use-case doesn't work.
14:49 imirkin: that's like saying UDP is buggy because it doesn't support retransmission
14:49 karolherbst: yeah okay, I see your point
14:50 karolherbst: but then the discussion feels pointless, because in the end it matters what features you can implement on top, not if it's technically correct
14:50 karolherbst: at least in dri2 vs dri3
14:50 MrCooper: even buggy DRI3 could still be superior to perfectly bug-free (as if that was possible :) DRI2 by that definition
14:51 imirkin: now software that uses UDP and expects it to do retransmission would be buggy
14:51 karolherbst: sure
14:51 karolherbst: but UDP allows you to implement retransmission on top of UDP
14:51 karolherbst: and we discuss things you can't implement on top of DRI2
14:51 karolherbst: or maybe you can't
14:51 karolherbst: anyway, that's the point here
14:52 karolherbst: eg.. mesa also accepts this pci- syntax in DRI_PRIME and that's kind of dri3 only as well or not?
14:53 karolherbst: or can you have multiple render offloadable devices with dri2?
14:53 imirkin: not sure. i don't think render offload was ever the point of dri2
14:53 imirkin: if you want good render offload, use dri3
14:53 imirkin: that's why i use dri3 at least :)
14:54 karolherbst: yeah.. not quite sure either how that's even implemented at all, just that with dri3 you can solve a lot of those issues in this area
14:54 imirkin: otherwise dri2 seems universally simpler and less error-prone
14:54 MrCooper: right, DRI2 was invented for handling compositing vs direct rendering correctly, and it worked OK for that at the time
14:55 MrCooper: but then various unfixable flaws in its design became apparent, hence DRI3
14:55 imirkin: right
14:55 imirkin: given new use-cases
14:55 imirkin: like render offload, careful control of what's displayed, etc
14:56 karolherbst: ohh good question, was vsyncing ever bugfree under dri2?
14:56 ickle: render offload was before dri3; limited, but still doable
14:56 ccr: bug was in developers being unable to predict the future? :P better polish your crystal balls.
14:56 MrCooper: yeah, those pesky things are always malfunctioning
14:56 karolherbst: kind of had the feeling that vsyncing only got better since dri3
14:57 karolherbst: or at least compositors used less CPU time to do it correctly
14:57 MrCooper: vsync works fine with DRI2 with a single GPU, but not at all with offloading
14:57 karolherbst: right..
14:58 karolherbst: yeah, maybe it's just that
14:58 MrCooper: also it didn't support more than 2 buffers originally, and extending that was messy
14:59 xuxing: GLX_USE_APPLEGL is for what?
15:00 Y0lk: Hi! Not sure if I'm in the right place, but does anyone here have a good understanding of the llvmpipe limitations? Basically i'm trying to figure out if it's possible to render onto very large framebuffers, like 16384 or bigger.
15:01 karolherbst: Y0lk: my first question would be: isn't that terribly slow? Just wondering.
15:02 karolherbst: most of those limitations should be fixable though, just usually there are hw limitations and there is no point in supporting more in software implementations
15:02 MrCooper: xuxing: Apple's OpenGL infrastructure in Mac OS
15:04 Y0lk: yes most likely, but it actually doesn't matter too much in my case if it's slow. Using it for a cpu-based server-side rendering system.
15:05 Y0lk: I played around in the code and was able to increase the max texture size to use textures of 16384 just fine, but I can't quite figure out what is limiting the framebuffer size
15:10 ajax: daniels: i have not! i'll take a peek.
15:59 alyssa: Rewriting my blit stack (which is currently u_blitter hacks)... can anyone confirm that Vulkan requires preload?
15:59 dj-death: preload?
15:59 alyssa: In GL, if you do `<clear> <render> <flush> <render>`, on tilers we're forced to insert a blit from system memory -> tile memory before the second render (which involves the 3D pipe on older hardware due to an errata)
16:00 alyssa: Does Vulkan allow the same operation? (Rendering without clearing at the beginning and without the application explicitly blitting themselves?)
16:00 dj-death: ah
16:01 dj-death: vulkan has renderpass concept which should wrap the whole clear/render/resolve set of commands
16:01 dj-death: and you can't really "flush" as in glFlush() in the middle of a render pass
16:01 imirkin: alyssa: why do you have to restore tile memory in that scenario?
16:02 imirkin: oh, because you run through all the tiles at that point. duh.
16:02 alyssa: dj-death: but then you still need to implement resolves?
16:02 alyssa: (in the driver, I mean)
16:03 dj-death: alyssa: within the render passes (for us) those are implicit resolves, probably tilers don't need to do any of that
16:04 dj-death: alyssa: explicit clears/resolves/blits happen outside the render passes
16:04 dj-death:back in 10mn
16:04 alyssa: Hmm, right
16:05 alyssa: `LOAD_OP_LOAD` I guess
16:05 anholt__: MrCooper: sounds likely
16:13 xuxing: Do you know where is <xcb/dri3.h>, I want to check xcb_present_pixmap
16:14 anholt__: generally: google that filename plus your distro name, we don't know what you're running.
16:17 MrCooper: xcb_present_pixmap is in xcb/present.h though
16:17 MrCooper: in contrast to DRI2, DRI3 is only about buffer sharing; presentation is handled by a separate Present extension
16:19 xuxing: I didn't find present.h in libxcb
16:21 xuxing: https://packages.debian.org/sid/libxcb-dri3-0 , only binary or code for libxcb. no source for libxcb-dri3
16:22 MrCooper: headers are always in separate *-dev packages
16:22 MrCooper: and source code in source packages
16:23 MrCooper: apt-get source libxcb-dri3-0
16:23 MrCooper: should do the trick (if you have deb-src lines in your apt.conf)
16:24 xuxing: OK, will try that when I got my ubuntu tomorrow
16:24 xuxing: no public git repo for this?
16:24 MrCooper: or just go straight to the mothership: https://gitlab.freedesktop.org/xorg/lib/libxcb
16:26 xuxing: Yes, My libxcb is from this git repo. But no xcb_presnt_pixmap impl
16:26 FireBurn: Is LTO considered supported these days? I'm seeing an issue with vaapi play back if mesa is compiled with LTO with gcc, which is a regression, works fine without lto & works fine with clang lto
16:26 FireBurn: I'm pretty sure it's a regression so will bisect it bit I'm not sure if anyone will care
16:28 anholt__: does anyone know, does LTO care about strict aliasing, or has alias information been lost by that step?
16:28 orbea: if it works with clang, but not gcc, bisecting might reveal undefined behavior. Assuming ofc its not a gcc bug...
16:30 FireBurn: Which is a big if, but everything was recompiled with gcc 10.1 when it was released
16:30 FireBurn: I get different behaviour on my raven machine from my intel one
16:31 MrCooper: anholt__: I don't know, but my assumption would be it can matter
16:31 FireBurn: I get a segfault on the raven system
16:32 anholt__: MrCooper: having recently had to figure out the xxhash aliasing bug, the thought of LTO catching aliasing issues tree-wide is terrifying and I don't want to go anywhere near lto
16:32 FireBurn: https://pastebin.com/x6zWTGXx
16:37 MrCooper: anholt__: I was against enabling strict aliasing in the first place :)
16:38 MrCooper: some of the blackest magic I've ever had to deal with
16:39 FireBurn: Right I'm going to see if I can bisect this
16:40 FireBurn: When was strict aliasing turned on?
16:41 MrCooper: a while ago
16:41 anholt__: 88ad8c7dedb87d92a5bed0868f108076185ec089 (2016)
16:42 anholt__: it's hard, we really hamper the compiler if we don't enable it, but the C language is awful and trying to write code under these conditions is possibly just too hard.
16:44 MrCooper: you know it's hard when someone like Benjamin Herrenschmidt doesn't want to deal with it
16:46 FireBurn: I'm just checking if 20.1.2 worked ok
16:47 MrCooper: maybe somebody should benchmark LTO & no-strict-aliasing vs no-LTO & strict-aliasing :)
16:49 FireBurn: :D
17:10 danvet: bbrezillon, you didn't run fast enough, so tag you're it :-P
17:25 sravn: bbrezillon, danvet: Needs a bit motivation and help, but then I can take a look at the atmel_hlcdc driver
17:26 sravn: Have a board but panel did not work last I played with it. Maybe something trivial but really needs the panel working to test things :-)
17:53 danvet: mripard, your big vc4 series, does that contain the patches to switch over to drm_atomic_helper_commit?
17:54 danvet: kinda not feeling motivated to annotate the hand-rolled version much
17:55 mripard: danvet: no, it's still using its own
17:55 danvet: uh :-(
17:55 danvet: I thought there was some patch series floating around for this since like forever
17:55 danvet: maybe way back from padovan
17:56 mripard: maybe there is, but I didn't submit it :)
19:03 sravn_: danvet, bbrezillon: At first it looks like s/atmel_hlcdc_dc_atomic_commit/drm_atomic_helper_commit and kill all the now unused code
19:04 sravn_: Thats too simple, I am missing something.
19:04 danvet: sravn_, I came to the same conclusion and typed up that patch
19:04 danvet: code seems to predate the nonblocking support in atomic helpers
19:04 danvet: I found another such copypasta in my journey
19:05 danvet: iirc we had over one year of no nonblocking support in helpers, because I had no idea how to do them best
19:05 danvet: and wanted to see a sample of "how not to do it" attempts first :-)
19:05 sravn_: danvet: Time to get my atmel board operational so I can test. Thats for the weekend to do.
19:06 sravn_: I have on my TODO to kill all uses of dev_private. Did you see any other obvious things that could use a cleanup while you looked at atmel_hlcdc?
19:06 imirkin: danvet: got more examples than you bargained for?
19:06 danvet: imirkin, I think it was worth it
19:06 sravn_: Will also look at logging, so we migrate to drm_*
19:07 danvet: it's just atomic became a success pretty quickly, so we had like a handful of examples
19:07 danvet: and a few handful more drivers that just copypasted one of the broken patterns :-/
19:08 imirkin: yeah, i think atomic is a good match for most hardware. nice internal API. just doesn't match the way many drivers were previously written.
19:14 danvet: imirkin, yeah can't have it all
19:15 danvet: getting almost perfectly working backwards compat with old uapi was already rather nice
19:15 danvet: any differences in legacy uapi behaviour I think we now mostly managed to fully standardize
19:16 imirkin: yeah. problem is that something like pre-nv50 modesetting will likely never be converted to the atomic api
19:16 imirkin: simply too much weirdness and too hard to locate hardware to test with
19:19 danvet: imirkin, yeah, I think same will hold for radeon
19:19 danvet: maybe the non-atomic kms code in amdgpu can be sunset eventually
19:20 danvet: that would be nice, since I'm always getting confused about it and then make a fool of myself on dri-devel :-)
19:20 imirkin: i'm sure you'll find something else when the time comes
19:20 imirkin: plenty to be confused about across the drm subsystem :)
19:21 danvet: oh sure, there's no bottom to looking stupid
19:21 imirkin: like talking about color, unless you're one of the 2 people who understand it
19:25 ajax: at some point the hardest part of fixing older drivers is finding a working agp machine
19:26 imirkin: or CRT
19:26 imirkin: or thing with s-video input :)
19:26 imirkin: i still have one monitor which accepts VGA and S-Video inputs, but ... once that goes, that's it
19:27 ajax: vga is a close enough proxy for crt, tbh
19:27 imirkin: should donate it to a museum ;)
19:28 imirkin: i suspect that between everyone in this channel we could put together enough hw to give the computer history museum a run for its money...
19:30 ajax: i got very close to having one card for every driver in xorg 6.7 at one point
19:31 imirkin: i had a trident board for a while, but something happened and it sorta fried
19:31 ajax: i have a trident pccard.
19:32 imirkin: pccard, like pcmcia?
19:32 ajax: yep
19:32 Kayden:had no idea pcmcia video cards were a thing
19:32 imirkin: yeah, first i hear of it
19:33 ajax: this one: https://www.cnet.com/products/village-tronic-vtbook-graphics-card-cyberblade-xp2-32-mb-series/
19:33 imirkin: wow, DVI too
19:33 imirkin: mine was just VGA
19:34 Kayden: better than 965 lol
19:34 ajax: very briefly this was a cool thing to do on macs before the igpu would routinely have two crtcs
19:34 imirkin: i got it off the reuse list at MIT, so it was probably new in the early 90's. maybe not trident?
19:34 imirkin: someone who made early 3D gpu's... 3Dlabs maybe?
19:34 ajax: you can still see its legacy in apple CGL, which has a Trident hardware profile
19:38 ajax: i think i have an expresscard dock somewhere with a gpu on the far end. and a pci card with an expresscard socket, for all your desktop hotplug needs.
19:38 ajax: no idea anymore what gpu was in that
19:38 emersion: does hotplug work with expresscard?
19:39 emersion: didn't for me, but maybe that's a motherboard thing
19:39 ajax: it's meant to
19:39 emersion: (tested with a T420)
19:39 ajax: for a long time linux didn't deal too well with it, life gets awkward when you can't predict how big the downstream decode aperture needs to be
19:41 ajax: maybe that's better now because thunderbolt?
19:45 mattst88: imirkin: heh, someone just sent me a pile of documentation for 3DLabs cards that I don't think anyone in the open source community has had access to before
19:45 mattst88: so if you want to write a wildcat driver, let me know :P
19:46 ajax: wildcat? holy shit.
19:47 mattst88: yeah, docs for ancient stuff like 300SX all the way through VP9/VP10
19:47 imirkin: mattst88: no, it was some piece of shit. there was an XFree86 driver, which was dropped some time back
19:47 ajax: mattst88: my inbox awaits.
19:47 imirkin: but back when i used it, the driver was there :)
19:47 mattst88: ajax: maybe I should put them all on x.org/docs/3DLabs/?
19:47 mattst88: ajax: sure things :)
19:48 mattst88: reading the docs about the bizarro shader stages the thing has is kind of a mindfuck
19:48 imirkin: i _think_ it was the trident driver, but i could just be confusing things
19:48 ajax: mattst88: i would not. just because the docs leak doesn't mean they're redistributable
19:48 ajax: like, you can find the rendition verite docs if you know where to look, but
19:49 ajax: anyway. wildcat and matrox p- and m-series are like the two "major" gl2-capable architectures we don't have gallium drivers for
19:49 ajax: i have a wild dream of seeing that complete, someday
19:51 imirkin: unfortunately i think i threw it out anyways
19:51 ajax: ... i could probably write a gles2 driver for the verite
19:52 imirkin: might have been one of these -- http://www.vgamuseum.info/media/k2/items/cache/51b8ab8a165aa1fb5a57daf7b2513248_XL.jpg -- i remember some confusing s3 chip on there.
19:52 ajax: not sure if it'd satisfy the minimaxes? thing only had like 8M of vram
19:52 imirkin: (and the board itself being massive)
19:57 imirkin: permedia/wildcard boards available on ebay in the $30 range
20:09 ccr:remembers trying to get S3 Diamond Virge to work with utah-glx
21:43 anholt__: tomeu: getting CI errors since the lava minio change https://gitlab.freedesktop.org/airlied/mesa/-/pipelines/173039
21:44 anholt__: (probably missing "needs")