<LaserEyess>
agd5f: any debugging tips or things I can dump to check? would this be in the EDID or something?
onox[m] has joined #dri-devel
nickel has joined #dri-devel
Tooniis[m] has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
nickel has quit []
Dylanger has joined #dri-devel
ramacassis[m] has joined #dri-devel
ella-0[m] has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Andy[m] has joined #dri-devel
<ccr>
wondering if this is a bug .. hitting assert in hasvk with vkquake, basically due to a VkViewport with height == 0 being set, which results in a value of -1 cast to uint32 in y_max during scissoring. now, the thing is that Vulkan spec seems(?) to say that "The absolute value of height must be less than or equal to VkPhysicalDeviceLimits::maxViewportDimensions" .. and "The application can specify a negative
<ccr>
term for height", which does not explicitly disallow 0 :P
cphealy has joined #dri-devel
<ccr>
though the reason for viewport of height 0 seems to be a bug in vkquake, which is another matter entirely
<ccr>
and with release build the assert is not there, of course, and things just go brrrr without care in the world despite borked data being generated
<zmike>
run with validation and find out
<ccr>
off to find out how to do that, then, I guess :o
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Lucretia has quit []
DragoonAethis has quit [Quit: hej-hej!]
Lucretia has joined #dri-devel
<ccr>
well, if "VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_api_dump:VK_LAYER_KHRONOS_validation" is enough .. there's only one validation error and it's "vkCreateSwapchainKHR() called with minImageCount = 2, which is outside the bounds returned by vkGetPhysicalDeviceSurfaceCapabilitiesKHR()" which does not sound relevant(?)
DragoonAethis has joined #dri-devel
pa has quit [Ping timeout: 480 seconds]
<zmike>
L E G A L
<ccr>
\:D/
yuq825 has joined #dri-devel
pa has joined #dri-devel
<karolherbst>
right.. zink.. I got told to make it run on radv...
<zmike>
my work is done
<karolherbst>
wait for the 100 bugs I'll file
<zmike>
for yourself, I assume
<karolherbst>
not if they are zink bugs
<zmike>
there are none
<karolherbst>
the CTS disagrees
<ccr>
<jedi mindtrick handwave> "these are not bugs you are looking at"
* karolherbst
goes fixing his bugs
<karolherbst>
ehm... something isn't right
<zmike>
it makes no sense
<karolherbst>
it literally doesn't... why is it like 2.5x as fast as radeonsi
<karolherbst>
ehh wait
<karolherbst>
it's as fast as
<karolherbst>
ahh no.. it is radeonsi... I am blind
pribas has quit [Read error: Connection reset by peer]
epoll has quit [Ping timeout: 480 seconds]
sjfricke[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
Eighth_Doctor has joined #dri-devel
martijnbraam has joined #dri-devel
ella-0 has joined #dri-devel
epoll has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
jenatali has joined #dri-devel
ybogdano has joined #dri-devel
Soroush has joined #dri-devel
doras has joined #dri-devel
lemonzest has joined #dri-devel
JosExpsito[m] has joined #dri-devel
fxkamd has quit []
khfeng has joined #dri-devel
mhenning has quit [Quit: mhenning]
Leopold has joined #dri-devel
Duke`` has joined #dri-devel
egalli has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
aravind has joined #dri-devel
zamundaaa[m] has joined #dri-devel
shoragan has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
pH5 has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
Leopold has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
fab has joined #dri-devel
bgs has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
ybogdano has quit [Ping timeout: 480 seconds]
shoragan has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
Surkow|laptop has quit [Ping timeout: 480 seconds]
Company has quit [Read error: Connection reset by peer]
danvet has joined #dri-devel
Surkow|laptop has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
xroumegue has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
xroumegue has joined #dri-devel
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
rasterman has joined #dri-devel
pjakobsson has joined #dri-devel
fab has joined #dri-devel
frieder has joined #dri-devel
frieder has quit []
frieder has joined #dri-devel
<pq>
kbingham, GBM is not OpenGL. GBM is not EGL, either. And obviously OpenGL is not EGL. Nor Vulkan. You do not want to allocate in OpenGL if you need a dmabuf, there are no sufficient APIs for that.
<pq>
kbingham, CPU cache is not the only cache in a machine. GPUs have caches and who knows what has caches.
<Prf_Jakob>
You can allocate in Vulkan tho plenty of API to go around there.
vliaskov has joined #dri-devel
<pq>
kbingham, AFAIU, while CPU may have uncached mapping, that means nothing to GPU caches which still need flushing in both directions correctly. Depending on the actual hardware, of course.
<pq>
kbingham, when you have a dmabuf, you can assume the worst case: that the buffer resides in VRAM, behind a slow bus and some caches you don't know about. That makes the regular mmap() perilous, which is why gbm_bo_map() exists. Copying with DMA may be faster than direct access, even if you only ever read the buffer once.
<emersion>
pq, you mean copying to a staging GPU buffer?
anshuma1 has joined #dri-devel
tursulin has joined #dri-devel
<pq>
emersion, staging CPU buffer, or whatever magic gbm_bo_map() does.
<pq>
naturally the optimal magic to do is completely hardware dependent
pH5 has joined #dri-devel
<pq>
kbingham, regular mmap() of a dmabuf might be fast, or too slow, or not work at all. That depends on where the buffer physically resides, the exact hardware, and maybe the driver too. So if you must mmap, use gbm_bo_map().
jkrzyszt_ has joined #dri-devel
<pq>
kbingham, also, it's really hard to beat glReadPixels performance if that would be the simplest way to get the pixels.
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<mlankhorst>
airlied: no pull reques from me this week eiher it seems, both drm-misc-next-fixes and drm-misc-fixes are empthy
<mlankhorst>
empty*
mvlad has joined #dri-devel
lynxeye has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2880
frankbinns has joined #dri-devel
swalker__ has joined #dri-devel
<kbingham>
pq, That all sounds understandable, but it's up to dorota's implementation (which I haven't seen yet). But an application using libcamera will provide a buffer, which is expected to be either allocated by a V4L2 device (an encoder) or a display device (drm) ... or potentially routed through to dorota's allocator so she could allocate using GBM methods. But the application generically has control of what the target buffers are that her
<kbingham>
code will be writing data to with the shaders.
<kbingham>
The aim was to be able to move image processing away from the CPU and to the GPU. I expect there will be limitations along the way though.
<pq>
kbingham, right. That makes me wonder where is mmap going to be needed?
frankbinns has quit [Ping timeout: 480 seconds]
<pq>
kbingham, if libcamera is offering a helper library for allocating suitable buffers for CPU consumers, shouldn't that library also have API for mmapping?
<kbingham>
pq, I think so yes ;-)
<kbingham>
mmap can be needed to read the completed image.
<pq>
it sounded a bit like the application is given a dmabuf and then left to deal with it.
<kbingham>
It won't always be encoded or displayed - it could be written to file directly, or encoded with a software encoder.
<pq>
*dmabuf fd
<kbingham>
I created a 'MappedFrameBuffer' class, that could handle the sync ioctl. But pinchartl didn't like it - and wants to do something else. But that something else isn't done yet.
Major_Biscuit has joined #dri-devel
<pq>
until that something else, I'd very much recommend gbm_bo_map() (*after* glFlush), or glReadPixels for CPU access.
<kbingham>
pq, The difficulty is how to know if CPU access will occur or not. Or perhaps we assume it will always occur, and we do a glReadPixels into a second dmabuf ... but that seems ... wasteful.
<pq>
kbingham, yeah, that's what I don't understand. Why would you need to know if CPU access will occur before an appliction actually asks to mmap something?
<pq>
or rather, in my imagination, only applications that need CPU access will use the helper allocator API, so anything allocated through that helper is always going to be CPU-accessed. I suppose that's not how it's designed then?
<kbingham>
The 'soft isp' component is several layers down and separate is the distinction.
<pq>
why does that make a difference?
<kbingham>
And there is no public 'api' to help applications map the buffer.
<pq>
aha!
<kbingham>
So right now - applications have to do it directly
<pq>
yeah, that's the problem
<pq>
so applictions have to use GBM themselves to import the dmabuf and then gbm_bo_map()
<kbingham>
Yes - but that won't work for our design, as the application *wont know* GBM is being used.
<kbingham>
The application shouldn't know if it's OpenGL ISP - or a V4L2 ISP
<pq>
the app does not need to know
<pq>
the does not need to choose a DRM device to initialize GBM on, and that device would need to be compatible with the buffer that's actually used.
<pq>
that might be risky
<pq>
ok, another solution is that you tell apps what API to use to handle the buffers
<pq>
dmabufs are not equal vs. devices used to access them
anshuma1 has quit []
<kbingham>
indeed. But somehow we have to make a generic API that applications 'get a picture from the camera'
<pq>
right, and Wayland has a precedent of such buffer API
<kbingham>
And the application shouldn't care if that came from a USB UVC camera, or through a mipi-csi2 receiver into a hardware ISP ... or in this case that dorota is looking into, from a CSI2 receiver, then processed with the GPU.
<kbingham>
I don't know much about wayland internals. Can you point me to any documentation for that please?
<pq>
this involves knowing which device a buffer must be usable on, and communicating the supported formats and format modifiers.
jernej has joined #dri-devel
<emersion>
there are two sides: buffer producer and buffer consumer
<pq>
it's basically saying: the application must allocate a buffer that is usable on at least this device, and uses a format+modifier from this list.
<emersion>
one side needs to allocate, and the other side needs to communicate what constraints it needs to be able to use the buffer
<pq>
in Wayland, the allocating side (client/application) also writes the buffer and the server only reads it, but having server write and client read doesn't make much difference.
jernej_ has joined #dri-devel
<pq>
I guess one problem is figuring out the set of formats+modifiers the writer side can write, because with GPUs they can often read a lot more formats than write.
jernej has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
flto_ has joined #dri-devel
root__ has joined #dri-devel
Daanct12 has joined #dri-devel
<pq>
kbingham, I should also point out that Wayland has a completely separate interface (wl_shm) for CPU accessible buffers. Dmabuf are assumed to be not CPU accessed.
flto has quit [Ping timeout: 480 seconds]
<kbingham>
It will be harder for us to make that same assumption :(
kts has joined #dri-devel
flto_ has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
root__ has quit [Ping timeout: 480 seconds]
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
<pq>
kbingham, there are ways to gain CPU access, and gbm_bo_map() is one of the best, because it is implemented by the hardware driver that knows what it's doing.
<pq>
the catch is, the dmabuf needs to be usable for that hardware/driver
<kbingham>
If we can detect if it's not usable, we can reject the request.
macromorgan has quit [Read error: Connection reset by peer]
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #dri-devel
srslypascal has quit [Quit: Leaving]
srslypascal has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
vup has quit []
flto has joined #dri-devel
devilhorns has quit [Remote host closed the connection]
devilhorns has joined #dri-devel
devilhorns has quit []
vup has joined #dri-devel
rasterman has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest2894
srslypascal has joined #dri-devel
Guest2894 has quit [Ping timeout: 480 seconds]
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
jfalempe has quit [Quit: Leaving]
lplc has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
fahien has joined #dri-devel
Net147 has joined #dri-devel
jfalempe has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.6]
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
danvet has quit [Read error: No route to host]
srslypascal has quit [Ping timeout: 480 seconds]
lynxeye has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
cheako has quit [Quit: Connection closed for inactivity]
<agd5f>
LaserEyess, yes, the EDID
<LaserEyess>
ok thanks, I'll take a look
sdutt has joined #dri-devel
lynxeye has joined #dri-devel
fab has quit [Quit: fab]
lplc has joined #dri-devel
yuq825 has left #dri-devel [#dri-devel]
cheako has joined #dri-devel
Dr_Who has joined #dri-devel
JohnnyonFlame has joined #dri-devel
Haaninjo has joined #dri-devel
fxkamd has joined #dri-devel
iive has joined #dri-devel
lemonzest has joined #dri-devel
kts has joined #dri-devel
lrusak has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
lrusak has quit [Remote host closed the connection]
kts has quit []
lrusak has joined #dri-devel
ppascher has joined #dri-devel
lrusak has quit [Remote host closed the connection]
danvet has joined #dri-devel
kts has joined #dri-devel
fahien has quit [Quit: fahien]
hikiko_ has quit []
hikiko has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
heat has joined #dri-devel
Duke`` has joined #dri-devel
jfalempe_ has joined #dri-devel
fab has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
jfalempe has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
jewins has quit [Quit: jewins]
ybogdano has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
frieder has quit [Remote host closed the connection]
kem has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Remote host closed the connection]
kem has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
oneforall2 has joined #dri-devel
<emersion>
jadahl: can you give more details wrt the ENOENT you get with my patch and MST?
<emersion>
cant figure out how that could happen, my patch only changes the GETRESOURCES IOCTL
swalker__ has quit [Remote host closed the connection]
<dakr>
In hdlcd_crtc_atomic_disable(), hdlcd_write(hdlcd, HDLCD_REG_COMMAND, 0), which disabled the controller, is protected with drm_dev_{enter,exit} and hence on driver unload the controller never gets disabled.
<danvet>
dakr, yeah so this is a bit a mess, or at least unsatisfactory
<danvet>
because there's 2 demands on device hotunplug
<danvet>
1) real device hotunplug, where you want drm_dev_enter/exit protections to actually protect stuff
<danvet>
2) developer unloads the driver and expects the driver to shut down hardware, in which case you do _not_ want drm_dev_enter/exit protections
<danvet>
there's no solution here really :-(
<danvet>
what's generally done is that for devices that can actually hotunplug (like usb) we implement 1)
<danvet>
and for stuff that can't hotunplug (like platform_device) we implement 2)
<danvet>
and everyone is kinda unhappy
<danvet>
dakr, note that for both 1) and 2) you want to switch over to drmm anyway, because otherwise things go boom
<danvet>
it's really just the drm_dev_enter/exit parts
<danvet>
dakr, the really annoying thing is that with pci_device usually you never hotunplug them, most drivers go boom in spectacular ways
<dakr>
So, you'd suggest to just leave out the drm_dev_enter/exit for those?
<agd5f>
dakr, we have some ugly workarounds to deal with it since we need to support both
<danvet>
but also with thunderbolt and pcie enclosures pci hotunplug is absolutely a thing, even in upstream
<danvet>
agd5f, yeah iirc on pci devices you can check whether it got hotunplugged or not
<danvet>
and use that to decide between drm_dev_unplug and drm_dev_remove
<danvet>
but there's nothing generic
<danvet>
dakr, for platform_device that would be make take
<agd5f>
danvet, actually IIRC the pci hotplug stuff is less reliable than the drm stuff
<danvet>
for pci_device do what agd5f/amd does in amdgpu
<danvet>
agd5f, lol
<karolherbst>
the heck?
<danvet>
agd5f, I mean no surprise, it's all so much corner cases and untested
<karolherbst>
agd5f: I suspect most drivers don't properly check for out of bounds accesses once the pci subsystem returns -1 for everything on ioremaped memory
urja has quit [Read error: Connection reset by peer]
<agd5f>
danvet, and when you actually hotplug devices there are all sort of crashes in the PCI core that when you go to re-plug the devices, especially when you add PCI AER to the mix
urja has joined #dri-devel
<agd5f>
and it's hard to say whether those are just quirks of the platform or legit PCI core problems
<karolherbst>
surprise hot unplugging was a mistake
<danvet>
karolherbst, people like to be able to move their laptops
<karolherbst>
sure, it's the "surprise" part which is a mistake
<karolherbst>
but I understand the sentiment of TB connectors being loose
<danvet>
karolherbst, also users can't be taught
<danvet>
"it worked"
<karolherbst>
I know
<danvet>
but yeah surprise hotunplug is really, really hard
<karolherbst>
the port should make it physically impossible to remove the device, then users destroy their laptop or something :P
<danvet>
and then surprise replug is even harder
<danvet>
the worst case is pretty much flaky cable
<karolherbst>
yeah...
<karolherbst>
why does this even work with USB :P
gouchi has joined #dri-devel
<danvet>
I think gregkh is a full rewrite no 5 or so
<danvet>
ended up creating the entire linux driver and device model
<karolherbst>
understandably
<danvet>
and it still doesn't work, because the uapi side is fubar everywhere except in drm
<danvet>
(per gregkh this lpc at least)
<karolherbst>
we still have no solution for mapped memory though, right?
Major_Biscuit has quit [Ping timeout: 480 seconds]
<danvet>
drm has drmm and a todo.rst entry :-)
<karolherbst>
sounds like we have at least a plan then :)
<dakr>
danvet, if we leave out drm_dev_enter/exit for platform_device, couldn't we run into trouble with e.g. accessing devm_ioremap'd mmio areas?
<danvet>
karolherbst, I thought amd fixed that, we just map one page a looot of times on every fault :-)
<danvet>
dakr, yeah
<karolherbst>
danvet: honestly, I'd just crash the processes using the GPU, but guess that works as well
<danvet>
dakr, but if you do the drm_dev_shutdown before you nuke the iomap it /mostly/ works
<danvet>
karolherbst, I think it's nicer fit for vk/gl model of "we pretend everything keeps working right until you look a the VK_ERROR_DEVICE_LOST or gl_arb_robustness
<agd5f>
we have surprise hotplug working for a number of customers, but it involves some usleeps and retries in the PCI code in a few places
<danvet>
agd5f, glorious
<karolherbst>
danvet: true
<karolherbst>
that's more or less how Apple was/is doing it
<agd5f>
and we haven't had much traction getting the changes upstream
<danvet>
karolherbst, ofc the mmap contents are already a dumpster fire, but same happens for gpu hang
<danvet>
when you e.g. have to reset vram
<karolherbst>
yep
<danvet>
agd5f, :-(
<agd5f>
PCI DPC is pretty much the same thing
sravn has quit [Remote host closed the connection]
sravn has joined #dri-devel
<agd5f>
basically surprise hotplug due to a hardware error
Company has joined #dri-devel
<danvet>
dpc?
<agd5f>
danvet, Downstream Port Containment. PCI feature for datacenters
Leopold has joined #dri-devel
<agd5f>
if the hardware throws an error the bridge takes the link down
<danvet>
agd5f, is that related to data poison propagation or well prevention of that?
* danvet
forgot the exact word it's called
<agd5f>
trying to avoid bad data propogation
<dakr>
danvet, what if we'd set dev->unplugged just right before returning from driver unbind for platform devices?
<dakr>
such that for the cleanup we can still enter the critical sections.
tursulin has quit [Ping timeout: 480 seconds]
<danvet>
dakr, you can make arbitrary mixups of 1) or 2)
<danvet>
but you're just trading races really
<danvet>
setting the ->unplugged later means you open up against userspace races
<danvet>
so if you're unlucky and userspace does an ioctl right when you do your cleanup, you end up going boom
<agd5f>
FWIW, we mostly use the drm plug stuff, but with a few ugly kluges here and there
<danvet>
dakr, what might work maybe is a two step process
<dakr>
danvet, what about two flags?
<danvet>
dakr, yeah that's what I mean
<dakr>
yes, just was slow in typing.. :)
<danvet>
don't ask me for good naming
<danvet>
since atm all I can do is drm_dev_unplug and drm_dev_unplug_harder
<danvet>
dakr, but also, the issue is that for pci you still want to gate both flags on the first hotunplug if the device is actually gone
<danvet>
since letting every single mmio time out is not great
<danvet>
so pci might need a little helper which directly goes to 2nd level hotunplug if it's a real hotunplug
<dakr>
danvet, yes, then we'd need separate functions for platform and the rest.
<danvet>
well it sounds like agd5f wants the same stuff
<danvet>
for pci
<danvet>
but with a small twist
<danvet>
dakr, but for now I'd just respin your patch set with the drm_dev_enter/exit parts removed
<danvet>
since the drmm parts should be a good idea no matter what
<dakr>
yes.
<danvet>
and then maybe a drm_pci_unplug() which dtrt for pci
<danvet>
or we add a terrible layering violation to drm_dev_unplug, wouldn't be the first pci special case :-)
jkrzyszt_ has quit [Ping timeout: 480 seconds]
<dakr>
danvet, would it be pci only?
<danvet>
well there's no struct device level generic thing to check for "was this a real hotunplug or a driver unbind only"
<danvet>
so they all would be bus specific
<Frogging101>
Could there be?
<danvet>
and the drm_dev_unplug would still be the "yank everything at once assuming it's a hotunplug"
<danvet>
also maybe we should drag gregkh into this discussion
<danvet>
iirc he doesn't like it, but maybe we can convince him that there's a real need
<danvet>
dakr, agd5f the other thing I've thought about is just a knob to disable the drm_dev_enter/exit check
<danvet>
which developers using module unload could use
<Frogging101>
What about when the system shuts down? What path does it take then?
<danvet>
but that leaves the door open to sw issues when you put device pointers into drmm structs
<danvet>
Frogging101, that's not a driver unbind, but a driver pm->poweroff path
lygstate has joined #dri-devel
mhenning has joined #dri-devel
<dakr>
danvet, since you mentioned greg didn't like it, was this (or similar) already discussed?
<danvet>
dakr, I think it was just about figuring out whether it was hotunplug or user initiated unbind
<danvet>
and not trying to wrap this concept in drm and allow drivers to do what they feel like
rgallaispou has left #dri-devel [#dri-devel]
<dakr>
danvet, ah so exposing this information to a generic device. well, knowing that would be neat, since it'd prevent us from having all kinds of drm_*_unplug() functions.
<jadahl>
emersion: when DP is active via MST, on onplug, it disappears immediately from the list. on hotplug, mutter reads the current state, then does a new configuration. this new state no longer has this connector, but I suspect in the kernel it's still "active" (has an fbid). later, when a new device wide mode set commit is constructed, it fails with iirc EINVAL (not ENOENT)
<jadahl>
emersion: the ENOENT happened because the disabling of a disconnected connector didn't result in a new hotplug event, meaning nothing told mutter it should re-query currently existing connectors, and when it tried to disable it later on, it failed with ENOENT
<jadahl>
the latter could be worked around by requerying the kms state from the kernel some time after disabling
<jadahl>
s/onplug/unplug/
ybogdano has joined #dri-devel
srslypascal has joined #dri-devel
kem has joined #dri-devel
mbrost has joined #dri-devel
chipxxx has joined #dri-devel
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #dri-devel
zackr has quit [Ping timeout: 480 seconds]
<Ristovski>
If I understand correctly, ttm keeps allocated pages around so they can be reused later, right? Is it possible to forcefully release them without artificially causing high memory pressure?
Leopold has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
jernej_ has quit []
jernej has joined #dri-devel
jernej_ has joined #dri-devel
jernej_ has quit []
jernej_ has joined #dri-devel
jernej- has joined #dri-devel
heat has quit [Read error: No route to host]
jernej has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
jernej_ has quit [Ping timeout: 480 seconds]
mvlad has quit [Remote host closed the connection]
djbw has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
* danvet
dragging djbw on here for maybe some help with whatever agd5f and amd found in terms of pci hotplug entertainment
lygstate has quit [Remote host closed the connection]
mattst88_ has quit []
mattst88 has joined #dri-devel
dviola has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
uis has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
Leopold has joined #dri-devel
chipxxx has joined #dri-devel
chipxxx has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
Haaninjo has quit [Quit: Ex-Chat]
kts has joined #dri-devel
Leopold has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<LaserEyess>
agd5f: EDID says it's display port and does not seem to have monitor range tags in it, it lists two DTDs for the lower/upper range of VRR that seems to be reported on windows
<LaserEyess>
amd drivers report freesync for this panel on windows, I don't get it
ybogdano has quit [Ping timeout: 480 seconds]
<agd5f>
LaserEyess, does it have any additional EDID data blocks?
<agd5f>
hwentlan_, ^^ any idea how windows figures out that this panel supports freesync?
<LaserEyess>
I already wiped windows from this machine but I can reinstall and do some testing to see if that's just not a false positive on the windows side
ybogdano has joined #dri-devel
<LaserEyess>
I'm suspecting there is a chance this panel does not support freesync, actually, it was never advertised as such but I had someone check it out before I bought it
<agd5f>
LaserEyess, what laptop is this?
h0tc0d3 has joined #dri-devel
<LaserEyess>
thinkpad x13 gen 3, AMD Ryzen 5 PRO 6650U with Radeon Graphics
<jenatali>
David Heidelberg: I presume you're talking about CI?
<DavidHeidelberg[m]>
jenatali: exactly
<jenatali>
We don't currently have any, nor any plans to do so, though I wish we had something
iive has quit [Quit: They came for me...]
<karolherbst>
jenatali: is there a list of CL extensions you absolutely need? :D
<jenatali>
David Heidelberg: any particular reason you're asking?
<jenatali>
karolherbst: the only one I'm hearing these days is CL/GL interop
<karolherbst>
right... the annoying one :/
<jenatali>
Yeah, especially for an external runtime
<karolherbst>
still thinking on how to support that, but I suspect we'll have to use dma_buf for that
<DavidHeidelberg[m]>
jenatali: would be nice to run few d3d* tests on Windows to check the correctness of the tests
<karolherbst>
I got it working at some point, and I should probably get back to it, but the mesa stuff we have for that is quite annoying and I am thinking about rewriting it from scratch
<zf>
we have vague plans for a centralized location for GPU driver tests, basically :D
<karolherbst>
it's currently used by rocm afaik
<jenatali>
karolherbst: you'd need something on top of just dma-buf, since you need the ability to flush the GL context from CL IIRC
<jenatali>
I plan on dropping that into the test images for Mesa CI soon
<zf>
jenatali, is there a good place to report bugs? I don't think we at wine have ever done so before :D
<jenatali>
zf: here, to me is good enough
<jenatali>
I can get them filed
mhenning has quit [Ping timeout: 480 seconds]
<zf>
sure :D
<zf>
I'll have to look up a list, but just offhand, one is that pipeline statistics queries sometimes return S_OK from GetData() but the buffer is zeroed
<zf>
I think occlusion queries might have a similar problem
<zf>
I'd share the test, but it's LGPL 2.1, I don't know if that's a problem for you
<jenatali>
Yeah GPL is often tricky
<zf>
(it should be pretty easy to recreate, though)
ybogdano has quit [Ping timeout: 480 seconds]
alatiera has quit [Ping timeout: 480 seconds]
<jenatali>
zf: If you see problems with that fully up-to-date version of WARP still, then we can figure out how to get a proper test repro in the bug
<zf>
I can double check
<zf>
jenatali, anything we should do besides update the OS completely?
<jenatali>
Fully up-to-date client win11 should have pretty much all of my fixes
<zf>
alright, thanks
<jenatali>
But I've been focusing on D3D12 where queries look very different
vliaskov has quit [Remote host closed the connection]
<zf>
yeah
<zf>
oh, the other thing I think is that warp doesn't support ddraw?
aravind has joined #dri-devel
<jenatali>
It does
<zf>
oh, I'm looking at win64, that's why :D
<jenatali>
Maybe not all of the features though
<zf>
yeah, now that I look at the right place, it seems like it supports most things
<zf>
I mostly notice it's missing YUV
<zf>
and luminance textures
mbrost has quit [Ping timeout: 480 seconds]
<zf>
well, if warp is reliable enough these days that we can run tests against it, then great :D
alatiera has joined #dri-devel
<jenatali>
That's what we largely test against
<airlied>
I think I saw you can even download wrap now
<airlied>
warp
<zf>
makes sense
* airlied
wonders would warp work under wine :-P
<zf>
reference rasterizers are quite useful :D
<jenatali>
For D3D9 or older it'll be missing some extensions and stuff, but you could do 9on12 for those which is open-source and supports more stuff
<zf>
we vaguely have support for d3d10+ layers, but I doubt it's ever been tested
<jenatali>
airlied: probably not, it needs a kernel driver these days
<zf>
probably we just implemented it that way because something something dxgi
<zf>
we can kind of do kernel drivers, but it depends what the kernel driver wants to do
<jenatali>
zf: it's an OS kernel graphics driver (basic render), kind of like vgem
<zf>
jenatali: hmm, is it still necessary for surfaceless rendering?
<jenatali>
Yes
<zf>
though if it uses the d3dkm stuff, that's not going to work now, if ever
<jenatali>
It does
<jenatali>
But yeah when it comes to wine I do need to be relatively separate from it - but where it intersects with improving Windows I'll take it
YuGiOhJCJ has joined #dri-devel
<zf>
yeah, makes sense
mbrost has joined #dri-devel
<anholt>
jekstrand: right now tu is over-synchronizing for implicit sync. is anv's create_sync_for_memory the current state of the art here?