ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
vliaskov_ has quit [Remote host closed the connection]
shashanks_ has joined #dri-devel
<jenatali>
!27023 should fix it
<jenatali>
Only an 8 year old bug...
shashanks has quit [Ping timeout: 480 seconds]
Mangix has quit [Ping timeout: 480 seconds]
glennk has joined #dri-devel
ADS_Sr_ has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: -> home]
ADS_Sr has joined #dri-devel
Mangix has joined #dri-devel
mbrost has joined #dri-devel
flynnjiang has joined #dri-devel
yyds has quit [Remote host closed the connection]
Haaninjo has quit [Quit: Ex-Chat]
mattrope has quit [Remote host closed the connection]
columbarius has joined #dri-devel
Leopold has quit [Remote host closed the connection]
co1umbarius has quit [Ping timeout: 480 seconds]
M839ty9[m] has joined #dri-devel
yyds has joined #dri-devel
elongbug has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
mbrost has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
heat_ has quit [Ping timeout: 480 seconds]
ngcortes has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
aknautiy has left #dri-devel [#dri-devel]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
mbrost has joined #dri-devel
yyds has quit [Remote host closed the connection]
mbrost has quit [Remote host closed the connection]
yyds has joined #dri-devel
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
Leopold has joined #dri-devel
Leopold has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
kts has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
simondnnsn has quit [Read error: No route to host]
simondnnsn has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
kts has quit [Remote host closed the connection]
kts has joined #dri-devel
fab has joined #dri-devel
kts has quit []
Ryan_ has joined #dri-devel
Ryan_ has quit []
vyivel has quit [Read error: Connection reset by peer]
vyivel has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
mszyprow has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
hansg has joined #dri-devel
Mangix has quit [Remote host closed the connection]
Mangix has joined #dri-devel
camus has joined #dri-devel
kzd has quit [Ping timeout: 480 seconds]
camus1 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
fab has quit [Quit: fab]
glennk has joined #dri-devel
macslayer has quit [Ping timeout: 480 seconds]
sima has joined #dri-devel
fab has joined #dri-devel
tzimmermann has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
Leopold_ has joined #dri-devel
egbert has quit [Read error: Connection reset by peer]
egbert has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
frankbinns has quit [Ping timeout: 480 seconds]
kxkamil has quit []
tursulin has joined #dri-devel
kxkamil has joined #dri-devel
frankbinns has joined #dri-devel
pa has quit [Quit: quit]
pa has joined #dri-devel
mvlad has joined #dri-devel
Net147_ has joined #dri-devel
Net147 has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
simondnnsn has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
flynnjiang has quit [Quit: flynnjiang]
simondnnsn has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
<karolherbst>
airlied, jenatali, gfxstrand: any thoughts on the llvm opaque pointers break linking spir-vs situation? tldr, the translator can't reconstruct a proper function signature, so the spirv using an external definition ends up generating the function all with uchar* pointers. We have three options here really: 1. link on an llvm level 2. make the translator always use uchar* pointers for function args (if exported) and cast to the proper thing
<karolherbst>
in the body 3. link on a nir level and just cast our way through that mess
macromorgan_ has joined #dri-devel
rasterman has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
jsa has joined #dri-devel
lynxeye has joined #dri-devel
glennk has quit [Ping timeout: 480 seconds]
any1 has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
rgallaispou has joined #dri-devel
Company has joined #dri-devel
jsa1 has joined #dri-devel
jsa has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
kts has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
glennk has joined #dri-devel
yyds has quit [Remote host closed the connection]
mvlad has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
simondnnsn has quit [Read error: Connection reset by peer]
heat_ has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
<mripard>
lynxeye: I recall a discussion involving etnaviv something like 5-6 years ago about designing some userspace interface to express the memory access constraints a DMA device could have, but I can't find it anymore
<mripard>
iirc you were involved in it, do you remember when it occured or the name of the thread?
bmodem has quit [Ping timeout: 480 seconds]
<karolherbst>
mhh.. I think I'm just gonna hack spirv-link, because I think the spirv target will fix it long term (question is if llvm-18 or 19 is read) and I don't feel like hacking up the translator
<sima>
jfalempe, dropped some comments about the design and mostly locking issues, since I'm assuming that all the details around drawing have been polished nicely already
<jfalempe>
sima, thanks a lot, I'm looking into that ;)
<jfalempe>
sima, I though that in the panic handler, only one CPU was still online, and thus locking wasn't needed there ?
<tomeu>
looks like xtensor isn't packaged, and I need it for my tests
<tomeu>
any ideas?
<sima>
jfalempe, but you're still not allowed to go boom on inconsistent state
<sima>
and I'm not sure you're actually guaranteed that the other cpus will stop, that needs inter cpu interrupts and who knows whether that works
<sima>
jfalempe, essentially the current panic code was developed with the "locking is optional" assumption, and john ogness is fixing that mistake since a few years now
<sima>
or well, trying
<sima>
the thing is, kms panic will be only one of an entire pile of panic dumpers/consoles
<sima>
we _must_ make sure that we _never_ make the situation worse and so prevent a subsequent console/dumper from doing its thing
<jfalempe>
sima, ok, got it, that also means that if one lock is taken at the time of panic, you won't see anything.
<jfalempe>
sima, but badly crashing is not a better option.
<sima>
jfalempe, also panics can come from nmi context, which can interrupt _any_ irq-disabled section or hardware interrupt
<sima>
jfalempe, yeah it has downsides, but if we end up breaking e.g. pstore or serial console in that case, then not only will you not get no kms output, but also no pstore or serial output
<sima>
you can try to be more clever with srcu, but it's _really_ hard
<sima>
given how buggy hand-rolled driver locking in kms usually is, I have no confidence drivers will get it right
rgallaispou has left #dri-devel [#dri-devel]
<jfalempe>
sima, Yes, I agree, it's still better to check with trylock() then
<sima>
jfalempe, also it will still be better than the current situation of no panic output on kms at all
<jfalempe>
sima, that depends on the locking time, I mean if the plane is locked 90% of the time, you won't see many panics. But that also means that the driver is very bad.
<sima>
jfalempe, the longest times are modesets usually, but at that point we don't have good chances anyway
<sima>
page-flips should be really quick
Leopold_ has joined #dri-devel
<sima>
and if we're unlucky and panic when that happens there's excellent chances it's the driver itself that went boom, and so a good idea not to touch it at all
<sima>
*the lock holding time for page flips should be really quick
<sima>
the actual flipping can take a while, but shouldn't matter
<jfalempe>
sima, hum I need to check, but for the mgag200 driver, we memcpy the framebuffer to video memory, and I think the lock is taken during this time.
<sima>
jfalempe, another thing to ponder is how long we want to hold the locks
<sima>
jfalempe, could even avoid that with rcu, but I think that's a bridge too far and really tricky and will complicated the normal kms code a lot
<bl4ckb0ne>
also going to need xtl it seems
<jfalempe>
sima, yes, we don't need to go that far, also I prefer to have a minimum working version, and then improve on that. Otherwise it will never get merged.
hansg has quit [Quit: Leaving]
<sima>
jfalempe, definitely
any1 has joined #dri-devel
<sima>
jfalempe, wrt minimal version I think the absolutely required stuff imo is only a) kerneldoc polish and linking into rst in the few places I've mentioned b) moving the ->get_scanout_buffer to drm_mode_config_funcs c) the plane trylock stuff for the drivers that need it with the current design (i.e. not simpledrm) and I guess d) moving to kmsg_dumper since I think that's the right one ...
<jfalempe>
sima, ok I will try to do that for the next version. I may ping you if I need help for those at some point.
<sima>
jfalempe, I'm also checking right now with printk folks whether kmsg_dumper really is the future to build on, or whether there's going to be changes there with the printk/console/panic locking redesign
<sima>
so maybe wait with that until we have confirmation
kts has joined #dri-devel
<jfalempe>
sima, ok, thanks
fab has quit [Quit: fab]
mszyprow has quit [Ping timeout: 480 seconds]
<bl4ckb0ne>
tomeu: a preference between tbb and openmp for xtensor ?
<tomeu>
bl4ckb0ne: not really, I just used debian's version and don't even know what those are
<bl4ckb0ne>
ill take a look
<bl4ckb0ne>
the aur package has nothing enabled
<sima>
jfalempe, hm I just looked at mutex_trylock and that might not be panic handler safe enough
<bl4ckb0ne>
ill go with just xsimd for now
<sima>
jfalempe, so maybe for future-proofing the iterator should directly give you the plane state, so that it'll be easier to change the locking and maybe do the spinlock trick?
<sima>
jfalempe, hm yeah we can't use mutex_trylock and friends, so also can't drm_modeset_trylock
<bl4ckb0ne>
well, no xsimd
<bl4ckb0ne>
packaged version is 12. something, xtensor need 10.0
<jfalempe>
sima, for most driver, plane->state is enough, but for ast, I need the plane to get VRAM address.
<jfalempe>
but that's probably the exception, so it may use it's own plane iterator.
<sima>
jfalempe, but ast_plane->vaddr never changes, right? so no locking issues there?
<sima>
also to_ast_plane(plane_state->plane) should work
<sima>
jfalempe, what I more mean is that it looks like we'll need the raw spinlock for plane->state right away :-/
<tomeu>
bl4ckb0ne: that's awesome, thanks a lot!
<sima>
you cannot call *mutex_trylock in interrupt context, much less nmi
<sima>
and it needs to be a raw spinlock otherwise it goes boom on realtime kernels (since normal spinlocks are just mutexes there)
Leopold_ has quit [Remote host closed the connection]
<HdkR>
Spinlocks you say? May I interest you in...efficient spinlocks using waitpkg/monitox/wfe extensions? :)
<jfalempe>
sima, yes plane->vaddr shouldn't change, so no problem there. for the different locking API, I didn't look into it yet, but I would assume the mutex_trylock() would be good. We'll need to be careful there.
<sima>
jfalempe, mutex_trylock is no good, it's not even allowed in interrupt context
<sima>
so definitely not enough for panic :-(
<sima>
I only just now realized this ...
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
macslayer has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
mbrost has joined #dri-devel
<sima>
jfalempe, ok first answer I have, kmsg_dumper is the right thing
simondnnsn has quit [Ping timeout: 480 seconds]
djbw has quit [Read error: Connection reset by peer]
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
Duke`` has joined #dri-devel
simondnnsn has joined #dri-devel
oneforall2 has quit [Remote host closed the connection]
simondnnsn has quit [Read error: Connection reset by peer]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
kts has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
lynxeye has quit [Quit: Leaving.]
mszyprow has joined #dri-devel
djbw has joined #dri-devel
Leopold_ has joined #dri-devel
CazzMatazz has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
<sima>
jfalempe, for the igt I guess you want to open the drm kms node and allocate some framebuffer of your own before triggering the panic drawing
<sima>
so that the corruption doesn't spread to fbcon or whatever is currently running :-)
<sima>
jfalempe, also it sounds like from chatting with john ogness that we need raw_spin_trylock
mbrost has quit [Remote host closed the connection]
<sima>
I'll try to type up a patch next week with the locking code (just a few lines) and the designs and driver rules documented in kerneldoc (probably a few pages)
mbrost has joined #dri-devel
<sima>
to get feedback from rt/printk people
bmodem has quit [Ping timeout: 480 seconds]
<CazzMatazz>
hello
<jfalempe>
sima, ok thanks, that sounds good.
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
<bl4ckb0ne>
tomeu: merged in aports, should be available in edge in a few minutes
vyivel has quit [Read error: Connection reset by peer]
simon-perretta-img has quit [Ping timeout: 480 seconds]
simon-perretta-img has joined #dri-devel
qyliss has quit [Quit: bye]
vyivel has joined #dri-devel
qyliss has joined #dri-devel
mripard has quit [Quit: mripard]
mbrost has quit [Ping timeout: 480 seconds]
<daniels>
bl4ckb0ne: slick’
<bl4ckb0ne>
B)
<bl4ckb0ne>
ill keep an eye on the release to actually enable xsimd at some point
frankbinns has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
jsa1 has quit []
jewins has joined #dri-devel
rasterman- has joined #dri-devel
rasterman has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
Haaninjo has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Mangix has quit [Read error: No route to host]
Mangix has joined #dri-devel
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
simon-perretta-img has quit [Ping timeout: 480 seconds]
mszyprow has joined #dri-devel
Leopold_ has joined #dri-devel
simon-perretta-img has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Mangix has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Leopold_ has quit [Remote host closed the connection]
Leopold has joined #dri-devel
mbrost has joined #dri-devel
djbw_ has joined #dri-devel
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
djbw has quit [Ping timeout: 480 seconds]
simondnnsn has joined #dri-devel
simondnnsn has quit [Read error: Connection reset by peer]
Leopold has quit [Remote host closed the connection]
Mangix has joined #dri-devel
Leopold_ has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<jenatali>
Anybody able to recommend a reviewer for !27023?
Leopold_ has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
<zmike>
jenatali: I got you
<zmike>
if you want to add a piglit test too, that would be great
<jenatali>
Yeah, that would be a good idea
<jenatali>
What category would I put that in?
<zmike>
uhhhhhhhhhhh
<zmike>
that sounds suspiciously close to naming
<jenatali>
Heh
tursulin has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
Casper has joined #dri-devel
CazzMatazz is now known as Guest13887
Casper is now known as CazzMatazz
<CazzMatazz>
Is it possible to get opencl working on a Navi14 card in Ubuntu 22.04 LTS?
<karolherbst>
probs not
<karolherbst>
also, wrong place to ask
<CazzMatazz>
Where would I ask?
<karolherbst>
ubuntu folks
<karolherbst>
there are probably ppa where you get still upstream supported mesas
<karolherbst>
but ubuntu shops eol mesa, so it's up to them to deal with all of that
<CazzMatazz>
Well I have the mesa package from both Ubuntu, PPAs, and the AMD drivers
<CazzMatazz>
but it's missing one file
Guest13887 has quit [Ping timeout: 480 seconds]
<karolherbst>
yeah.. so it's a ubuntu bug?
<CazzMatazz>
clinfo shows that I'm missing 'gfx1012-amdgcn-mesa-mesa3d.bc'
<CazzMatazz>
Well, I guess you could say it's an Ubuntu repo bug
<karolherbst>
probs need libclc installed
<CazzMatazz>
Yes, I can install it, BUT it breaks other things in OpenCL
heat_ has joined #dri-devel
<karolherbst>
what CL driver are you using here anyway?
<CazzMatazz>
If I try to install libclc-amdgcn, I have to remove libclc-dev in favor of libclc-15-dev. I don't know what to make of this
<karolherbst>
but anyway, can't help with missing files or installing packages breaking things
<karolherbst>
really want to either file bugs against ubuntu or the ppa you are using
heat has quit [Read error: No route to host]
<CazzMatazz>
The mesa package I have is mesa-opencl-icd
<CazzMatazz>
And ok, I'm just trying to wrap my head around all this
<CazzMatazz>
I tried using Rusticl but I think it's crashing because it's in early development
<karolherbst>
well.. what version of mesa do you have installed anyway?
<CazzMatazz>
So I tried a bleeding edge ppa for Ubuntu - oibaf. But apparently Rusticl isn't available for Ubuntu 22.04 anymore? As of very recently
<CazzMatazz>
mesa 23.3.3
<karolherbst>
could be due to rust packaging or something...
<karolherbst>
but yeah.. for rusticl to work on AMD you kinda wnat 23.3 or newer
<karolherbst>
and stock ubuntu 22.04 is 23.0
<CazzMatazz>
What if I used rustup to upgrade to Rust's nightly build?
<CazzMatazz>
or does that not matter
<karolherbst>
won't have to go so far, but yeah, if you build it yourself you should be able to use it
<karolherbst>
but probably easier to just not use ubuntu LTS
rasterman- has quit []
<CazzMatazz>
It's my first Linux distro, but I have been using it for a while now. I just figured it'd be stable
<karolherbst>
yeah, but stable generally means "old software"
<CazzMatazz>
and by 'build it myself' you mean mesa? I tried but it looks kinda hard with missing libraries
<karolherbst>
yeah...
<karolherbst>
that's where the "don't use ubuntu LTS" part comes into play
<karolherbst>
sadly I can't check what mesa version ubuntu 23.04 is on because the package website keeps throwing 503s or not replying at all, soo...
<karolherbst>
ehh 23.10 I mean
<CazzMatazz>
I do like Debian, but maybe it's time for me to move on. Arch has an opencl-amd package in the AUR that's supposed to work nicely with my hardware
ngcortes has joined #dri-devel
<karolherbst>
I mean.. moving away from LTS and just do the upgrade every half a year would already help here
<karolherbst>
mhhh
<karolherbst>
seems like 23.10 is on mesa 23.2...
<karolherbst>
still a bit too old
<CazzMatazz>
yeah, I think Rusticl requires 24.04
<karolherbst>
yeah.. something like that
<karolherbst>
if you don't want to move to arch, there is always fedora which updates stuff a bit more aggressively
<CazzMatazz>
I mean I have a rusticl instance right now, but I don't know if it's stable. If I try to run benchmarking with hashcat it works for some hash types then crashes after a while
<karolherbst>
yeah.. that's a bug which I still need to look into..
<CazzMatazz>
and clover is pretty much a thing of the past now?
<karolherbst>
pretty much
<karolherbst>
though it's still has a few advantages, just I don't know if hashcat works any better there
<karolherbst>
if it does, I should really fix those issues...
<CazzMatazz>
clover is the platform thats broken for me because of the missing amdgcn
<karolherbst>
ahh, right
<CazzMatazz>
so it should work in theory, im pretty sure it works otherwise
<CazzMatazz>
i also have one called AMD APP, i think that's AMD's proprietary platform? its not even picked up by hashcat
<karolherbst>
yeah... I think that's for older GPUs
<karolherbst>
it's confusing..
<karolherbst>
maybe it runs on your GPU, dunno
Leopold_ has quit [Remote host closed the connection]
<CazzMatazz>
i have the rx 5500 which is from 2019. i dont mind how old it is, i just wanted to try and run certain software like hashcat and DaVinci Resolve
<karolherbst>
right...
<CazzMatazz>
it has been a lot to wrap my head around but im glad i learned in the process, at least
<karolherbst>
I've tested davinci resolve on my navi22 and it should run, though users reported that some effects make it crash
<karolherbst>
but I'm looking into it
<karolherbst>
but it does run and plays RAW video files just fine, and editing also seems to work with the effects I was trying, so not sure if it only crashes on older gpus or something...
<CazzMatazz>
do you use rusticl or clover with it?
<karolherbst>
rusticl
<karolherbst>
I'm sure clover wouldn't be able to run it at all
<karolherbst>
due to missing features and all that
<CazzMatazz>
well thats cool, i tried installing davinci a long time ago and no matter what i did no video would show up, even though i didnt get the usual error message
<CazzMatazz>
i was so confused
<karolherbst>
yeah...
<karolherbst>
that happens if the CL driver is broken, but not broken enough to make it crash outright
<CazzMatazz>
i havent tried davinci since i "discovered" rusticl - adding the variable to my bashrc. i may have to try it again
<karolherbst>
though I also had this happening while the runtime deadlocked...
<karolherbst>
you'll need mesa-24.0 for it to run proberly
<karolherbst>
mhh maybe the fixes got backported to 23.3 though...
fab has quit [Quit: fab]
<CazzMatazz>
i think i read something like that on the gitlab issues page that said it "should" work in 23.3
<karolherbst>
you kinda need that libclc stuff installed for it to work on clover
<karolherbst>
CazzMatazz: the thing is that rocm doesn't really refuse to work on those GPUs, but it's also not "supported"
<karolherbst>
so if it works: great, if not? well.. tough
<CazzMatazz>
well the thing i dont understand is i have libclc-15, but then i cant install libclc... i wonder what version the ubuntu "libclc" is
<karolherbst>
AMD kinda doesn't get it, so it is what it is. Though they do seem to become better now, but uhhh
<karolherbst>
well
<karolherbst>
whatever
<CazzMatazz>
i think the libclc-amdgcn package wants a much older version of libclc
<karolherbst>
prolly the newest llvm version when 22.04 was released or so
<karolherbst>
but anyway
<karolherbst>
should report a packaging bug against ubuntu there
<CazzMatazz>
i will try to find a way to do that. its kind of AMDs fault too though
<karolherbst>
yeah.. maybe
<karolherbst>
packaging can be hard :D
<CazzMatazz>
i used their amdgpu-install package to set up opencl. they advertise it on their website to be compatible with ubuntu 22.04
<karolherbst>
heh...
<CazzMatazz>
it definitely can be with conflicting libraries
<CazzMatazz>
i dont fault them... well maybe just a little
<karolherbst>
I wouldn't trust install scripts tbh, they always do weird stuff
<karolherbst>
ohh wait
<karolherbst>
it's adding a ppa?
<karolherbst>
oh well
<CazzMatazz>
i think they add some repositories
<CazzMatazz>
no its not a ppa
<CazzMatazz>
it really just runs commands for you
<karolherbst>
I see
<karolherbst>
yeah.. anyway, can't help with that 🙃
<CazzMatazz>
the 2 main ppas for mesa on ubuntu are kisak and oibaf
<CazzMatazz>
i think they just compile and package mesa for people that dont want ubuntus ancient packages
<jenatali>
zmike: Was getting ready to write a test, but decided to do some spec lawyering, and I can't find any place where it says that two images with the same internal format and different type *must* produce different "effective internal formats" (i.e. breaking mip completeness)
<zmike>
🤔
vyivel has quit [Read error: Connection reset by peer]
<zmike>
I guess technically there's no requirement for it?
<jenatali>
Yeah, I could write something that'd catch the bug in my driver, or maybe even Mesa all-up, but not sure I can write something that's valid on all drivers
<jenatali>
Nothing stopping a driver from taking 16-bit unorm data and storing it as 8-bit unorm if all you asked for is generic RGBA
<zmike>
so you're suggesting this may be a case of undefined behavior between different drivers
<jenatali>
Yeah
<jenatali>
The bug I hit was that we were uploading mip data for a mip-incomplete texture in a broken way, but it didn't actually matter that it was mip complete or incomplete
<jenatali>
I just needed us to be consistent and not try to upload data in the wrong format
<zmike>
it's unlikely any spec change would happen if this got raised to the wg
<zmike>
so potentially this might be a
<zmike>
and you know how much I don't want to say this
<zmike>
but it might be a case where your driver needs a pipe cap
<jenatali>
Nah, the spec says that the driver can figure out the effective internal format however they want, and that the effective internal format is the thing that determines compatibility
<jenatali>
I don't see a spec problem... I just don't see a good way to write a test to force different effective internal formats
<jenatali>
Since, like I said, they can figure it out however they want
<zmike>
ah okay I misinterpreted
<zmike>
well
<zmike>
hm
<zmike>
how about an apitrace from the app?
mbrost has joined #dri-devel
<zmike>
could see about DavidHeidelberg adding that to ci if we can establish consistent behavior
vyivel has joined #dri-devel
<jenatali>
The consistent behavior is "don't blow up." The app has a mipped texture, then redefines it to not-mipped with the same internalFormat but a different type, which (at least for our driver) chooses a different effective internal format. The problem was Mesa still thought it was mip complete and tried to upload mismatched mip data
<jenatali>
Sampling would've worked fine, it's still base complete
simondnnsn has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
<zmike>
the more I hear about this problem the more I think I'm glad I don't deal with WGL apps
<jenatali>
Heh
<jenatali>
It's apparently some app written by some guy at Dell forever ago for testing GL behavior on Dell PCs
heat_ has quit [Remote host closed the connection]
heat has joined #dri-devel
a1batross has quit []
linkmauve has quit [Quit: Gateway shutdown]
ngcortes has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
Mangix has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
simondnnsn has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
soreau has quit [Remote host closed the connection]
soreau has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
soreau has quit [Read error: Connection reset by peer]