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