00:55damo22: ajax: Hello, I have a small suggestion for libpciaccess and I want to understand why this check is present https://gitlab.freedesktop.org/xorg/lib/libpciaccess/-/issues/12
01:04mattst88: I know nothing about this, but, you can't just return the existing mapping?
01:07mattst88: might need to check that region/map_flags are the same
01:08damo22: i think you cant return the same mapping because if one of them unmaps it, the other will silently lose access
01:09mattst88: since this is HURD, shouldn't you have a pciaccess process that arbitrates access? :)
01:09damo22: the only thing i could think of was dropping the check entirely
01:09mattst88: sorry, Hurd. (I hate when people write MESA, so I shouldn't mistakenly write HURD)
01:10damo22: im not too fussed what you call it
01:10mattst88: more my neurosis than anything :)
01:11imirkin: i get pretty annoyed by MESA too for some reason
01:11damo22: i guess i could ensure unmapping is done correctly so only one mapping is present at any given time
01:11MrBIOS: hey folks
01:11damo22: but is there really a problem with having duplicate mappings?
01:12mattst88: I don't know, myself
01:12mattst88: do you know why there are multiple (attempted) mappings?
01:12mattst88: MrBIOS: hi!
01:12MrBIOS: hey, how goes?
01:12damo22: yes, one is probing and then it doesnt unmap then it tries to use the pci device and remaps it
01:13damo22: i kept getting 0x0
01:13damo22: on the second mapping
01:13mattst88: damo22: so there's a driver or something that maps, probes something, and fails to unmap?
01:14damo22: its quite convoluted on hurd
01:14mattst88: okay, yeah, I'd guess figuring out why it's not unmapping would be my first step
01:14MrBIOS: Might anybody here be interested in some COVID-19 contract work? I’m looking for someone who can investigate the feasibility of writing an AMD Geode driver (yes, _that_ Geode)
01:14MrBIOS: DRM driver, that is.
01:15damo22: MrBIOS: check coreboot src
01:15imirkin: not a lot of those geodes running around...
01:15damo22: i think they threw out the geodes from the tree
01:15mattst88: yeah, I want to know what geode hardware is still in use that warrants spending money on it :)
01:15MrBIOS: imirkin: there are actually tens of thousands of them running around, at a bare minimum.
01:16mattst88: XO 1 :)
01:16MrBIOS: mattst88: OLPC. They sold two million of them.
01:16damo22: but there is probably support for the gfx in the tree
01:16imirkin: oh, OLPC used geode? didn't know that
01:16mattst88: MrBIOS: I've got a stack of them in my garage...
01:16MrBIOS: imirkin: yes, the original model, the XO-1, was Geode based
01:16MrBIOS: mattst88: so do I. I probably have you beat. I have about 200
01:16mattst88: though I think I don't have the one with Geode; unclear if I misremebered receiving one or what
01:17imirkin: MrBIOS: you have a big garage.
01:17mattst88: MrBIOS: and I'm glad you do!
01:17MrBIOS: imirkin: office, but yes :)
01:17mattst88: so the contract work is for XO laptops?
01:17imirkin: MrBIOS: how did your thing go for getting power-be working?
01:17imirkin: i remember we talked about that like ... 3-5 years ago?
01:18MrBIOS: imirkin: it went okay, for a while
01:18MrBIOS: more like six, yes
01:18imirkin: time flies
01:18mattst88: when you're stuck indoors
01:18MrBIOS: the hardware I sent to the developer resulted in functional r600g and Mesa patches
01:19mattst88: guy that worked for RH and did some pixman stuff for a while?
01:19MrBIOS: mattst88: so, these days, there’s mainline support for the XO-1 and XO-1.5
01:19mattst88: MrBIOS: oh, that's good to hear
01:19MrBIOS: mattst88: yep, that’s him
01:20MrBIOS: anyways, there’s an old directfb geode driver
01:20MrBIOS: of course, directfb won’t even compile with modern gcc
01:20imirkin: if i didn't have 100 other things i was working on, sounds like it could be easy and fun to do
01:20mattst88: yeah, I bet it would be simple
01:21MrBIOS: BTW, the OLPC’s are OpenFirmware, no legacy PC BIOS.
01:21mattst88: I hope someone is able to take you up on your offer
01:22mattst88: MrBIOS: does the OLPC Association or Foundation still exist?
01:22MrBIOS: mattst88: yes, barely.
01:23MrBIOS: OLPC Foundation does exist, they effectively service legacy customers. After about ~2012, they transitioned to selling re-badged Chinese ODM netbooks.
01:23MrBIOS: They shut down their office in Miami not too long ago, maybe a year, and one of their oldest employees left
01:24MrBIOS: OLPC Foundation has been owned/financed by a Nicaraguan banker, bizarrely enough.
01:24imirkin: i was at the media lab when all that stuff was getting kicked off
01:24MrBIOS: imirkin: you probably know Walter Bender, then
01:25imirkin: nope, didn't know too many of the people involved
01:25imirkin: negroponte left to head it, that's the main thing i remember
01:25mattst88:contracted for OLPC 2011~2012
01:26imirkin: that explains why you have a garage-full of them then :)
01:27MrBIOS: mattst88: I have a good ~5-10 prototypes I have been given over the years. I picked some up from ‘dilinger’ in Seattle a number of years ago
01:27MrBIOS: 3 or 4
01:27mattst88: imirkin: yep
01:27MrBIOS: https://www.media.mit.edu/people/walter/publications/ is Walter. He was a founding member of MIT Media Lab, and ran it for a while.
01:27MrBIOS: mattst88: nice, are most of your OLPC’s 1.75’s?
01:28mattst88: MrBIOS: yeah
01:28MrBIOS: mattst88: some guy came out of the woodwork a year or two ago and did some kernel dev work for 1.75
01:28mattst88: I thought I had an XO1 and a 1.5, but IIRC when I looked last I couldn't find one or the other, so now I'm not sure I ever had both
01:28MrBIOS: mattst88: https://www.phoronix.com/scan.php?page=news_item&px=OLPC-XO-1.75-Linux-5.4
01:29mattst88: very cool
01:29mattst88: I was able to get some gcc patches from Marvell unstuck (and ultimately upstreamed) by saying "OLPC needs this" -- that was pretty fun
01:30mattst88: ugh, that's the XO 1.75 that I gave to Michael and then he wrote a bad benchmarking article about
01:31MrBIOS: Anyways, these days, the XO-1 is still usable, albeit grossly underpowered. My goal is to graft low-end devices, such as Pi Zero/Pi3/Pi4/etc etc. on to the original XO-1 hardware, via usbcdc/eth, basically using it as a glorified KVM/dumb terminal, for I/O
01:31MrBIOS: mattst88: yeah dumb, benchmarkers gotta benchmark
01:31damo22: he usually benchmarks power usage of mobos with hugeass gfx cards attached
01:31imirkin: MrBIOS: hm. i was there like 2002-2005ish
01:31mattst88: damo22: lol
01:31MrBIOS: yeah, I’m familiar with his schtick
01:32imirkin: but i don't recognize him.
01:37mattst88: MrBIOS: FWIW, it might be worth emailing the dri-devel@ mailing list as well
01:38MrBIOS: it might
02:27mareko: krh: my plan isn't to remove classic from Mesa. My plan is to move classic to src/mesa_classic, so that nothing changes from the build, install, and packaging perspective
04:05krh: mareko: yeah I know... I think that's not idea eit
04:05krh: Ideal either
05:11mareko: krh: dude, a controversial idea can never have an ideal solution :)
07:27tango_: is this the place to ask questions about clover? I'm seeing some very strange behavior with an RX580, amdgpu driver, on debian sid (kernel 5.4.0, mesa 20.0.2) using the `reduction` test from this repository https://github.com/Oblomov/cldpp
07:28tango_: basically, the initial data upload (host -> device) is very fast (as if it was zero-copy, and simply mapping the host memory into the gpu memory space), and the throughput of the actual reduction is abysmal (12 to 14GB/sec)
07:29tango_: _moreover_, when the host data ptr at the end is freed, the program segfaults, which doesn't happen with any other opencl platform (FLOSS and not)
07:38tango_: (the question being: as the author of the test, am I doing something wrong that only hits on amdgpu, or is amdgpu doing something funky based on the way the buffers are set up?)
08:09HdkR: tango_: Mapping as a host visible pointer or device pointer?
08:10tango_: HdkR: well, I wouldn't know what's actually happening behind the scenes, I can only see what's happening “superficially”
08:11HdkR: When you clCreateBuffer are you using the *_HOST_PTR bits?
08:11tango_: I allocate and initialize on host, then I create an opencl buffer with CL_MEM_READ_ONLY, , no HOST_PTR bits
08:11tango_: and then I'm calling clEnqueueWriteBuffer
08:11tango_: this is extremely fast
08:11tango_: wait, I'll push the slightly more verbose version
08:12HdkR: Fun, sounds like it is still mapping on the host. Since 12-14GB/s is pretty good for a PCIe device streaming memory over the PCIe bus :P
08:12tango_: (ok, pushed)
08:13tango_: I'm wondering if I could force a migration with clEnqueueMigrateEtc, but I wondering why a Write would be turned into a mapping
08:13tango_: and why it would cause a segfault further down the line
08:17tango_: HdkR: BTW, I was looking at the mesa issue tracker and https://gitlab.freedesktop.org/mesa/mesa/-/issues/2702 sounds suspiciously like the same issue
08:21HdkR: Sadly I'm not versed in Clover to know if there is an explicit problem with memory management there
09:22tango_: hm how do I tell which gallium driver is being used for a specific hardware?
09:23tango_: (by clover)
09:23bnieuwenhuizen: does clinfo not give you a name?
09:26tango_: bnieuwenhuizen: apparently not: Device Name Radeon RX 580 Series (POLARIS10, DRM 3.35.0, 5.4.0-4-amd64, LLVM 9.0.1)
09:26tango_: I was actually a bit surprised by this, now I was looking for where the string is set, to see if I could add it
09:27tango_: this is starting to feel a bit like the yak shaving scene in malcolm in the middle
09:27tango_: (this one, for reference: https://www.youtube.com/watch?v=AbSehcT19u0)
09:32tango_: ah, AMD_DEBUG=info,compute spews a lot of info
09:34bnieuwenhuizen: tango_: with that name you can be pretty sure it is "radeonsi"
09:34tango_: bnieuwenhuizen: thanks, I was starting to suspect as much
09:35tango_: still would be nice if it was retrievable in a relatively easy way
09:48tango_: ah this is even more interesting: if I run up to 32*1024*1024 elements, I get up to 120GB/sec, even though the upload is way too fast to be the actual transfer timing
09:48tango_: and there's no segfault
09:49tango_: however if I do more (e.g. 64*1024*1024), the perforance drops again to “pci-express” bandwidths
09:49tango_: but I don't get a segfault on free
10:52tango_: (eh, “detected potential spam”. maybe because I linked the cldpp repo?) anyway, submitted as #2703
13:50arora: jekstrand: Hey, I know you are generally unavailable on weekends, but it's urgent so I am leaving a message here. Reply whenever you can. I recieved feedback from Trevor Woerner on the draft, and he wants me to add a week-by-week break-down of the project, from start to finish and also deliverables for each week. The deadline for submission is 31st March. I understand that it's highly implementation
13:51arora: based, but it would be helpful if you could provide some vague idea for like a week-by-week breakdown.
15:22ldiamond: I opened this issue yesterday: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2702
15:23ldiamond: I was hoping I could provide more information and maybe do some testing of potential patches. Is there a guide on setting up a dev environment for mesa and have vaapi working?
15:27pepp: ldiamond: basically you need to build mesa (and drm if the version from your distro isn't recent enough). Then make sure LIBVA_DRIVERS_PATH variable points to your install dir
15:28pepp: (ie: I'm building mesa and installing it using the /opt/mesa prefix. And I have LIBVA_DRIVERS_PATH=/opt/mesa/lib/x86_64-linux-gnu/dri)
15:28ldiamond: Ho, you actually responded to that specific issue.
15:28ldiamond: I'm assuming you don't have a RX 580 handy
15:29pepp: I have a RX590, I'll test tomorrow. But testing on a laptop (raven1) I get similar performance (speed = 0.5X)
15:32ldiamond: I unfortunately can't test it on Windows since I have not had a windows pc in years.
15:37ldiamond: unless I can usb boot it, we'll see
15:41ldiamond: I will test clearlinux and try on windows too if I can.
18:51jekstrand: arora: Ugh... Yeah, that's a tight deadline...
18:52jekstrand: arora: I don't think I'm the one who should be making the week-by-week breakdown. I think the reason why they want a week-by-week is because they want to ensure that you've thought through the problem and know what you're getting into so I think you should be the one to write it.
18:53jekstrand: arora: Note that you don't actually have to follow it exactly. The whole week-by-week thing will get blown away by week 2, I'm sure.
18:54jekstrand: arora: However, it provides an indication that you know roughly what you're getting into and that we've planned about the right amount of work for a summer.
18:54jekstrand: I'm happy to provide feedback and help you think through things but I think this one needs to be yours.
18:57arora: jekstrand: Hey, glad that you replied :). Oh yea, about that, I, in a bit of adrenaline rush, went ahead and made a week-by-week breakdown and a lot of other changes as well lol.
18:57arora: It's here: https://drive.google.com/file/d/1t5YjO7m01dFlwOed9inVKTvnvb4cLaEW/view?usp=sharing
19:00arora: jekstrand: Except the class-taking bit, I have scheduled everything into the draft
19:09jekstrand: arora: I think it probably needs to be more specific. Right now it's just 2 weeks of "do the thing", one week of "buffer", and a blog week.
19:10jekstrand: arora: So, for instance, for the third milestone, we'd like to get the "final" layer config file and all merged by the end.
19:11jekstrand: So we need to think about when the final MR needs to be posted in order to allow plenty of time for review.
19:11arora: Oh ok, right.
19:12jekstrand: Also, it will almost certainly take more time for review than you think. :-)
19:13jekstrand: So plan lots
19:13jekstrand: And then work backwards from there.
19:13jekstrand: If you think it'll take a month for review, for instance, that that means you have to have stuff working by that point.
19:13jekstrand: You'll still do engineering work during that month because the code will be constantly changing to adjust to the review feedbabck.
19:14jekstrand: What all do you need to have working by then?
19:15jekstrand: One thing that may be helpful is to set aside the schedule for a bit and just come up with a list of every feature you think there will have to be.
19:15jekstrand: Then you can try to put it all in order to get a sense of how things will have to flow.
19:16jekstrand: Again all of this will get thrown out by week 2 but it's good to have sat down and thought through the problem as best as you can.
19:17arora: jekstrand: How long does it usually take for reviews?
19:17jekstrand: I would expect the config file format review to take at least a month, probably more.
19:19jekstrand: There are going to be lots of questions such as "How do you specify which GPU to select?" and "How do we specify detection criterion?"
19:20jekstrand: I expect that there will be far more discussion about those types of issues than about the code itself.
19:32arora: Ok, I will try to work backwards from the review month.
19:33arora: How do I break down the understanding and improving part?
19:33arora: Should I like mention the faults in other projects and possibly the function names?
19:35jekstrand: Venemo: Trying to correct the internet? :-P
19:35jekstrand: arora: First off, I really don't think the understanding and improving part should take a month
19:37jekstrand: I'm not sure how airlied and bnieuwenhuizen would want to handle things. One of the first things that needs to happen is landing that MR.
19:37jekstrand: I went through and gave a bunch of comments on the first patch
19:38jekstrand: I don't know if bnieuwenhuizen wants to make the adjustments or if he'd want you to take over it.
19:38jekstrand: I've not looked at airlied's second patch yet though.
19:38bnieuwenhuizen: what adjustments am I supposed to have an opinion on?
19:40jekstrand: bnieuwenhuizen: The device selection layer MR
19:46bnieuwenhuizen: oh .. totally missed that the first patch is actually mine ...
19:50airlied: jekstrand: I might squash them
19:50airlied: I fixed lots of stuff in my patch :)
19:50airlied:is saying that like finding time to do it isn't near impossible
19:52airlied: bnieuwenhuizen: any objections to squashing and just leaving your name in the commit msg? :)
19:54bnieuwenhuizen: airlied: nope
19:59airlied:will try and reconcile it a bit today, keep on juggling, keep on juggling :-P
20:02arora: jekstrand: Umm, what does this MR mean for me and the project?
20:02jekstrand: arora: Merge request
20:03arora: oh no, not in that way, I mean does landing that MR affect the gsoc project?
20:03arora:feels that timezones are hard
20:05jekstrand: arora: I think we should try to land it. I was hoping that the first step could be you taking ownership of the MR and addressing any review feedback.
20:05MrBIOS: do you guys participate in GSoC by chance?
20:05jekstrand: And then everything else will build on it
20:05jekstrand: MrBIOS: We have, from time to time
20:05MrBIOS: this year?
20:06jekstrand: X.org also has their own EVoC thing
20:06jekstrand: MrBIOS: There are a few project proposals this year
20:10arora: jekstrand: Alright, I will work for a bit. Any other changes in the draft?
20:13jekstrand: arora: Not really. I don't have a lot of experience GSoC mentoring so I don't really know what's expected
20:14airlied:has enough experience to knw I'm not good at it :)
20:22arora: jekstrand: Does that MR allow the user to provide GPU name?
20:25jekstrand: arora: Not yet
20:57arora: jekstrand: It's almost 3am here, here's some changes, https://github.com/ashok-arora/gsoc-vulcan-gpu/blob/master/xorg-final.pdf
21:10arora: Provide your feedback, I will see them in the logs, I am gonna go to sleep now.
21:30Venemo: jekstrand: sometimes I try :O
22:32airlied: bnieuwenhuizen: one q, the instance unordered_map locking, I'd likely get it wrong (i.e. not use C++ correctly)
22:32airlied: any suggestions welcome :)
22:34HdkR: std::scoped_lock? :)
22:34bnieuwenhuizen: I was about to suggest std::lock_guard: https://en.cppreference.com/w/cpp/thread/lock_guard
22:35bnieuwenhuizen: not that i matters much for a single mutex :)
22:36jekstrand: And here I was going to suggest you ditch C++ and use c11_thread.h for the mutex and util/hash_table.h
22:36airlied: jekstrand: I could take that suggestions, not sure C++ wins much here :)
22:36bnieuwenhuizen: that is the other option :P
22:36jekstrand: If we're going to be doing any serious string manipulation, std::string might buy us something
22:37jekstrand: But, yeah, the only real use of C++ is a single unordered_map. Doesn't seem all that necessary. :-)
22:37jekstrand: Better yet, we should re-write it in Rust. :-P
22:37airlied: jekstrand: once you write anv in it first :-P
22:38jekstrand: airlied: Don't tempt me!
22:38airlied: it would be all fun and games until you had to link the compiler :-p
22:38jekstrand: airlied: That said, I have been contemplating how we can start using Rust in mesa. Something nice ane self-contained like a layer is a very good place to start.
22:39airlied: the other ssw vulkan project for risc-v uses rust I believe
22:39jekstrand: If Rust had more competent link-with-C support, I would totally start rewriting bits in Rust
22:40bnieuwenhuizen: as someone who doesn't really know rust that much, what is missing in C-linking support?
22:41jekstrand: bnieuwenhuizen: It can link with c, technically. However, you have to re-write your headers to produce Rust things; it can't just consume them.
22:41jekstrand: Also, the Rust build system, cargo, assumes that it's the only build system in play and isn't really designed to integrate into anything
22:42jekstrand: So you either have to invoke cargo from meson (you can't just call rustc) or meson from cargo.
22:42jekstrand: So, yeah, we could probably start using rust but we would have to keep things very tightly contained so because the Rust/C boundary is way more painful than the Rust/C++ boundary
22:42jekstrand: C/C++ boundary, I meant.
22:42ascent12: Meson has its own Rust "support", but due to the nature of Rust and how everything is heavily tied to cargo, it really is a second class citizen.
22:43bnieuwenhuizen: heh, that is likely going to get fun with generated source files?
22:43ascent12: i.e. you basically have get no way of using Rust dependencies.
22:43jekstrand: bnieuwenhuizen: Yeah....
22:44jekstrand: bnieuwenhuizen: So we could, for instance, rewrite ISL in Rust. It's got a fairly small interface (still dozens and dozens of functions, structs, and enums) and is very self-contained.
22:45jekstrand: However, there's no way we could bind all of NIR to rust and start writing NIR passes in Rust.
22:45bnieuwenhuizen: WSI another candidate?
22:45bnieuwenhuizen: or is that annoying because external deps?
22:45jekstrand: WSI could be done, probably.
22:45jekstrand: I should clarify what ascent12 said about external deps
22:46bnieuwenhuizen: (I meant here external deps == C headers for the windowing system)
22:46jekstrand: Cargo uses the NPM/Maven model of dependencies where you specify them in your manifest file and cargo automatically downloads the exact version you requested, builds it, and statically links it into your project.
22:47jekstrand: Because meson and, more specifically, linux development doesn't work that way (meson does have wraps which are similar), it can't really pull in crates (cargo's packages) and use them easily.
22:47jekstrand: bnieuwenhuizen: Yeah, binding Rust to X11 or Wayland could get "fun" though I suspect someone somewhere has written bindings.
22:50ascent12: Rust's strict ownership model really doesn't play nicely with the way libwayland works. Bindings exist, but they essentially reimplemented it all, although I still think it can optionally wrap over libwayland.
22:50ascent12: No idea about X11.
22:51jekstrand: Looks like there are at least a couple x11 binding projects
22:51jekstrand: Yeah, that's the other problem. Virtually any Rust binding to C code is going to have to use "unsafe" all over the place and may have a lot of trouble mapping Rust's ownership model to C.
22:52bnieuwenhuizen: jekstrand: the ownership model would also be the question I'd have around the vulkan API
22:52jekstrand: ascent12: I would think Wayland would be mostly ok. You'd just end up more-or-less building a smart pointer wrapper for everything.
22:53jekstrand: bnieuwenhuizen: Yes, that gets tricky. Fortunately, however, virtually everything in Vulkan is effectively immutable which helps a great deal.
22:53jekstrand: Though internally it may not be immutable so that's bad
22:53bnieuwenhuizen: (+ how to deal with allocators)
22:53ascent12: I know libwayland-server was where a lot of the real issues were, with all of the container_of type things. libwayland-client probably isn't quite as bad.
22:53jekstrand: You'd have to throw the allocators away most likely
22:53jekstrand: ascent12: Oh, yeah, wrapping libwayland-server would be a disaster
22:53jekstrand: But libwayland-client should be mostly
22:54bnieuwenhuizen: jekstrand: are allocators actually in common use anywhere?
22:54jekstrand: bnieuwenhuizen: I don't know
22:54jekstrand: bnieuwenhuizen: No one uses them in their compilers, I can tell you that.
22:54jekstrand: Good luck trying to make LLVM use the allocator. :-P
22:55bnieuwenhuizen: I think CTS has some tests to check allocation failure
22:55jekstrand: It does, but they only warn if you never call the allocator
22:55bnieuwenhuizen: and I think allocators were also explicitly the mechanism to control pipeline cache sizes?
22:55bnieuwenhuizen: (not that I've ever seen anyone use it for that)
22:57bnieuwenhuizen: I guess it can't be much worse than virvulkan will do internally anyway
22:58jekstrand: I think in some engines the allocators could actually matter.
22:59jekstrand: In some of the more crazy threading systems that are used in game engines, calling malloc() from one of their light-weight threads is a no-no
23:19krh: Librsvg might a good place to look. Federico who maintains it now pulled in rust a rewrote tiny bits at a time
23:19krh: He has a good blog series about it
23:21airlied: jekstrand, bnieuwenhuizen: pushed a cleaned up version using C only
23:30MrBIOS: airlied: where?