tobiasjakobi has quit [Remote host closed the connection]
frieder has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
RobertC has joined #dri-devel
thellstrom has joined #dri-devel
Danct12 has quit [Quit: Quitting]
ramaling has quit [Remote host closed the connection]
thellstrom1 has quit [Remote host closed the connection]
ramaling has joined #dri-devel
Danct12 has joined #dri-devel
<MrCooper>
bnieuwenhuizen: amdgpu evicts a BO from VRAM to system RAM for CPU access only if it's not currently CPU visible, and there's no space for it in the CPU visible part of VRAM; i.e. never with resizable BAR
mbrost has joined #dri-devel
khfeng has joined #dri-devel
yk has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
khfeng_ has joined #dri-devel
khfeng has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
Ahuj has joined #dri-devel
pcercuei has joined #dri-devel
khfeng_ has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
phomes has quit [Quit: Page closed]
<pq>
danvet, I'm like a moth to a flame... when I see it, I can't help myself.
<pq>
bnieuwenhuizen, given that dumb buffer mmaps do not get torn down before using them in KMS, I doubt moving them.
<daniels>
pq, emersion: ++ for the UAPI feedback, super helpful you are both keeping on top of it and trying to keep it coherent :)
<emersion>
<3
elongbug has joined #dri-devel
<pq>
thanks!
yk has joined #dri-devel
<pq>
but as pinchartl wrote, it may be futile anyway.
<MrCooper>
bnieuwenhuizen: a couple of things to keep in mind for that dma-buf related code: 1) it only moves to GTT where that's supported for scanout, i.e. only with newer APUs, not any dGPUs 2) it's only relevant when PCIe p2p is supported, otherwise dma-bufs are always pinned to GTT while shared with another device
luzipher__ has quit [Ping timeout: 480 seconds]
<MrCooper>
I guess this could be called while it's not shared though
itoral has joined #dri-devel
mbrost has quit [Remote host closed the connection]
Peste_Bubonica has joined #dri-devel
phomes has joined #dri-devel
i-garrison has joined #dri-devel
khfeng_ has joined #dri-devel
RobertChiras has joined #dri-devel
RobertC has quit [Ping timeout: 480 seconds]
RobertChiras has quit [Ping timeout: 480 seconds]
blue__penquin has quit [Quit: Connection closed for inactivity]
itoral has quit [Remote host closed the connection]
NiksDev has quit [Ping timeout: 480 seconds]
<mriesch>
hi all, are there ongoing efforts to update the mainline rockchip drm drivers to support the new quartz64 board? ezequielg: looking in your direction ;-)
NiksDev has quit [Remote host closed the connection]
sdutt has joined #dri-devel
jewins has joined #dri-devel
sdutt has quit []
Duke`` has joined #dri-devel
camus1 has joined #dri-devel
sdutt has joined #dri-devel
camus has quit [Remote host closed the connection]
rsalvaterra has joined #dri-devel
phomes has quit [Quit: Page closed]
Ahuj has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
idr has joined #dri-devel
GloriousEggroll has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
blue__penquin has quit []
NiksDev2 has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
gouchi has joined #dri-devel
<daniels>
not off the top of my head - we do have some virgl-on-crosvm testing, but I don't know off the top of my head if it covers GLES guests, and assuming you're using the proprietary Mali drivers, we don't test on those either (Panfrost ftw)
<daniels>
*GLES hosts
<robclark>
virgl-on-crosvm does work with mesa/freedreno fwiw, I've seen it with my own two eyeballs ;-)
<robclark>
it could be proprietary driver misses some extensions that virglrenderer needs?
frieder has quit [Remote host closed the connection]
<imirkin>
virglrenderer desperately wants some mesa-only ES exts to make desktop GL work properly
<imirkin>
(not technically mesa-only, but practically)
<robclark>
yeah, that sound quite likely
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
mixfix41_ has joined #dri-devel
mixfix41 has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
NiksDev has joined #dri-devel
mbrost has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
Kayden has quit [Quit: Leaving]
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
khfeng_ has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
phomes has joined #dri-devel
ngcortes has joined #dri-devel
mbrost has joined #dri-devel
mriesch has joined #dri-devel
<mriesch>
hi all! are there ongoing efforts to mainline the rockchip drm driver for the quartz64 board? ezequielg: looking in your direction ;-)
<siqueira>
Hi MrCooper , hwentlan I'm working on a set of IGT failures that get fixed by this patch https://paste.centos.org/view/79dc2fa1 . However, I'm afraid that I can regress the userspace due to this issue https://gitlab.gnome.org/GNOME/mutter/-/issues/1108 (you made the kernel patch to fix it), as you can see in my commit description, I was not able to
<siqueira>
reproduce the problem. Could you share some of your thoughts on this change? Maybe I should test something else with this patch?
<danvet>
siqueira, maybe the igts just hard-code the assumption that cursor without primary plane is possible?
<danvet>
so we'd need to do a check for that first, and if it fails, skip the entire test?
<danvet>
s/entire/specific/
<danvet>
oh also nothing cursor specific here, just really any feature at all I guess
<danvet>
there's a lot of hw that requires primary plane to be on out there
jewins has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
<danvet>
siqueira, a lot of hw under drm/tiny
<danvet>
so much so that we made it a simple boolean to set in the plane check helper function
<danvet>
ah now that's not a helper
<danvet>
but tiny requires it
<danvet>
iirc
<danvet>
there's others
lemonzest has quit [Quit: Quitting]
<siqueira>
hhmmm... I tried to find something like drm_crtc_helper_funcs under tiny directory to check this boolean value under some atomic_check function, but looks like that tiny does not rely on this type of hook, right? Any hint on where I should look for this boolean value? I checked drm_plane and drm_plane_state and I did not see any reference to this
<siqueira>
check.
Anson[m] has joined #dri-devel
DextersHub has quit []
thellstrom has quit [Quit: thellstrom]
evadot has quit [Remote host closed the connection]
aura[m] has joined #dri-devel
manu has joined #dri-devel
mbrost has joined #dri-devel
<danvet>
siqueira, see drm_simple_kms_crtc_check
robertfoss has quit [Quit: WeeChat 2.6]
robertfoss has joined #dri-devel
pnowack has quit [Quit: pnowack]
Kayden has joined #dri-devel
robertfoss has quit []
robertfoss has joined #dri-devel
gouchi has quit [Remote host closed the connection]
robertfoss has quit [Quit: WeeChat 2.6]
robertfoss has joined #dri-devel
<jenatali>
jekstrand: I'm chatting with someone who's trying to take some SYCL code, take the device bits after it's been split from the host, convert to SPIR-V, and then try to send that through the CLOn12 compiler to get DXIL
<airlied>
jenatali: sounds like a lot of problems :-P
<jenatali>
They're bumping into some weirdness where LLVM + the translator produces built-ins in the global address space, which is against spec, since CL says they have to be Input... and then it casts them to generic for no good reason before loading them
<airlied>
jenatali: I assume that's the SPIRV-LLVM-Translator
<jenatali>
airlied: I think it shouldn't be that many, really
<jenatali>
Yeah, it is
* airlied
assumes latest version of everything are in use
<jenatali>
Yep
<airlied>
karolherbst: ^ might remember some of this as well
<jenatali>
Anyway, vtn doesn't like having the variable in the wrong address space and asserts before overriding it to system... and then nir validation blows up trying to cast from system -> generic
<jenatali>
And obviously the SPIR-V is incorrect, but really only barely incorrect, and I'm wondering how people would feel about some cheap hacks to make it work - seems like vtn consuming SYCL SPIR-V would be generally valuable
<karolherbst>
jenatali: ehh.. didn't we fix something like that in the translator?
<karolherbst>
this was before the spec got fixed though :D
<karolherbst>
maybe somebody broke it
<jenatali>
karolherbst: Oh, this is when mapping a CL C *function* to a built-in global variable
<karolherbst>
ahh
<jenatali>
But the CL C functions rely on name mangling, and since it's C, all user functions will be unmangled... so SYCL apparently devised their own way of getting at builtins
<karolherbst>
mhh
<karolherbst>
sounds annoying
<jenatali>
They abuse that C++ reserves names starting with double underscore, and say that __spirv_BuiltIn{Name} variables are decorated as built-in
<jenatali>
But in the LLVM IR they don't have any way of annotating that those need to be "input", since SPIR only defines address spaces 0 thru 4 (private, global, constant, local, generic)
mbrost has quit [Remote host closed the connection]
<karolherbst>
mhh, right
rasterman has quit [Quit: Gettin' stinky!]
mbrost has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
<agd5f>
jenatali, weird question, but do you know the timeout value windows uses for D3hot to D0 state transitions on PCI?
<jenatali>
agd5f: Not off the top of my head, no. I work higher in the stack than that
<agd5f>
jenatali, no worries. just curious
<jenatali>
If it's important I could probably find out
<agd5f>
The windows team is going to ask their contacts, so probably not a big deal. thanks though
<agd5f>
AMD windows team
ppascher has joined #dri-devel
iive has joined #dri-devel
<jekstrand>
jenatali: Uh... Fix SYCL?
<jenatali>
jekstrand: Yeah, I agree
<jekstrand>
I'm fine with doing simple things that get stuff running if we can't change said stuff but we should always try to fix the real bug