ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
RAOF has quit [Remote host closed the connection]
RAOF has joined #dri-devel
guludo has quit [Quit: WeeChat 4.4.2]
sassefa has joined #dri-devel
sassefa has quit []
sassefa has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
LeviYun has quit [Ping timeout: 480 seconds]
ellyq_ has quit []
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
epoch101 has joined #dri-devel
LeviYun has joined #dri-devel
pcercuei has quit [Quit: dodo]
LeviYun has quit [Ping timeout: 480 seconds]
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
amarsh04 has quit []
alane has quit []
alane has joined #dri-devel
amarsh04 has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
LeviYun has joined #dri-devel
alanc has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
<DavidHeidelberg>
mareko: what about asking for llvm18 only with new HW support enabled? For CI it would be most reasonable to wait until Debian gets soft-freeze and then bump it
LeviYun has joined #dri-devel
epoch101 has quit []
<airlied>
Ermine: TTM has no core drm impact
<airlied>
so drivers can just use it
Daanct12 has quit [Quit: WeeChat 4.4.2]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
Daanct12 has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
nep_nep has left #dri-devel [#dri-devel]
LeviYun has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<a-865>
Is this likely describing a bug?:
<a-865>
Sep 16 23:30:08 kernel: [drm] Initialized nouveau 1.4.0 20120801 for 0000:01:00.0 on minor 0
<a-865>
Sep 16 23:30:08 kernel: nouveau 0000:01:00.0: DRM: DDC responded, but no EDID for DVI-D-1
<a-865>
Sep 16 23:30:08 kernel: nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes
<a-865>
started post-6.6.x kernel with GK107 10de:0fc1 in Feb. or Mar.
Duke`` has joined #dri-devel
LeviYun has joined #dri-devel
<a-865>
symptom?
sassefa has quit []
<airlied>
it's a we tried to probe the monitor, it's there but it didn't respond
bmodem has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
<a-865>
airlied: can you postulate why?
glennk has joined #dri-devel
<a-865>
local I/0 totally absent with kernels doing this
<K900>
Bad cable?
<K900>
Could just be a bad cable
<airlied>
sounds like something in the ddc/i2c broke or bad cable
<K900>
Though it's pretty hard to fuck up a cable so that I2C only works _sometimes_
<a-865>
nothing wrong with cables. Occurs only with kernels > 6.6.50, on every installed distro, regardless whether both displays are connected to DVI ports, or one DVI and one HDMI
<daniels>
mareko: hmm, I thought AMD drivers were just supposed to be dropped into any distro without any system changes
hansg has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
warpme has quit []
nerdopolis has joined #dri-devel
<mareko>
daniels: with ACO that's true
sgerhold has joined #dri-devel
<mareko>
DavidHeidelberg: let's wait for when debian upgrades to llvm18 and then we bump it
<mupuf>
in debian stable or sid?
<mupuf>
or testing?
<mupuf>
FYI, it is already in testing and sid
<mupuf>
if stable, then you'll have to wait another year
libv_ is now known as libc
libc has left #dri-devel [#dri-devel]
libc has joined #dri-devel
libc has quit []
libc has joined #dri-devel
libc has left #dri-devel [#dri-devel]
libv has joined #dri-devel
siak_ has joined #dri-devel
siak has quit [Ping timeout: 480 seconds]
<tjaalton>
sid is already on 18, ubuntu 24.10 is on 19
<tjaalton>
the failure to find opencl-c-base.h is probably due to some change in the llvm-toolchain-19 packaging
<tjaalton>
happens on debian too now that I tried
<dj-death>
I think it's 18+
<tjaalton>
but the mesa packaging is on 18 already, and didn't fail before
<dj-death>
hmm then I don't know
<dj-death>
something else :)
mlankhorst has joined #dri-devel
vliaskov_ has quit []
<DavidHeidelberg>
mupuf: not whole year, I think we can switch images in soft freeze, where we don't have to be afraid of breaking changes
vliaskov has joined #dri-devel
<mupuf>
DavidHeidelberg: ack, well, you know better than me Debian's practices
<mupuf>
I mean, my understanding is ~0, I just usually get annoyed and walk away grumbling :D
<DavidHeidelberg>
mupuf: I was thinking.. maybe.. the CI could be switched to Ubuntu (6m release cycle), but I'm not sure if anyone would spend time to bumping it
<mupuf>
realistically what are the odds for breaking changes in testing though?
<DavidHeidelberg>
mupuf: I recently become Debian Maintainer, so I got used to it :D Modern packages are fine, the older ones and special ones are pain and suffering
<tjaalton>
dj-death: well, the patch did help with llvm-19 anyway ;)
<dj-death>
tjaalton: good
<DavidHeidelberg>
mupuf: well, I remember bumping CI to bookworm and... there was lot of work and lot of expectations unexpectedly passed/failed..
<mupuf>
oh, wow, ok
<mupuf>
bbl!
f11f12 has quit [Quit: Leaving]
libv_ has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
libv has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
siak has joined #dri-devel
fab_ has joined #dri-devel
fab_ is now known as Guest3723
Guest3723 has quit []
fab has joined #dri-devel
libv has joined #dri-devel
siak_ has quit [Ping timeout: 480 seconds]
libv_ has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
pcercuei has joined #dri-devel
<mareko>
DavidHeidelberg: I'd like to bump the LLVM version requirement to 18, but I can do when it's most convenient for the CI
<mareko>
*I can do it
guludo has joined #dri-devel
siak_ has joined #dri-devel
epoch101 has joined #dri-devel
<karolherbst>
mareko: as I'm looking more into SVM these days, is there a way with amdgpu to guarantee that allocations across GPUs to have the same virtual address?
<pepp>
mareko: couldn't the requirement be bumped per gfx version? I don't think LLVM18 makes a major difference vs LLVM15 for gfx8 for instance
siak has quit [Ping timeout: 480 seconds]
<mareko>
pepp: it's a built-time requirement
<mareko>
*build
warpme has quit []
<mareko>
karolherbst: for ROCm or Mesa?
siak_ has quit [Ping timeout: 480 seconds]
<karolherbst>
mesa
<karolherbst>
I already have a prototype which works across drivers/devices for anything doing userspace vm management, but I don't think radeonsi supports that, nor do I know if it's in theory supported by amdgpu
<pepp>
mareko: hmm true. I guess LLVM is not meant to be used with a runtime version >= build-time version
<mareko>
yes, each llvm version is a separate lib, libllvm18 etc.
<mareko>
karolherbst: the addresses are assigned by userspace, it's solvable with mesa changes only I think
<karolherbst>
ohh, they are?
<mareko>
the kernel only exposes an empty virtual address space with a small area reserved for the kernel, the rest is up to us to assign
<mareko>
libdrm provides a virtual address allocator as a utility
<karolherbst>
ohh, libdrm is doing it, figures
<mareko>
but we can use any address range that's free
<karolherbst>
so the way I considered doing it, is that rusticl reserves an address range and manages it itself
<karolherbst>
and drivers tell in which range an area can be reserved
<mareko>
yes that's doable
<karolherbst>
okay, cool
<mareko>
the only limitation is that address bits 47-63 must be 1
<karolherbst>
right.. iris has the same limitation
<mareko>
that naturally doesn't intersect with any CPU addresses
<karolherbst>
so for iris I just excluded that range rusticl could reserve, because it's just messy to use those ranges for SVM
<mareko>
it also doesn't conflict with ROCm sharing the same address space and mirroring the whole CPU address space in there
<karolherbst>
(like in theory the shader could sign-extend the address, but halfing the availble VM range isn't an issue at all)
LeviYun has quit [Ping timeout: 480 seconds]
<karolherbst>
mhh, maybe I get SVM working with iris + radeonsi until XDC then... would be kinda cool
<mareko>
the only short-term obstacle is that radeonsi also uses the same range for command buffers, shaders, and the scratch buffer for spills and arrays
<mareko>
and ring buffers for the gfx pipeline
<karolherbst>
mhh, why would that be an issue?
<mareko>
you can't use those addresses
<mareko>
it will only work if we reserve a piece of the address range just for rusticl
<karolherbst>
yeah, that's the idea
<karolherbst>
it's already implemented for e.g. iris
<karolherbst>
so rusticl just allocates some VM space from the driver and assigns addresses out of that range to resources allocated with a special flag
<mareko>
karolherbst: on a different note, it's non-conformant to evaluate constant expressions at compile time because the rounding mode can be unknown if it's changed at runtime
jsa has quit [Ping timeout: 480 seconds]
<karolherbst>
there is no way to change it at runtime tho
<karolherbst>
maybe there is an extension and maybe it was planned to do it, but core CL doesn't allow it
<mareko>
so ROCm doesn't evaluate constant expressions at compile time because of that
<karolherbst>
heh
<mareko>
e.g. sqrt(3)
LeviYun has joined #dri-devel
<karolherbst>
interesting
<karolherbst>
maybe ROCm implements an extension so it matters, but it's still a bit strange
<karolherbst>
there was e.g. cl_khr_select_fprounding_mode to change the rounding mode at compile time
<karolherbst>
maybe it has CUDA reasons for why they aren't doing it
<karolherbst>
*CUDA/HIP
<mareko>
arguably even the current way is non-conformant because sqrt evaluated on the CPU and GPU can produce slightly different results
<karolherbst>
yeah..
<karolherbst>
I don't think the CL spec says anything at all here
<karolherbst>
so I think it matters what the C99 spec says
nashpa has quit [Ping timeout: 480 seconds]
<mareko>
it seems unlikely that sqrt is allowed to generate 2 different results for the same value (one is a constant and the other isn't)
<mareko>
a compiler could run a shader to evaluate constant expressions on the target device instead of the CPU
<karolherbst>
mhhhh yeah...
<karolherbst>
I think the conclusion from the last time I had the discussion was, that constant folding is allowed to show different results
<karolherbst>
I even landed a CTS fix recently which moved a calculation from compile time to runtime
<karolherbst>
but maybe I need to dig deeper into the C spec and figure out what's the situation there
<karolherbst>
mareko: there is e.g. the gcc -frounding-math compiler flag which disables constant folding by assuming some default rounding mode
<karolherbst>
which is disabled by default, which means that the compiler will be happy to constant fold
<karolherbst>
though floating point constants in C code is also usually promoted to double, so not sure it even matters much
<karolherbst>
(and maybe they get promoted due to this reason)
<karolherbst>
C99: "If a floating expression is evaluated in the translation environment, the arithmetic precision and range shall be at least as great as if the expression were being evaluated in the execution environment."
warpme has joined #dri-devel
Schrostfutz_ has joined #dri-devel
mainakchhari has quit [Remote host closed the connection]
jsa has joined #dri-devel
Daanct12 has quit [Quit: WeeChat 4.4.2]
dliviu has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
Kwiboo has quit [Quit: .]
Schrostfutz_ has quit [Read error: Connection reset by peer]
Kwiboo has joined #dri-devel
Kwiboo has quit []
sassefa has joined #dri-devel
Kwiboo has joined #dri-devel
hansg has quit [Quit: Leaving]
bolson has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
frieder has quit [Remote host closed the connection]
rasterman has quit [Quit: Gettin' stinky!]
dsimic is now known as Guest3736
dsimic has joined #dri-devel
Guest3736 has quit [Ping timeout: 480 seconds]
<cambrian_invader>
if I have a gpgpu+display driver, and I want to set up a framebuffer, who is responsible for ensuring that both the gpgpu and the display driver can DMA the framebuffer?
<cambrian_invader>
e.g. if the display driver supports a larger address space than the gpu
<cambrian_invader>
then the sequence drm_create_dumb(display); drm_handle_to_fd(display); drm_fd_to_handle(gpu) will fail since the GPU won't be able to address the buffer
<cambrian_invader>
(or might not, but it's likely)
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
Kwiboo has quit []
Kwiboo has joined #dri-devel
Kwiboo has quit [Read error: Connection reset by peer]
Kwiboo has joined #dri-devel
sassefa has joined #dri-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
Kayden has quit [Quit: Leaving]
Kayden has joined #dri-devel
Duke`` has joined #dri-devel
heat is now known as Guest3737
Guest3737 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
hansg has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
sassefa has quit []
mbrost has joined #dri-devel
<cambrian_invader>
huh "Note that dumb objects may not be used for gpu acceleration"
<cambrian_invader>
so maybe this is a mesa bug
<emersion>
cambrian_invader: dumb buffers are specifically for display
kts has joined #dri-devel
<emersion>
and for CPU rendering
<cambrian_invader>
yeah, but as noted above the problem occurs when sharing it with the gpu
<emersion>
if you want a buffer which can do rendering + display, you'd need to use GBM
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
LeviYun has joined #dri-devel
mbrost has joined #dri-devel
gouchi has joined #dri-devel
<a-865>
Lyude: 6.6.11 (suse), 6.6.18 (suse), 6.6.24 (suse), 6.6.28 (mageia), 6.6.32 (suse), 6.6.50 (mageia & suse) all work as expected
<Ermine>
airlied, MrCooper thank you for your answers
guludo has quit [Quit: WeeChat 4.4.2]
guludo has joined #dri-devel
edolnx has joined #dri-devel
<uriah>
pepp: hi, I'm sorry to bother you about this, but I am very curious, and willing to experiment with trying to update your qemu amdgpu native context commits for newer qemu, but is this work by chance already elsewhere, or being collaborated on between various driver devs for compatibility with all the various efforts?
plouton has joined #dri-devel
<pepp>
uriah: hi. digetx might have a more recent branch
<uriah>
Ok
<uriah>
I saw that and just wanted to be sure
<uriah>
There are 2, one for intel and one possibly more general?
<uriah>
Also, I saw v12 qemu venus patch series; is that meant to be separate, or behind the native context commits?
<pepp>
I think so. The native-context one seems to have everything required for amdgpu nctx
<uriah>
Ok
hansg has quit [Remote host closed the connection]
<uriah>
Sweet thanks
<pepp>
venus / nctx are separate, but share some infrastructure work in qemu
<uriah>
Ok
<uriah>
So I should try both at once and see where I get?
Haaninjo has joined #dri-devel
<uriah>
As in, both patch series, and test whether either works individually
<uriah>
Like, in the future... would people adopt a choice between both?
<uriah>
Especially considering wanting venus for legacy hardware that won't be supported by native context?
<uriah>
Or am I misunderstanding the intel side, which is currently iris and up?
<uriah>
(I would also be interested in trying to port digetx's work to i915/i965)
<uriah>
I have an old retina haswell laptop xD
Lucretia has quit [Ping timeout: 480 seconds]
<uriah>
Anyhow thank you so much for answering
edolnx has quit [Ping timeout: 480 seconds]
edolnx has joined #dri-devel
Ryback_ has joined #dri-devel
dviola has joined #dri-devel
Lucretia has joined #dri-devel
warpme has joined #dri-devel
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
<DemiMarie>
budgetazoo: support for Intel native context on older hardware would be great, but IOCTLs should be gated based on the hardware version to avoid exposing unnecessary attack surface.
warpme has quit [Remote host closed the connection]
warpme has joined #dri-devel
vliaskov has joined #dri-devel
Calandracas has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
<uriah>
Demi: noted.
<cambrian_invader>
ok, so I wrote a patch for mesa to create the framebuffer with the gpu driver and then transfer it to the display driver
<DemiMarie>
budgetazoo: thanks! At some point it might make more sense to have a separate renderer but I’m not sure.
<cambrian_invader>
but it doesn't always work because drm_gem_dma_prime_import_sg_table wants a contiguous buffer
<cambrian_invader>
the DMA for this device does support scatter-gather; do I need to convert to shmem for that to work?
Calandracas_ has quit [Ping timeout: 480 seconds]
<cambrian_invader>
and where do I hook into the dma stuff?
mbrost has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
warpme has quit []
warpme has joined #dri-devel
cascardo has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
cascardo has joined #dri-devel
warpme has quit []
warpme has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
tobiasjakobi has quit [Remote host closed the connection]
tobiasjakobi has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
gio_ has joined #dri-devel
gio has quit [Ping timeout: 480 seconds]
tobiasjakobi has quit []
gouchi has quit [Remote host closed the connection]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
warpme has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
warpme has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
libv has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
libv_ has joined #dri-devel
libv has quit [Ping timeout: 480 seconds]
alyssa has joined #dri-devel
<alyssa>
robclark: for honeykrisp+virtgpu, I'm getting a lot of log spam:
<alyssa>
TU: error: ../src/freedreno/vulkan/tu_knl_drm_virtio.cc:1299: could not get connect vdrm: No such file or directory (VK_ERROR_INCOMPATIBLE_DRIVER)
libv_ is now known as libv
warpme has quit [Ping timeout: 480 seconds]
<alyssa>
wonder if we can make turnip less noisy...? "have virtgpu but not adreno virtgpu" shouldn't really be different than "don't have msm or kgsl"
sassefa has quit []
<Ermine>
I guess drm_gem_cma_mmap() is not a thing nowadays?
guludo has quit [Quit: WeeChat 4.4.2]
<cambrian_invader>
Ermine: it's drm_gem_dma_* now
<uriah>
pepp: Demi: digetx's qemu patches did the trick for amdgpu native context to work here, it seems! Thanks so much!
<Ermine>
cambrian_invader: oh, thank you
<DemiMarie>
budgetazoo: which qemu patches?
<uriah>
[@_oftc_alyssa:matrix.org](https://matrix.to/#/@_oftc_alyssa:matrix.org) and thanks to your discussion irl too :>
<Ermine>
Also, in Documentation/gpu/drm-mm.rst: "To use drm_gem_mmap(), drivers must fill the struct struct drm_driver gem_vm_ops field with a pointer to VM operations" --- seems like outdated statement
mbrost has quit [Ping timeout: 480 seconds]
vliaskov has quit [Ping timeout: 480 seconds]
LeviYun has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
heat is now known as Guest3770
Guest3770 has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
CME_ has joined #dri-devel
CME has quit [Read error: Connection reset by peer]
warpme has quit [Ping timeout: 480 seconds]
plouton has quit []
LeviYun has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
rasterman has joined #dri-devel
<robclark>
alyssa: yeah, I guess that could probably be quieted down.. but probably not something I can look at this week
LeviYun has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mbrost has joined #dri-devel
warpme has joined #dri-devel
Lucretia has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
Company has quit [Remote host closed the connection]
heat is now known as Guest3773
heat has joined #dri-devel
Guest3773 has quit [Read error: Connection reset by peer]