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
<airlied> a-865: 6.6.49 works?
<airlied> or not narrowed down that far?
<a-865> It's between late Feb and mid March in Leap's 6.4 kernel. 6.6.50 works. journalctl -b --dmesg: https://paste.opensuse.org/b833c8a4376d
<airlied> ah okay so anything 6.7+ doesn't
LeviYun has joined #dri-devel
<a-865> after 22 Feb., by 18 Mar.
<a-865> everything 6.7+ locks up local I/O=blackscreen, no keyboard
kaiwenjon has quit [Quit: WeeChat 3.8]
LeviYun has quit [Ping timeout: 480 seconds]
kaiwenjon has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
meltq has joined #dri-devel
lumidify has quit [Quit: leaving]
lumidify has joined #dri-devel
<a-865> journalctl -b --dmesg with Tumbleweed 6.9.9: https://paste.opensuse.org/14fabf9513df
fab has joined #dri-devel
meltq has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
blaztinn_ has quit [Remote host closed the connection]
blaztinn has joined #dri-devel
rasterman has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
frieder has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
<airlied> a-865: not sure what debug option might be useful
<airlied> Lyude: ^ you might know nouveau.debug=debug or drm.debug=255
<emersion> Lynne: sync_files are binary
bbrezill1 has quit []
bbrezillon has joined #dri-devel
<emersion> suncobj might be binary or timeline
<emersion> syncobj*
<emersion> wlr has code for these things fwiw
coldfeet has joined #dri-devel
kts has joined #dri-devel
LeviYun has joined #dri-devel
sghuge has quit [Remote host closed the connection]
kts has quit [Quit: Leaving]
sghuge has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
vliaskov has joined #dri-devel
vliaskov_ has joined #dri-devel
warpme has joined #dri-devel
Haaninjo has joined #dri-devel
vliaskov has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
fab has quit [Ping timeout: 480 seconds]
jsa has joined #dri-devel
siak has joined #dri-devel
jkrzyszt has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
warpme has quit []
LeviYun has joined #dri-devel
lynxeye has joined #dri-devel
MrCooper has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
f11f12 has joined #dri-devel
<MrCooper> Ermine: FYI, the brand-new xe driver uses TTM
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
fab has joined #dri-devel
fab is now known as Guest3711
LeviYun has quit [Ping timeout: 480 seconds]
<Lynne> emersion: syncobj?
LeviYun has joined #dri-devel
Guest3711 has quit [Ping timeout: 480 seconds]
fab_ has joined #dri-devel
fab_ is now known as Guest3713
kts has quit [Quit: Leaving]
LeviYun has quit [Ping timeout: 480 seconds]
LeviYun has joined #dri-devel
jsa has quit [Ping timeout: 480 seconds]
<emersion> a sync_file may only exist once GPU work has been submitted
<emersion> a drm_syncobj is a container which can hold zero, one or more sync_files
sima has joined #dri-devel
kts has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Company has joined #dri-devel
jaya has quit [Remote host closed the connection]
Guest3713 has quit [Ping timeout: 480 seconds]
<Lynne> emersion: ah, I see, so I can get an implicit sync_file out of a dmabuf, or, with explicit sync, I could get a syncobj
jsa has joined #dri-devel
warpme has joined #dri-devel
kts has quit [Quit: Leaving]
<dj-death> karolherbst: maybe you have some interest in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30711 ?
<dj-death> karolherbst: not sure what changed in ubuntu 24.10 but it's always failing to build stuff with the llvm header without that change
<dj-death> since it's just adding another directory I don't think it'll break other distros
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<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> mhhh
<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]
Mangix has joined #dri-devel
jsa has joined #dri-devel
sassefa has quit []
<a-865> airlied: https://gitlab.freedesktop.org/drm/nouveau/-/issues/385 is my report about this kepler no EDID
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
dliviu has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
dliviu has joined #dri-devel
bolson_ has joined #dri-devel
kzd has joined #dri-devel
bolson has quit [Ping timeout: 480 seconds]
feaneron has joined #dri-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
fab has joined #dri-devel
Kwiboo has quit [Quit: .]
Kwiboo has joined #dri-devel
fab has quit [Quit: fab]
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
<cambrian_invader> I don't know what I want :P
<cambrian_invader> here's a dump of the relevant calls https://paste.debian.net/1329632/
<cambrian_invader> and this is all downstream of gbm_dri_bo_create so I guess I am using GBM
sassefa has joined #dri-devel
warpme has quit []
jsa1 has joined #dri-devel
amarsh04 has quit []
jsa has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
sassefa has quit []
amarsh04 has joined #dri-devel
bmodem has quit [Remote host closed the connection]
bmodem has joined #dri-devel
<cambrian_invader> emersion: should mesa be using something other than renderonly_create_kms_dumb_buffer_for_resource ? like drm_mode_addfb ?
<cambrian_invader> that one doesn't seem to have any handles for controlling the buffer location
<MrCooper> addfb just allocates a KMS framebuffer handle for an existing BO, it doesn't create a new BO
<cambrian_invader> hm
<cambrian_invader> do you know of any examples of "hardware-specific ioctls"? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_dumb_buffers.c#n55
mbrost has quit [Remote host closed the connection]
sghuge has quit [Read error: Connection reset by peer]
sghuge has joined #dri-devel
libv has joined #dri-devel
mbrost has joined #dri-devel
libv_ has quit [Ping timeout: 480 seconds]
<cambrian_invader> https://lore.kernel.org/dri-devel/20230803100041.387404-1-contact@emersion.fr/ makes the same point, which seems to indicate that the strategy employed by mesa here is incorrect
mattrope has quit [Remote host closed the connection]
mattrope has joined #dri-devel
tobiasjakobi has joined #dri-devel
pzanoni has quit [Read error: Connection reset by peer]
lstrano_ has quit [Remote host closed the connection]
Ryback_ has quit [Remote host closed the connection]
lstrano_ has joined #dri-devel
pzanoni has joined #dri-devel
dolphin has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
lstrano_ has quit [Remote host closed the connection]
Mangix has quit [Read error: Connection reset by peer]
shankaru has quit [Read error: Connection reset by peer]
guludo has quit [Read error: Connection reset by peer]
aswar002 has joined #dri-devel
Mangix has joined #dri-devel
lstrano_ has joined #dri-devel
guludo has joined #dri-devel
shankaru has joined #dri-devel
dolphin has joined #dri-devel
kxkamil has quit [Remote host closed the connection]
kxkamil has joined #dri-devel
unerlige has quit [Remote host closed the connection]
unerlige has joined #dri-devel
plouton has quit []
jsa1 has quit [Remote host closed the connection]
jsa has joined #dri-devel
<cambrian_invader> ok, so I guess mesa should use lima_bo_create somehow?
<cambrian_invader> "In practice, it would mean that you'd stop using renderonly_create_kms_dumb_buffer_for_resource, and replace it with your own driver-specific allocation ioctl on the render node." https://gitlab.freedesktop.org/mesa/mesa/-/issues/5510#note_1248284
bolson_ has quit [Remote host closed the connection]
bolson has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
Mangix has quit [Ping timeout: 480 seconds]
Mangix has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
jsa has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
kts has quit [Quit: Leaving]
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
jessica_24 has joined #dri-devel
riteo has joined #dri-devel
tobiasjakobi has quit []
coldfeet has quit [Remote host closed the connection]
Lucretia has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
docmax__ has joined #dri-devel
docmax_ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
LeviYun has quit [Ping timeout: 480 seconds]
guludo has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
guludo has joined #dri-devel
<Lyude> a-865: hm, looking at https://gitlab.freedesktop.org/drm/nouveau/-/issues/385 are you saying this would happen between upstream kernels 6.6.50 and 6.7.9?
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]
Mangix has joined #dri-devel
warpme has quit [Ping timeout: 480 seconds]
sassefa has joined #dri-devel
edolnx has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
sassefa has quit []
tobiasjakobi has joined #dri-devel
edolnx has joined #dri-devel
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 :>
<uriah> Uh oh I matrixed apologies
<uriah> Demi: the 4 last commits applied on top of v12 venus patch series https://gitlab.freedesktop.org/digetx/qemu/-/commits/native-context
<uriah> Using qemu-9.1 and linux 6.10.10 rn
<uriah> I will push a repo for how to get it working on gentoo asap
<uriah> Demi: v17 actually sorry. From august 22
<uriah> v12 is what I used for kernel venus under pepp's linux commits
<uriah> (Which I edited a bit to get up to 6.10.10)
benjaminl has quit [Read error: Connection reset by peer]
benjaminl has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
LeviYun has joined #dri-devel
<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]
LeviYun has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel