<zzxyb[m]>
excuse me, I created and processed gbm_bo on the first drm device, how to display it on the output of the second drm device after completion
aravind has joined #dri-devel
Namarrgon has joined #dri-devel
angerctl has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
ultra has quit [Remote host closed the connection]
ultra has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
aravind has joined #dri-devel
Duke`` has joined #dri-devel
itoral has joined #dri-devel
bgs has joined #dri-devel
fab has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
eukara has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
Ahuj has joined #dri-devel
fab has quit [Quit: fab]
kzd has quit [Quit: kzd]
kzd has joined #dri-devel
sima has joined #dri-devel
lemonzest has joined #dri-devel
rasterman has joined #dri-devel
shashanks_ has quit [Ping timeout: 480 seconds]
kzd has quit [Quit: kzd]
itoral has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
jkrzyszt has joined #dri-devel
fab has joined #dri-devel
<MrCooper>
zzxyb[m]: what are the two GPUs the BO is being shared between? Asking because scanning out from a shared BO doesn't work except for some special cases
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
pcercuei has joined #dri-devel
MajorBiscuit has joined #dri-devel
carbonfiber has joined #dri-devel
tursulin has joined #dri-devel
Haaninjo has joined #dri-devel
apinheiro has joined #dri-devel
benjaminl has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
imre has quit [Remote host closed the connection]
imre has joined #dri-devel
<pq>
zzxyb[m], sounds like the kernel DRM drivers you are using are not checking everything they should, or rejeceting everything they should. That may cause things like gbm_bo_import or createFB to succeed when they should not.
<pq>
zzxyb[m], such sharing and scanout depends completely on the hardware, so it is not a surprise you get different results on x86 vs. ARM.
<pq>
zzxyb[m], the various API calls you are doing are supposed to fail, when the hardware does not support the operation. Failing those calls correctly is the drivers' responsibility.
hansg has quit [Quit: Leaving]
hansg has joined #dri-devel
<pq>
zzxyb[m], there many different ways on how arrange one DRM device to render and another to scan out, and there is no single way that both works everywhere and is performant.
<pq>
*there are many
<pq>
zzxyb[m], the choices involved are: on which device you allocate a buffer, in which direction is the buffer import done, and which device is doing a copy if a copy is needed.
<pq>
zzxyb[m], the best choice depends on the hardware architecture and the exact graphics chips or cards chosen, and how they are connected.
<pq>
zzxyb[m], also, multiple different ways can work, but not all of them may have an acceptable performance, so you cannot solely rely on API calls failing to find the best solution.
camus has quit [Remote host closed the connection]
aravind has quit [Remote host closed the connection]
aravind has joined #dri-devel
DMJC has joined #dri-devel
<DMJC>
hi, I've got a question regarding Mesa/GL Drivers.
<DMJC>
I've got an application which I was trying to run in WINE, when I ran it on X11/AMD drivers it comes up with a black screen, but when I run it in Xephy
<DMJC>
with LLVMPipe it renders
vliaskov has joined #dri-devel
<DMJC>
Is there an easy way to determine whether it's AMD's Open source driver that's causing the problem?
<kunzite>
LLVMPipe is usually the source of truth compared to other drivers so that is concerning
andrey-k- has quit []
andrey-k- has joined #dri-devel
<DMJC>
yeah if I run LIBGL_ALWAYS_SOFTWARE=1 /home/james/development/wine-git/wine secretops.exe
<DMJC>
the game renders/works
<DMJC>
but on both DRI_PRIME=1 and DRI_PRIME=2 I get a black screen
<DMJC>
Intel and AMD Drivers
<pq>
I don't think DRI_PRIME=2 is a thing, is it?
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<DMJC>
it is when you have 3 GPUs...
<DMJC>
on my laptop PRIME=1 is coming up as intel, PRIME=2 and PRIME=0 come up as AMD
<DMJC>
there's also an NVIDIA GPU in this laptop (Intel/NVIDIA), but I've disabled it atm and use an eGPU (5700XT)
<pq>
that's undocumented then, the last I looked. Personally I'd use DRI_PRIME with pci device identifications to be sure I get exactly the card I want.
<DMJC>
hmm, so at least I know whatever it is in AMD/Intel that's broken is working on closed source NVIDIA
<DMJC>
and on LLVMPipe
<pq>
arrrh, one day I will remember to go through the dri-devel email cc list and remove all skynet.ie addresses.
<DMJC>
I've got a list of all the GL Extensions the game uses, don't suppose there's a way to override them individually so I can eliminate the working ones?
<pq>
DMJC, I think Mesa had some environment variables for that.
<emersion>
pq, yeah, i get these annoying notifications too :/
lygstate has quit []
andrey-k- has quit []
andrey-k- has joined #dri-devel
andrey-k- has quit []
andrey-k- has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
shashanks has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
bmodem has joined #dri-devel
andrey-k- has quit []
andrey-k- has joined #dri-devel
andrey-k- has quit []
Jeremy_Rand_Talos has quit [Remote host closed the connection]
Jeremy_Rand_Talos has joined #dri-devel
yuq825 has quit []
noralf has joined #dri-devel
<zzxyb[m]>
<MrCooper> "zzxyb: what are the two GPUs the..." <- amd and displaylink(udl)
yuq825 has joined #dri-devel
<pq>
displaylink is a "software" device, there is no hardware behind it, and no GPU. A very special case.
andrey-k- has joined #dri-devel
Major_Biscuit has joined #dri-devel
<noralf>
"dim push-branch drm-misc-next" failed for me: "dim: FAILURE: Could not merge drm-intel/drm-intel-next", could someone please have a look. Fixing this is beyond my abilities.
<zzxyb[m]>
In fact, I encountered an arm computer, which is a mali gpu, but cannot create gbm_surface on displaylink (driver defect). So I thought about creating multiple gbm_surfaces on mali and sharing them to displaylink display
<pq>
I've never worked on any Mali device, though.
<pq>
the difference between integrated and discrete graphics card matters too, whether it has dedicated VRAM or not. CPU access to dedicated VRAM directly is slow.
<zzxyb[m]>
pq: I have encountered a lot of mali driver bugs, unfortunately, it has greatly increased the difficulty of my work, I work on wayland
<pq>
zzxyb[m], gbm_surface is a collection of gbm_bo's. You don't share surfaces, you share buffers. But yes, creating a gbm_surface on the actual GPU, taking gbm_bo out, exporting it, then importing it to displaylink is how a zero-copy path might work.
<pq>
We can't help with proprietary drivers though, if you use one.
<zzxyb[m]>
<pq> "displaylink is a "software..." <- Yes, the displaylink device seems to have the DRI function, but it is an independent DRM device. Maybe I am used to calling it a GPU, but in fact it is not. The main reason is that this type of technology belongs to the multi-GPU range. Forgive me for the wrong name.
<zzxyb[m]>
pq: I am trying on the amd open source driver, using gbm_bo_import, but the result is not very friendly, let me show you the display effect
MrCooper has quit [Ping timeout: 480 seconds]
<pq>
zzxyb[m], I think much of it depends on the exact details of how you use the GBM API. E.g. do you use explicit modifiers. Do you tell AMD to allocate linear. Etc.
<pq>
I would guess that udl cannot handle anything that is not using DRM_FORMAT_MOD_LINEAR.
<zzxyb[m]>
pq: I'm sure the image size is correct, this displaylink device is just one resolution
<linkmauve>
Ah, I had approximately the same kind of artifacts trying to import an INVALID dmabuf exported from amdgpu to i915.
<pq>
are you sure the displaylink device is driving the panel correctly?
<linkmauve>
Make sure you allocate it as LINEAR.
<pq>
linkmauve, really? It can cause pixel strething like that?
<linkmauve>
pq, it uses tiling, so tiles become linear in memory.
<zzxyb[m]>
pq: Yes, if I don't use gbm_bo_import, there is a way to light up the displaylink normally, but there will be a memory copy
<pq>
linkmauve, yeah, but if you look at the correct image, the white dots are very small an round. In the incorrect image they are very stretched horizontally.
<linkmauve>
And if the importer isn’t aware of it, or interprets this INVALID as linear, it will take the whole tile and spread it on a <width×height>×1 line.
<pq>
but yeah, mismatch of format modifiers is the most likely cause
<linkmauve>
pq, if a white dot is 2×2, it might look 4×1.
<pq>
hmm, right
<linkmauve>
I do not know the exact tiling format of this particular GPU, but I would expect some morton order which puts close pixels close in memory.
<linkmauve>
I don’t remember if I ever fixed that issue on my end, I wanted to play a game rendered with radv, encode that buffer with vaapi on the Intel card, and then stream that out with waypipe.
<zzxyb[m]>
If I copy it to dumbbuffer, it can be displayed normally. Should I seek a solution to reduce copying from gbm_bo to dumbbufer?
<zzxyb[m]>
zzxyb[m]: But this cost is very high, first map gbm_bo to user memory, and then copy the memory to dumbbuffer, the performance is not high
<linkmauve>
zzxyb[m], the issue is that your buffer is tiled, that is pixels are not ordered like you would expect in memory pixel per pixel and row per row.
kts has joined #dri-devel
<linkmauve>
So you have to either allocate it linear, and take the perf hit on every draw to it, if your GPU is even able to draw to a linear buffer.
<linkmauve>
Or do a copy, untiling the tiled buffer into a linear layout.
<linkmauve>
On my Mali-400 GPUs, the tiling/detiling is always done on the CPU, and detiling can be extremely slow if you map the buffer as uncached memory, this can be something to look for.
<pq>
zzxyb[m], note: gbm_bo_map() internally makes a copy when necessary in order to give you a linear pixel arrangement.
<linkmauve>
I once reported an issue with that in Lima, I don’t know whether it got fixed, but glGenerateMipmap() would access the image that just got submitted, tiled, from an uncached map.
<pq>
mmap() does not do such conversions, but it can be ever slower.
<linkmauve>
It would take something like 15s on my phone to generate the mipmap for a 4096×4096 texture. ^^'
<zzxyb[m]>
linkmauve: I'm wondering if it can be solved in the udl driver？
<linkmauve>
I don’t know anything about udl, sorry.
<pq>
zzxyb[m], I believe udl would not accept CPU de-tiling code for Lima tiling modes, no.
<pq>
zzxyb[m], if Lima cannot render to linear, then you have to do a copy into linear in some way. I think such embedded systems often have some additional hardware that can do that de-tiling copy more efficiently than the CPU.
<pq>
zzxyb[m], did you ever benchmark glReadPixels straight into udl dumb buffer?
kts has quit [Ping timeout: 480 seconds]
<pq>
no dmabuf, no imports, no exports, just the plain old glReadPixels
aravind has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
<zamundaaa[m]>
pq: Afaik Mesa has workarounds for hardware that can't render to linear - it resolves the image to linear on glFlush / eglSwapBuffers. So using a linear buffer should work fine
<linkmauve>
Looking at my my phone’s drm_info, it doesn’t even support tiled formats for scanout. :|
<pq>
zamundaaa[m], ah, that helps. But I'm not sure it's Mesa...
<daniels>
specifically kmsro has code to handle it for drivers which use kmsro (not Intel/AMD) when using GBM as a target
<pq>
zzxyb[m], I keep getting confused with the AMD vs. Lima cases. They aren't comparable, especially if Lima is proprietary.
Haaninjo has joined #dri-devel
<pq>
zzxyb[m], if you need it to work on Lima, solve it on Lima. Making it work on AMD is a new problem, not the same problem.
itoral has quit [Quit: Leaving]
<_jannau__>
Lima (mesa) or Mali (proprietary)?
<pq>
oh Lima was the Mesa one? I got that confused.
<daniels>
pq: lima is the mesa driver for old (pre-Panfrost) Mali GPUs
thellstrom has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
hansg has quit [Quit: Leaving]
apinheiro has quit [Quit: Leaving]
lemonzest has joined #dri-devel
neggles has joined #dri-devel
yuq825 has quit []
phasta has quit [Quit: Leaving]
tzimmermann has joined #dri-devel
yuq825 has joined #dri-devel
MrCooper has joined #dri-devel
kts has joined #dri-devel
<pcercuei>
You guys are okay with a huge patch touching 85 files with a tiny change in each file, or should I have a huge patchset of 85 tiny patches each touching a file?
<emersion>
i'd personally favor the former, as long as no other changes are mixed in
<tzimmermann>
pcercuei, if the change is completely uniform across all 85 files, a single patch would be better IMHO
<pcercuei>
Ok, even if the files touched are scattered across subsystems?
<pcercuei>
(not *that* scattered - but it touches 3-4 subsystems)
<MrCooper>
then it should probably be split per subsystem at least
<pcercuei>
Hmm. But the kernel wouldn't build between commits then
<pcercuei>
(I update the prototype of a callback function)
<MrCooper>
one possible way to handle that is: add new callback with new signature, convert callback users, remove old callback(, rename new callback to old one)
<jfalempe>
I'm not sure it's the best way to fix that, but aspeed is a bit particular in this case. Nothing is connected on DP, but you still want to use it remotely, with a decent resolution.
carbonfiber has quit [Quit: Connection closed for inactivity]
andrey-k- has quit []
DMJC has quit [Ping timeout: 480 seconds]
andrey-k- has joined #dri-devel
daxe_ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
hansg has joined #dri-devel
elongbug has quit [Ping timeout: 480 seconds]
<tzimmermann>
jfalempe, oh. i didn't see it. let me comment
andrey-k- has quit []
djbw has quit [Read error: Connection reset by peer]
kunzite has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
kunzite has joined #dri-devel
JohnnyonF has joined #dri-devel
thellstrom1 has joined #dri-devel
kunzite has quit [Remote host closed the connection]
<zzxyb[m]>
<zzxyb[m]> "excuse me, I created and..." <- this is a more comprehensive solution to the problem.@pq,@linkmauve
JohnnyonFlame has quit [Ping timeout: 480 seconds]
thellstrom1 has quit [Ping timeout: 480 seconds]
kunzite has quit []
<tzimmermann>
javierm, FYI i have a few other patchsets for fbdev ops coming up. i also want to use the fb_ops init macros and Kconfig tokens in fbdev drivers. with the fbdev device file now being optional, i'd like toget to the point where the respective fb_ops can be left out from compilation
Leopold_ has quit [Remote host closed the connection]
kzd has joined #dri-devel
JohnnyonFlame has joined #dri-devel
penguin42 has joined #dri-devel
kts has quit [Quit: Konversation terminated!]
<penguin42>
karolherbst: I'm going to get back to looking at profiling; are we at about the same point as a couple of weeks back?
<karolherbst>
yeah
Duke`` has joined #dri-devel
JohnnyonF has quit [Ping timeout: 480 seconds]
<penguin42>
karolherbst: Ack, I'll look at it over the next few days and let you know where I get to
Leopold_ has joined #dri-devel
general_j[m] has quit []
<javierm>
tzimmermann: neat. I still owe you the review of the previous set, let me do that now
<javierm>
tzimmermann: I meant to do it on Friday but got busy with some stuff
<tzimmermann>
oh, you mean the screen_info thing?
<tzimmermann>
ok, sounds good
<javierm>
tzimmermann: yeah. Although I think you had some review from Arnd already?
<tzimmermann>
i wanted to look at your recent FB_CORE stuff, but didn't have time yet
kts has joined #dri-devel
<tzimmermann>
yes, arnd looked over it
<javierm>
tzimmermann: there's no rush. I believe the menu is much more organized after your suggestion (and from Geert and Arnd)
aravind has joined #dri-devel
<arnd>
tzimmermann: one more thing I noticed the other day but didn't comment on is that CONFIG_FB_NOTIFY should be selected by FB_DEVICE now, it's no longer needed without that
fab has quit [Quit: fab]
<javierm>
arnd: but should be select CONFIG_FB_NOTIFY if FB right ?
<javierm>
because I don't see it used by the DRM fbdev emulation layer
<javierm>
arnd: I haven't realized that you were in this channel btw :)
<arnd>
javierm: good question. I see four callers of fb_register_client(), and I had assumed that at least the BACKLIGHT_CLASS_DEVICE one does get used with drm drivers, but I have not looked closely at that
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
<javierm>
arnd: yes, but that fb_register_client() call happens from backlight_register_fb() and that's only defined when #if defined(CONFIG_FB) || (defined(CONFIG_FB_MODULE)
<javierm>
otherwise is just a stub
<javierm>
arnd: I can include that cleanup in the next iteration if you want with your Suggested-by
<arnd>
javierm: so in the current mainline code (before the FB_DEVICE and FB_CORE options are split out), we would always register the notifier for a drm device, but after your patches the #ifdef check is no longer true
<arnd>
I see this getting called from drm drivers through devm_backlight_device_register(), so I'm still not sure whether this #ifdef should be changed to checking for CONFIG_FB_CORE instead
<javierm>
arnd: hmm, that's a good point...
<javierm>
arnd: probably we could just keep as a FB select as it is in my latest version. Yes, it's not needed if FB_DEVICE isn't enabled but that's a cleanup we can do later
* pcercuei
gets triggered by #ifdefs
nehsou^ has quit [Ping timeout: 480 seconds]
nehsou^ has joined #dri-devel
<javierm>
arnd: I probably should audit all the #ifdef FB and see which ones have to be replaced by FB_CORE
<arnd>
javierm: I meant this more as something that could be changed along with tzimmermann's patches that introduce FB_DEVICE in the first place, it doesn't really belong in your series
<arnd>
javierm: the only other such check that I see is in drivers/video/backlight/lcd.c, which has the same code
<javierm>
arnd: right. Which isn't selected by DRM so we could just keep as is
<arnd>
ah right, it seems that there are in fact only two remaining callers of lcd_device_registers: drivers/hid/hid-picolcd.c and drivers/video/omap/lcd_ams_delta.c
<javierm>
arnd: yeah
<javierm>
arnd: I'll wait for your review though before re-spinning the series. There's no rush of course
eukara has joined #dri-devel
andrey-k- has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
alyssa has joined #dri-devel
Company has joined #dri-devel
andrey-k- has quit []
fab has joined #dri-devel
nehsou^ has quit [Ping timeout: 480 seconds]
alyssa has quit [Quit: alyssa]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
rasterman has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
<swick[m]>
airlied sima what was your conclusion about the color pipeline API thing?
sravn has quit []
Major_Biscuit has quit []
jkrzyszt has quit [Ping timeout: 480 seconds]
<emersion>
gfxstrand: hm, if UMF becomes a thing, would it be driver-agnostic and device-agnostic like drm_syncobj?
<emersion>
or would it stay a driver-specific opaque object, with users needing mesa to interact with it?
JohnnyonFlame has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
alyssa has quit []
alyssa has joined #dri-devel
Piraty has quit [Remote host closed the connection]
Piraty has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
msizanoen[m] has quit []
vliaskov has quit [Remote host closed the connection]
rasterman has quit [Read error: No route to host]
<sima>
emersion, definitely want to at least wrap it in drm_syncobj for interop I think, but within mesa it might be more driver specific
<emersion>
sima: hm… would it be drm_syncobj or Something Else?
<sima>
well for backwards interop drm_syncobj, because semantics should match
<sima>
it's just that the fence materializes only right when it gets signalled :-)
<emersion>
it would really help me if it was just drm_syncobj, because that would mean we can work on the new Wayland protocol
rasterman has joined #dri-devel
<sima>
emersion, yeah I think for protocol purposes you can assume drm_syncobj
<emersion>
i see
<sima>
or that we owe you really big time
<sima>
if we rev everything at the same time for umf, we'll imo never get there, too big a jump
<emersion>
i agree
hansg has quit [Quit: Leaving]
<emersion>
yeah, i think a drm_syncobj which materializes a signaled fence on completion would work
<emersion>
on UMF completion*
<sima>
yeah
<sima>
we might be able to do better for "vk app renders into winsys buffers(*)"
<sima>
(*) conditions apply
<sima>
just not sure whether the conditions work out or not
<sima>
but worst case fallback should at least be functional
<emersion>
do you have a plan for sync_file?
<sima>
not possible
<emersion>
ok
<sima>
I have some really funky ideas to fix some fairly theoretical deadlock issues with sync_file and modesets out-fences
<sima>
but they're really kernel internals, not actual umf future fences
<sima>
real future fences like umf we just can't squeeze into sync_file without breaking the world
<emersion>
the slightly annoying thing with this idea is that there are no GL/Vulkan drm_syncobj import/export
<sima>
same for implicit fencing really, it would instead be "future fence semantics implicit sync" which is just entirely a different beast
<emersion>
KMS too
<sima>
hm I thought vk and exts and gl too for interop?
<sima>
kms you need to fish the sync_file out of the drm_syncobj fd
<emersion>
but then you need to wait for the fence to materialize
<sima>
yeah
<sima>
no way around that
<sima>
kms doesn't eat future fences
<sima>
we'd need to be able to somehow cancel atomic commits
<emersion>
vk and GL only have sync_file exts, not drm_syncobj
<sima>
and I'd like not to get there :-)
<sima>
uh
<emersion>
but we can fix that
<emersion>
it's just some more work
<sima>
you sure? the kernel supports backing them into fd, and there's no other use afaik than import/export to native obj when you start with a vk timeline semaphore?
<sima>
*baking
<emersion>
for vulkan, exporting a timeline semaphore into a FD gives you the drm_syncobj, but there's no guarantee: as far as the spec is concerned, it's an opaque FD
<sima>
it's a platform specific fd
<emersion>
which can only be imported into the exact same device
<emersion>
and exact same driver
<sima>
yeah on linux it's more :-)
<emersion>
(UUIDs must match)
<emersion>
well, NVIDIA could export to not-drm_syncobj for instance
<sima>
well, except that one
<sima>
the thing is, you can just try
<emersion>
and any other Linux driver could do whatever
<sima>
yeah so just check it's mesa or something
<emersion>
i'd rather just add the proper ext
<sima>
vk_ext_this_is_mesa
<emersion>
we have a sync_file ext, we can have a drm_syncobj ext
<jenatali>
FWIW Mesa can have non-drm drivers
<sima>
hm right
<emersion>
we have VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_SYNC_FD_BIT_KHR, we can add VK_EXTERNAL_SEMAPHORE_HANDLE_TYPE_DRM_SYNCOBJ_BIT_KHR
<sima>
but any fd you get you could test-import as a drm_syncobj into a drm fd, and it'll reject it if it's something else
<emersion>
sima, this wouldn't work for import
<sima>
emersion, you need to export an fd first to check :-)
<sima>
I should probably go ^Z instead of coming up with idiot feature checks ...
<emersion>
yeah i don't want to build something hacky like this
wens has quit [Remote host closed the connection]
wens has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold__ has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
sima has quit [Ping timeout: 480 seconds]
kugel has quit [Quit: Lost terminal]
kugel has joined #dri-devel
i-garrison has quit []
ultra has quit [Ping timeout: 480 seconds]
i-garrison has joined #dri-devel
ultra has joined #dri-devel
fab has quit [Quit: fab]
<penguin42>
life would be a lot easier if 'profile' wasn't used as both a way of measuring performance and as a choice of configuration
<jenatali>
Amen
<jenatali>
You just switch to the profile profile
<DemiMarie>
sima: can one at least assume one can get a pollable FD out of a UMF? That is required to be able to use them cross-process.