ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
tlwoerner_ has joined #dri-devel
tlwoerner has quit [Ping timeout: 480 seconds]
dakr has quit [Ping timeout: 480 seconds]
<karolherbst> airlied: :( now radeonsi/llvm fail to compile and looping somewhere forever
<karolherbst> any idea on how to figure out where it's stuck?
<airlied> karolherbst: stuck in llvm somewhere?
<karolherbst> yeah.. doing RA I think
<karolherbst> I think it's related to image ops though
<airlied> might get there eventually :)
<karolherbst> I do have a few timeouts in the CTS run and they are all image related
<karolherbst> it doesn't :(
<airlied> like 10-15 minutes :-P
<karolherbst> it still doesn;t :P
<karolherbst> also the kernel isn't that complicated
<karolherbst> I suspect something is wrong with the image_store
<karolherbst> airlied: I wouldn't be surprised if mixed writeonly and readonly images kind of upset something...
<karolherbst> might be easier to figure out what's wrong there
<karolherbst> and yeah.. writeonly and readonly kernel in one...
<karolherbst> but might be something else.. dunno
columbarius has joined #dri-devel
<karolherbst> guess I'll need to build llvm with debug symbols :(
co1umbarius has quit [Ping timeout: 480 seconds]
neoXite___ has joined #dri-devel
neoXite___ has quit []
neoXite has joined #dri-devel
illwieckz has quit [Quit: I'll be back!]
illwieckz has joined #dri-devel
<karolherbst> is there an easy way to add -debug to radeonsis llvm pipeline?
alyssa has joined #dri-devel
<alyssa> hmm, no way to turn "a = x * y. b = mad(x, y, z)." into "a = x * y. b = a + z." is there? :(
<alyssa> I guess CSE before fusing FMA...
<alyssa> maybe I just have my pass order wrong, I'd believe that
<alyssa> ~~getting pass ordering right is np-hard~~
<karolherbst> why is LLVM on every level a pita
<alyssa> karolherbst: inertia
<karolherbst> heck.. I just mess with llvm directly :)
<karolherbst> ahh it's doing nothing
<karolherbst> nice
<alyssa> oh I see what's happening
<alyssa> the original code is
<alyssa> "a = x * y. b = a + z. /* uses of both a and b b */"
<alyssa> opt_algebraic_late is greedily changing that to
<alyssa> "a = x * y. b = fma(x, y, z). /* uses of both a and b b */"
<alyssa> even though that's actually worse in this case, because now we have 2 multiplies instead of just 1
<karolherbst> alyssa: could do it if it's the only use
<alyssa> that hurts in other cases, like
<karolherbst> but...
<karolherbst> yeah
<alyssa> "a = x * y. b = a + z. c = a + t"
<alyssa> possibly what we want is to fuse if all uses are fadd or fsub
<karolherbst> or if we can actually optimize all uses away
<alyssa> that's what I said
<karolherbst> sorry, llvm drained my brain, and I can't think :)
<alyssa> Will that help or hurt? who knows!
<alyssa> will it compile? TBD!
<karolherbst> jooooo make sure Jason doesn't see it, otherwise it will never land :P
<alyssa> helps this one shader, will it help the whole shaderdb? who knows
<alyssa> karolherbst: what do you mean? :-(
<karolherbst> you are touching nir_search!
<alyssa> not really
<karolherbst> true...
<karolherbst> let's think of a way of doing this, but also touching nir_search!
<alyssa> karolherbst: you do know if jekstrand would NAK a patch, there's a great chance I would too? :-p
<karolherbst> I don't
<karolherbst> and I don't plan of knowing this
<karolherbst> uhm.. to know this?
<alyssa> (...also the req_local_mem patch is nak'd until freedreno is sorted out?)
<karolherbst> uhm...
<karolherbst> though I actually do have to figure out what to do with freedreno...
Leopold has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<karolherbst> I suspect the code can't really deal wiht the void images :)
pribas has joined #dri-devel
pribas_ has quit [Ping timeout: 480 seconds]
<airlied> karolherbst: finally fixed the coroutine thing
<karolherbst> \o/
<airlied> 18815 for the fix
<karolherbst> cool. I'll give it a run tomorrow
ella-0 has joined #dri-devel
<karolherbst> ahh.. what is LLVM just doing :(
<karolherbst> I honestly have no idea what's wrong
<karolherbst> but apparently it tries to replace undefs with 0s, but while doing so it inserts new undefs
<karolherbst> it makes no sense
ella-0_ has quit [Read error: Connection reset by peer]
<karolherbst> but it also happens in kernels not using images at all...
<a-865> can someone here suggest where to go to solve a problem with r600 dri? [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
Mangix has joined #dri-devel
<karolherbst> wait a minute....
<karolherbst> why is my ubo a vec4... that's not right...
<karolherbst> though that's not fixing my issue either
pallavim has joined #dri-devel
<karolherbst> frigging god, I found it...
<karolherbst> something odd with get_global_size
<airlied> okay I think llvm15/16 are back working again
<airlied> just need 18816 as well
* airlied ponders opaque pointers void
<karolherbst> why does this llvm bug make no sense...
<karolherbst> ohh...
<alyssa> it's an llvm bug
<karolherbst> the heck...
<karolherbst> I found it. but wtf...
<karolherbst> or not?
<karolherbst> dunno
<karolherbst> what does the type of icmp specify? the source thingies?
<karolherbst> because I have an icmp eq i32 comparing two 64 bit values
<karolherbst> ehh wait.. actually not
<karolherbst> and the difference doesn't seem to be that severe that it should mess things up?
<karolherbst> but it might also be caused by changes in future LLVM passes
<alyssa> have you considered not using llvm
<karolherbst> yeah.. maybe I should just embrace aco instead, but I have no idea if that's more or less work
<karolherbst> I mean... it essentially works what I have
<karolherbst> it makes no sense
<karolherbst> yo wtf
<karolherbst> casting the result of get_global_size to uint makes it compile
<karolherbst> I am so sure it's something super stupid somewhere deep inside LLVM
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<karolherbst> yeah.. it makes no sense
<karolherbst> airlied: soo.. what would I have to do to use ACO? I refuse to fix LLVM bugs :D
bmodem has joined #dri-devel
<airlied> karolherbst: write a lot of code :-)
<karolherbst> uhhh... :/
<karolherbst> still don't get why casting the workgrou_size thing to 64 bit makes LLVM fall apart
Leopold_ has quit [Remote host closed the connection]
Company has quit [Read error: Connection reset by peer]
Surkow|laptop has quit [Ping timeout: 480 seconds]
Surkow|laptop has joined #dri-devel
aravind has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
pcercuei has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
lemonzest has joined #dri-devel
Duke`` has joined #dri-devel
itoral has joined #dri-devel
tzimmermann has joined #dri-devel
itoral_ has joined #dri-devel
fab has joined #dri-devel
itoral has quit [Ping timeout: 480 seconds]
Surkow|laptop has quit [Ping timeout: 480 seconds]
pallavim has quit [Read error: Connection reset by peer]
pallavim has joined #dri-devel
SexgirLLL has joined #dri-devel
SexgirLLL has quit []
Surkow|laptop has joined #dri-devel
mhenning has quit [Quit: mhenning]
<airlied> woo opaque ptrs gears
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
garrison has quit []
i-garrison has joined #dri-devel
ahajda has joined #dri-devel
cef has quit [Remote host closed the connection]
cef has joined #dri-devel
pallavim has quit [Remote host closed the connection]
pallavim has joined #dri-devel
pallavim has quit [Read error: Connection reset by peer]
Ristovski has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
danvet has joined #dri-devel
Ristovski has joined #dri-devel
pochu has joined #dri-devel
mvlad has joined #dri-devel
fab has joined #dri-devel
<dj-death> anybody able to help with the top commit of this MR? : https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18788
<dj-death> when bumping llvm from 11 to 13 on the debian-vulkan builder, I'm getting runtime errors due to the alignment sanitizer :
<dj-death> ../src/util/ralloc.c:873:7: runtime error: member access within misaligned address 0x55c0ee710b48 for type 'struct gc_slab', which requires 16 byte alignment
<dj-death> I managed to reproduce locally
<dj-death> and errors are due to the pointer arithmetic with empty lists
<dj-death> normally the elements are aligned correctly, but with an empty list, this kind of stuff is causing problems : https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/list.h#L237
<dj-death> turning off -fno-sanitize-recover=all is the only reasonable thing I'm able to come up with
<tzimmermann> is anyone interested in trading reviews? i'd need reviews of https://lore.kernel.org/dri-devel/20220919130408.21486-1-tzimmermann@suse.de/
tursulin has joined #dri-devel
<pq> danvet, emersion, robclark, re: plane uniform color; make sure you leave the UAPI open to add a floating-point format in the future. The Wayland protocol does, too.
MajorBiscuit has joined #dri-devel
<pq> danvet, emersion, robclark, not because of more precision, but because of being able to express negative and greater than 1.0 values.
<pq> danvet, I'm also sceptical that "black is all anyone ever needs" for CRTC background color is actually true. I can easily imagine a use case where it is not true (emitting a limited quant.range video but needing control over the full value range, IOW black > 0), but I cannot promise it will actually have use.
lynxeye has joined #dri-devel
<pq> that use case would of course have other problems with the current set of properties, too, they don't allow full-range control while emitting limited range metadata.
<pq> AFAIU
swalker_ has joined #dri-devel
swalker_ is now known as Guest1390
swalker__ has joined #dri-devel
Guest1390 has quit [Remote host closed the connection]
Duke`` has quit []
Duke`` has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
jfalempe has joined #dri-devel
Surkow|laptop has joined #dri-devel
<dj-death> heh what the hell
<dj-death> I'm looking at why we're getting a crash in nir_lower_doubles() in Anv
<dj-death> and we've never passed the softfp64 shader
<dj-death> how does anything ever worked?
Duke`` has quit [Ping timeout: 480 seconds]
<mslusarz> alyssa: thanks for the review of metadata MR, I'll try to rebase it soon
pallavim has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest1393
swalker__ has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
rgallaispou1 is now known as rgallaispou
gouchi has joined #dri-devel
gouchi has quit []
DemiMarie has quit [Quit: Bridge terminating on SIGTERM]
dafna33[m] has quit []
MatrixTravelerbot[m]1 has quit []
mairacanal[m] has quit []
colemickens has quit [Quit: Bridge terminating on SIGTERM]
LaughingMan[m] has quit []
cleverca22[m] has quit []
tintou has quit []
DrNick has quit []
dcbaker has quit [Quit: Bridge terminating on SIGTERM]
frytaped[m] has quit []
bluepenquin has quit [Quit: Bridge terminating on SIGTERM]
arisu has quit []
mripard has quit []
underpantsgnome[m] has quit []
heftig has quit [Quit: Bridge terminating on SIGTERM]
kusma has quit [Quit: Bridge terminating on SIGTERM]
cmeissl[m] has quit []
michael5050[m] has quit []
DavidHeidelberg[m] has quit [Quit: Bridge terminating on SIGTERM]
tomba has quit [Quit: Bridge terminating on SIGTERM]
ramacassis[m] has quit []
martijnbraam has quit [Quit: Bridge terminating on SIGTERM]
ralf1307[theythem][m] has quit []
Tooniis[m] has quit []
viciouss[m] has quit []
x512[m] has quit []
hasebastian[m] has quit []
Dylanger has quit [Quit: Bridge terminating on SIGTERM]
Soroush has quit []
robertfoss[m] has quit []
Mis012[m] has quit []
nielsdg has quit []
unrelentingtech has quit []
Anson[m] has quit []
doras has quit []
ambasta[m] has quit []
sjfricke[m] has quit []
egalli has quit []
GeorgesStavracasfeaneron[m] has quit []
gagallo7[m] has quit []
gdevi has quit []
gnustomp[m] has quit []
ella-0[m] has quit []
cwfitzgerald[m] has quit []
YaLTeR[m] has quit []
znullptr[m] has quit []
Andy[m] has quit []
zzoon[m] has quit []
Mershl[m] has quit []
naheemsays[m] has quit []
Ella[m] has quit []
jekstrand[m] has quit []
kunal_10185[m] has quit []
JosExpsito[m] has quit []
moben[m] has quit []
jenatali has quit [Quit: Bridge terminating on SIGTERM]
onox[m] has quit []
jasuarez has quit []
kunal_1072002[m] has quit []
Vin[m] has quit []
T_UNIX has quit []
Strit[m] has quit []
xerpi[m] has quit []
pac85[m] has quit []
pushqrdx[m] has quit []
robertmader[m] has quit []
Sumera[m] has quit []
tleydxdy has quit [Quit: Bridge terminating on SIGTERM]
reactormonk[m] has quit []
RAOF has quit [Quit: Bridge terminating on SIGTERM]
chema has quit []
bylaws has quit []
neobrain[m] has quit []
kallisti5[m] has quit []
danylo has quit []
KunalAgarwal[m] has quit [Quit: Bridge terminating on SIGTERM]
PiGLDN[m] has quit []
frytaped has quit [Quit: Bridge terminating on SIGTERM]
Newbyte has quit []
r[m] has quit []
eyearesee has quit []
halfline[m] has quit []
kunal10710[m] has quit []
masush5[m] has quit []
AlexisHernndezGuzmn[m] has quit []
pmoreau has quit [Quit: Bridge terminating on SIGTERM]
nyorain[m] has quit []
knr has quit []
yshui` has quit []
sigmoidfunc[m] has quit []
undvasistas[m] has quit []
zamundaaa[m] has quit [Quit: Bridge terminating on SIGTERM]
Weiss-Fder[m] has quit []
hch12907 has quit [Quit: Bridge terminating on SIGTERM]
neoXite has quit []
devilhorns has joined #dri-devel
chaim has joined #dri-devel
maxzor has joined #dri-devel
fahien has joined #dri-devel
<lina> Quick question: Is drm_mm suitable for doing small object allocation? I already use it for page-granularity VMA allocations, but I'm thinking of building a fine-grained GPU object allocator on top of it.
<lina> Basically, I need something closer to SLUB but for GPU arenas, but it doesn't have to be that fancy.
<lina> Right now I have a very dumb allocator that just allocates/frees a whole page-aligned GEM object for every little alloc/dealloc, which is nice for debugging but terrible for performance, since a bunch of those allocs/deallocs happen for every submission.
<lina> So my idea was to reuse the same drm_mm machinery on another layer on top, carve out chunks of GPU address space for specific allocators (for memory with specific properties, there are a few types), and just have a drm_mm on top allocating/freeing objects. Then every time I alloc I keep a high watermark of the highest allocated address, and add backing pages (e.g. in 1MB chunks, using GEM objects behind
<lina> the scenes) as needed.
<lina> It's probably fine to never free backing pages, since these are all small structures linear in the number of GPU queues/users/renders currently in existence, not big buffers or anything like that. And that also neatly sidesteps a coprocessor TLB invalidation problem I'm having right now, since mappings would never change after coming into existence...
arisu has joined #dri-devel
vliaskov has joined #dri-devel
<airlied> lina: not sure we have had anything that cared or needed sub page gpu allocations
<lina> In this case it's specifically for the coprocessor structures (which vary from a few bytes to several dozen kilobytes in size).
<lina> macOS seems to do it using arenas for specific object types, or sometimes a few related ones (I can tell since I see its allocation patterns when tracing), but I think it's fine to just have a few global allocators that only care about the memory type (caching mode/readonly/etc) and just hard-code the VMA ranges for each ahead of time.
<lina> I imagine there's no reason drm_mm wouldn't work, other than possibly performance?
<airlied> yeah probably fine for a first pass
<lina> I'll go with that then, since I already have it abstracted and it will probably be a big performance win just by not thrashing the page table.
neoXite has joined #dri-devel
kusma has joined #dri-devel
<kusma> Seems like the docs build on ci is broken :( https://gitlab.freedesktop.org/mesa/mesa/-/jobs/29013012#L180
pcercuei has joined #dri-devel
Company has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts has quit []
itoral_ has quit []
ambasta[m] has joined #dri-devel
Andy[m] has joined #dri-devel
bluepenquin[m] has joined #dri-devel
bylaws has joined #dri-devel
chema has joined #dri-devel
RAOF has joined #dri-devel
cleverca22[m] has joined #dri-devel
cmeissl[m] has joined #dri-devel
colemickens has joined #dri-devel
cwfitzgerald[m] has joined #dri-devel
dafna33[m] has joined #dri-devel
dcbaker has joined #dri-devel
DemiMarieObenour[m] has joined #dri-devel
Anson[m] has joined #dri-devel
Guest1407 has joined #dri-devel
doras has joined #dri-devel
danylo has joined #dri-devel
Dylanger has joined #dri-devel
egalli has joined #dri-devel
ella-0[m] has joined #dri-devel
Ella[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has joined #dri-devel
GeorgesStavracasfeaneron[m] has joined #dri-devel
frytaped[m] has joined #dri-devel
gagallo7[m] has joined #dri-devel
gdevi has joined #dri-devel
gnustomp[m] has joined #dri-devel
Guest1417 has joined #dri-devel
halfline[m] has joined #dri-devel
hasebastian[m] has joined #dri-devel
hch12907 has joined #dri-devel
heftig has joined #dri-devel
zzoon[m] has joined #dri-devel
jasuarez has joined #dri-devel
jekstrand[m] has joined #dri-devel
jenatali has joined #dri-devel
JosExpsito[m] has joined #dri-devel
kallisti5[m] has joined #dri-devel
kunal10710[m] has joined #dri-devel
kunal_10185[m] has joined #dri-devel
kunal_1072002[m] has joined #dri-devel
KunalAgarwal[m][m] has joined #dri-devel
LaughingMan[m] has joined #dri-devel
mairacanal[m] has joined #dri-devel
martijnbraam has joined #dri-devel
masush5[m] has joined #dri-devel
Mershl[m] has joined #dri-devel
michael5050[m] has joined #dri-devel
Mis012[m] has joined #dri-devel
moben[m] has joined #dri-devel
mripard has joined #dri-devel
Vin[m] has joined #dri-devel
naheemsays[m] has joined #dri-devel
neobrain[m] has joined #dri-devel
Newbyte has joined #dri-devel
eyearesee has joined #dri-devel
nielsdg has joined #dri-devel
nyorain[m] has joined #dri-devel
DavidHeidelberg[m] has joined #dri-devel
onox[m] has joined #dri-devel
pac85[m] has joined #dri-devel
PiGLDN[m] has joined #dri-devel
pmoreau has joined #dri-devel
pushqrdx[m] has joined #dri-devel
r[m] has joined #dri-devel
ralf1307[theythem][m] has joined #dri-devel
ramacassis[m] has joined #dri-devel
reactormonk[m] has joined #dri-devel
robertmader[m] has joined #dri-devel
robertfoss[m] has joined #dri-devel
sigmoidfunc[m] has joined #dri-devel
sjfricke[m] has joined #dri-devel
Strit[m] has joined #dri-devel
Sumera[m] has joined #dri-devel
knr has joined #dri-devel
T_UNIX has joined #dri-devel
tintou has joined #dri-devel
underpantsgnome[m] has joined #dri-devel
tleydxdy has joined #dri-devel
tomba has joined #dri-devel
Tooniis[m] has joined #dri-devel
undvasistas[m] has joined #dri-devel
Soroush has joined #dri-devel
unrelentingtech has joined #dri-devel
viciouss[m] has joined #dri-devel
MatrixTravelerbot[m]1 has joined #dri-devel
Weiss-Fder[m] has joined #dri-devel
x512[m] has joined #dri-devel
xerpi[m] has joined #dri-devel
YaLTeR[m] has joined #dri-devel
yshui` has joined #dri-devel
zamundaaa[m] has joined #dri-devel
znullptr[m] has joined #dri-devel
pmoreau is now known as Guest1427
rgallaispou has left #dri-devel [#dri-devel]
chipxxx has joined #dri-devel
rgallaispou has joined #dri-devel
rgallaispou has quit []
fahien has joined #dri-devel
pochu has quit [Quit: leaving]
rgallaispou has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
pochu has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
soreau has quit [Read error: Connection reset by peer]
<alyssa> mslusarz: awesome
soreau has joined #dri-devel
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
bluepenquin[m] is now known as bluepenquin
<jekstrand> alyssa, karolherbst, airlied: What patch am I naking?
<karolherbst> jekstrand: I was just joking about alyssa touching nir_search :P
<karolherbst> also.. anybody interested in reviewing rusticl related patches? Just wondering if there are some interested enough in digging into Rust and getting more into it.
<alyssa> jekstrand: the ffma one
JohnnyonFlame has joined #dri-devel
dakr has joined #dri-devel
off^ has quit [Ping timeout: 480 seconds]
<alyssa> jekstrand: What's actually intel specific about the brw ffma pass?
<jekstrand> alyssa: The heuristics are based on what various Intel HW can do when it comes to immediates in instructions.
<alyssa> Oh, I see
<karolherbst> alyssa: what did shader-db tell you btw?
<alyssa> karolherbst: for ffma?
<alyssa> small win
<karolherbst> \o/
devilhorns has quit []
<karolherbst> alyssa: do you also see a slight reduction in GPR usage?
<karolherbst> wouldn't be surprised if you do
<alyssa> yes
<karolherbst> it's probably the best we can do before things get too complicated
srslypascal has quit [Remote host closed the connection]
zehortigoza has quit [Remote host closed the connection]
xroumegue has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
sdutt has joined #dri-devel
heat has joined #dri-devel
<ajax> karolherbst: feel free to tag me for rust patches, seems like a good way to get more fluent in it (i'm not very, to my shame)
fxkamd has joined #dri-devel
xroumegue has joined #dri-devel
<karolherbst> ajax: or subscribe to the rusticl/rust labels :) but yeah, I can also tag you after a while
garrison has joined #dri-devel
i-garrison has quit [Read error: Connection reset by peer]
Haaninjo has joined #dri-devel
<ajax> indeed
<lygstate> ajax: Can you take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18749 that's fixed macos github ci
<karolherbst> ajax: good starters are probably !18806 !18809 and !18810
<ajax> lygstate: sure. is there anything special i need to do to make github ci run (when i push to my github mirror)?
<lygstate> Have a look at actions
<ajax> ack, thanks
<ajax> i've been hating the appleglx ifdef crap for a few years now but in no way do i have the patience to get mesa building on a mac of my own
<lygstate> I didn't have either, I getting it fixed by using github actions
fxkamd has quit []
pallavim has quit [Remote host closed the connection]
pallavim has joined #dri-devel
<MrCooper> lygstate: hooking it up to the GitLab CI would be better, otherwise it'll keep breaking
fab has quit [Quit: fab]
macromorgan is now known as Guest1468
Guest1468 has quit [Ping timeout: 480 seconds]
macromorgan has joined #dri-devel
<alyssa> ajax: relatable
<alyssa> MrCooper: i'm okay with this outcome
<MrCooper> so am I :) but if I cared about the macos build, I wouldn't be
idr has joined #dri-devel
<lygstate> MrCooper: yeap, just don't know how to hook it up to GitLab CI
<MrCooper> lygstate: gstreamer's cerebro repo serves as an example; eric_engestrom was looking into it I think
lygstate has quit [Read error: Connection reset by peer]
lygstate has joined #dri-devel
<lygstate> MrCooper: Can you give me the URL, I'll have a look if I have the time
<DavidHeidelberg[m]> * lygstate: generally, we could have a gitLAB CI job, which would check, if gitHUB CI job finished successfully? And for Marge-bot runs, just take MR.patch and apply it, test and gitLAB job would fetch result?
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
Leopold_ has joined #dri-devel
iive has joined #dri-devel
Duke`` has joined #dri-devel
<MrCooper> DavidHeidelberg[m]: gstreamer has macos runners for GitLab, they seem okay with us using those
Leopold_ has quit [Remote host closed the connection]
ybogdano has joined #dri-devel
<macromorgan> for a panel backlight, if I try to set the backlight too high should I just set it to the max value instead or should I return -EINVAL?
<macromorgan> basically if the max is 15 and I try to set it to 16 for example, should I just set it to 15 or should I return -EINVAL?
Leopold_ has joined #dri-devel
fab has joined #dri-devel
slattann has quit [Quit: Leaving.]
<alyssa> MrCooper: I actively do not want Marge building for macOS.
<MrCooper> why not?
<alyssa> because then people will make changes that build fine for linux and bsd, but not for macos and marge will reject that
<alyssa> and that's pushing the responsibility to support a broken proprietary platform onto upstream devs
<alyssa> and i'm not okay with that
<MrCooper> yep, that's what Marge is for :)
<MrCooper> or rather the CI pipeline
<alyssa> I do not want Marge rejecting patches that are good for Linux and BSD
<emersion> i agree with alyssa
<alyssa> I realize we have Windows CI in there now. Not thrilled about that either but it's not my fight.
<MrCooper> others might feel similarly about the drivers you care about
<emersion> alyssa: unfortunately Windows is already there
<emersion> yea
<karolherbst> might be good enough to make it a warning
<karolherbst> and then one files a bug
<MrCooper> non-gating CI is a waste of effort
<MrCooper> will just get ignored
<emersion> yeah, as intended
<emersion> and then people who care about windows/macos need to fix it
gawin has joined #dri-devel
<ajax> windows is also not comparable because there is actual development _for that os_ happening
<ajax> it's not like a gl-to-d3d12 driver is much use on linux
<alyssa> ajax: yeah, that
sdutt has quit []
sdutt has joined #dri-devel
<ajax> apple goes three years between build fix commits
<karolherbst> MrCooper: that's exactly the point here
<alyssa> Microsoft pours enough upstream goodness into Mesa and pays jenatali to look after the build regardless of CI doing it
<alyssa> which means the windows CI is probably a small net positive for upstream
<ajax> and this is no shade on jeremy or anyone else at apple, really, they're fine people who do good work, but it's not something they're enhancing in any way
<alyssa> right, there are ttbomk exactly two uses for apple/mesa at this point: llvmpipe/glx and asahi/glx
<MrCooper> ajax: in fact, it's quite clearly intended to keep people from migrating to actual Linux; personally, I find that more questionable than building Mesa for macos
<ajax> alyssa: src/glx does have a native mode for X11.app
<alyssa> (And the latter is a stopgap that will only linger past 2023 as a "r/e and porting" aid)
<ajax> loads CGL and thunks through by calling some magic dylib that calls the right below-the-line api
<alyssa> oh. yes. that.
<alyssa> that, that is even more questionable to have upstream imho
<alyssa> (Does asahi/macos go through that path? I have no idea and shiver to find out.)
<MrCooper> karolherbst: why waste the effort then?
<alyssa> Point is, outside of those two use cases, it doesn't matter if mesa builds for macos
<ajax> i... doubt it? what does that display to? the glx hack there is literally only for X11.app client windows, you can't use it to draw directly to an NSWindow
<alyssa> ajax: displays to X11.app client windows :-p
<ajax> lol
<karolherbst> MrCooper: because we could have a bot auto filing issues or something.. or just a bot complaining on the MR saying: look macos build failed, press here to open the issue
<alyssa> I wired it in as a software rasterizer
<ajax> then no, that's the llvmpipe path not the cgl path
<alyssa> it's very fast software
<alyssa> apple cpu go brrgh
<DavidHeidelberg[m]> alyssa: what about OPTIONAL job which can check macOS on github, at least for people who cares about MacOS?
<ajax> and yeah, at this point i feel like exposing anyone to macos' opengl is impolite
<karolherbst> but if we don't think macos is a target to care about, we can also just drop the support for it
<ajax> if we're going to keep that as a target platform i'd rather see it be zink+moltenvk
<karolherbst> DavidHeidelberg[m]: you can make jobs fail with a warning non blocking MRs
<alyssa> (...And as the maintainer of the latter use case, I am saying that I care far more about the upstream project and the Linux devs and that I would far rather break it than have a single upstream linux or bsd dev spend a minute of their time dealing with this mess.)
<alyssa> as for the former... meh?
<DavidHeidelberg[m]> karolherbst: I was thinking exactly that
<alyssa> xquartz mesa works as well as it ever will, not sure it really makes a difference whether that's upstream
<alyssa> karolherbst: Nobody notices those.
<karolherbst> the thing is rather how we deal with it
<karolherbst> yeah.. that's why we need marge to comment
<alyssa> I don't want Marge bothering people with this.
<DavidHeidelberg[m]> alyssa: well, somebody will, but can fix later
<karolherbst> if there is a job with a warning, it will comment on the MR but still merge it
tzimmermann has quit [Quit: Leaving]
<ajax> at least for the src/glx case i'm happy to abuse github for ci for it
<DavidHeidelberg[m]> alyssa: then we should drop also M$ builds......
<alyssa> DavidHeidelberg[m]: I already addressed that.
<karolherbst> or marge just opens an issue the first time this happens, and as long as there are open issues with a certain label marge won't open new ones or something
<MrCooper> DavidHeidelberg[m]: a job which doesn't cause the pipeline to fail will just get ignored, so won't be any benefit to those who care about the macos build (they already know when it's broken)
<alyssa> (cl-on-12 alone advanced NIR-based OpenCL by years)
bmodem has quit [Ping timeout: 480 seconds]
<ajax> and i should probably bite the bullet and finish refactoring appleglx to use the same vtables as everyone else instead of being weird ifdefs
<karolherbst> dunno... this is definetly something which can be automated
<DavidHeidelberg[m]> I think issue is, that nobody looking at Github, while people still see stuff on Gitlab
<DavidHeidelberg[m]> so at least propagate failure would be "nice"
<karolherbst> you can also subscribe to labels
<karolherbst> and the build error issue could have a "macos" or "apple" label and relevant people get pinged
<karolherbst> I honestly don't see this "warning gets ignored" as a problem here if we deal with it the proper way
<DavidHeidelberg[m]> jenatali: I put it as example going into extreme (not sure if it's obvious from my msg ;) )
<DavidHeidelberg[m]> if Mesa supports MacOS, it should work. If no-one willing to support it, the code should be rather dropped then, than say "it breaks, we don't care"
<DavidHeidelberg[m]> jenatali: no,no :D don't worry :D
<karolherbst> e.g. if marge complains on my MR I broke the build, and gives me a link on how to create the issue with everything pre filled, then that's not painful, I just click and create. Best if marge just does it automatically
<karolherbst> if it gets missed, it might happen on the next MR
<jenatali> David Heidelberg: and of course I got disconnected and didn't notice I needed to re-auth so only you saw my message lol
<DavidHeidelberg[m]> jenatali: Matrix 4ever sometimes, I hate that disconnection, had same problem today
* DavidHeidelberg[m] thanks god for https://dri.freedesktop.org/~cbrill/dri-log/
kts has joined #dri-devel
Guest1393 has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Konversation terminated!]
nchery has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
eukara has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
soreau has quit [Ping timeout: 480 seconds]
gawin has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
zehortigoza has joined #dri-devel
sdutt has quit [Remote host closed the connection]
sdutt has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
pH5 has quit []
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
<daniels> alyssa: there are a surprising number of people using llvmpipe + osmesa on macOS
<karolherbst> if there would be just a proper API to do off screen rendering :(
<ajax> there's several
<karolherbst> can't we just map osmesa on top of one of those?
<ajax> pretty much do
<ajax> it's basically the same kind of binding as the libgl-xlib target, just without, you know, surfaces
<karolherbst> osmesa on top of zink :D
<ajax> mm-hmm, would be nice.
fahien has quit [Ping timeout: 480 seconds]
garrison has quit []
i-garrison has joined #dri-devel
fahien has joined #dri-devel
soreau has joined #dri-devel
nchery has joined #dri-devel
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
Jeremy_Rand_Talos_ has joined #dri-devel
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
<dj-death> MrCooper: !18788 looking good to you?
ybogdano has quit [Ping timeout: 480 seconds]
nchery has quit [Read error: No route to host]
nchery has joined #dri-devel
ybogdano has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
<alyssa> daniels: concerning
fahien has quit []
fahien has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
<swick> emersion, pq: there is a MR for mutter for using libdisplay-info and I'm unsure what to do about it. We still don't have any high level API but tbh the low-level API is enough to replace all the current usage in mutter.
<swick> do we still want a high level API before we make the first release?
<emersion> we don't necessarily have to, but it would be a good opportunity to figure out what we need in the high-level API
<emersion> but it might be too harsh of a first step to do this in one go if mutter already has some low level parsing in place
<swick> the low-level API in di does exactly what we do in mutter right now so it's not a regression in any way
<swick> so we could just do start with that but I'm really not sure what the best idea here is
<swick> but having libdisplay-info as a required dependency on mutter without a release would be bad
sobkas has quit [Remote host closed the connection]
mvlad has quit [Remote host closed the connection]
gawin has quit [Ping timeout: 480 seconds]
Lucretia has quit [Read error: Connection reset by peer]
Lucretia has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
Leopold_ has joined #dri-devel
Surkow|laptop has quit [Ping timeout: 480 seconds]
<jekstrand> jenatali, daniels: Does the Windows testing in Mesa CI actually test WSI stuff? Enough that I'd detect a crash at least?
<jekstrand> I suspect Zink would probably crash if WSI didn't work.
<zmike> it will
<jekstrand> Awesome
<jenatali> jekstrand: Yes I believe so
<jekstrand> I've tested !18826 locally on top of the NVK branch but, of course, I can't test Windows. Woo.
<jekstrand> I should probably test lavapipe on that branch....
<jenatali> jekstrand: I can help with Windows testing in a few weeks if you need it
Surkow|laptop has joined #dri-devel
<jekstrand> jenatali: If CI doesn't blow up, I doubt it's broken.
lyudess has quit []
Lyude has joined #dri-devel
<jenatali> Yep
<emersion> swick: i don't mind doing a release, but i wonder if we should freeze the API or mark it as unstable for now
<jenatali> CI only tests the Microsoft drivers for GL/VK on Windows, so theoretically there could be llvmpipe/lavapipe regressions that don't get caught
<jekstrand> Looks like I did break lavapipe. :D
<karolherbst> how rude
<karolherbst> btw.. is the virtl-on-gles test timing out occasionally?
<karolherbst> *virgl
neoXite has quit []
<mdnavare> vsyrjala: jadahl: Wanted to follow up with you both on VRR discussion and what the final verdict was : Do we agree to change the codebase in i915 to always calculate the VRR params and keep it ready so we dont need full modeset when VRR enable is requested and at that point we can just commit the pre computed state to the HW in commit tail?
fahien has quit [Ping timeout: 480 seconds]
<mdnavare> vsyrjala: The second question was should we reject the modeset if requested on a non VRR panel or just continue modeset without VRR and somehow let the user know through exposing the crtc state vrr enable or a HW state readout of VRR enable reg?
<karolherbst> yeah.. seems like a common issue
gawin has joined #dri-devel
<swick> emersion: I wouldn't mind it being unstable for now and dealing with changes in mutter
<emersion> making it unstable would mean that we don't need to be extra-careful when designing APIs
<emersion> so it would be simpler, and as more eyes/users look at the API, it could be improved
<swick> mh, but then again it means we need to either ensure a specific version to be available at runtime or do some other tricks
<swick> or just statically link it which some packagers might not like?
OftenTimeConsuming has quit [Remote host closed the connection]
<emersion> for wlroots and libliftoff i tell people that statically linking is better, and let distros deal with the dynamic linking
OftenTimeConsuming has joined #dri-devel
rasterman has joined #dri-devel
<swick> mh yeah, I'll ask for opinions on the mutter side but I'd prefer a release soon with unstable API that we can statically link
fab has quit [Quit: fab]
lemonzest has quit [Quit: WeeChat 3.5]
chipxxx has quit [Read error: No route to host]
maxzor has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
JohnnyonFlame has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
apinheiro has joined #dri-devel
nchery_ has joined #dri-devel
ybogdano has quit [Ping timeout: 480 seconds]
nchery_ has quit []
<zamundaaa[m]> fwiw I want to use libdisplay-info ASAP in KWin as well. As a starting point I think just using git submodules would work
nchery has quit [Ping timeout: 480 seconds]
<karolherbst> how can one set a custom vdpau driver?
<karolherbst> nvm.. the search path was just all wrong
nchery has joined #dri-devel
ybogdano has joined #dri-devel
chaim has quit [Quit: Konversation terminated!]
Duke`` has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
pallavim has quit [Ping timeout: 480 seconds]
<jstultz> jekstrand: so curious about your thoughts.. trying to look at using drm_syncobjs a bit, and the ioctls being always against the drm device is sometimes a problem as not all the apps that might want to import & wait on a passed syncobj may have permissions to the drm device. A thought was maybe to allow syncobj ioctls against the exported and passed syncobj fd itself?
<karolherbst> is there a way to dump LLVM IRs after every pass?
maxzor has quit [Ping timeout: 480 seconds]
<jekstrand> jstultz: I don't see why that couldn't be wired up. Let me look and see if we expose anything right now
ahajda has quit [Ping timeout: 480 seconds]
<jekstrand> jstultz: Yeah, we don't have any ioctls today. What kinds of things were you wanting to be able to do?
<airlied> jstultz: isn't that dma-fences?
<jstultz> jekstrand: basically the same drm_syncobj ioctls one would do against the drm_device. import/export/signals/waits/query
<jstultz> airlied: would like to preserve the drm_syncobj and not just share sync_files
<jstultz> (sorry, be back in a bit, realized I have an appt I have to run for)
apinheiro has quit [Quit: Leaving]
<karolherbst> uhh.. error: use of undefined value '@llvm.amdgcn.s.buffer.load.f32' :(
<karolherbst> how can I make the llvm tooling to just accept my code?
ybogdano has quit [Read error: Connection reset by peer]
ybogdano has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
<alyssa> karolherbst: download NIR
mhenning has joined #dri-devel
<karolherbst> alyssa: yeah soo.. I have two choices: make ACO work, which is a lot lot lot work, or deal with LLVM :(
<karolherbst> or convince others to deal with the LLVM instead
<karolherbst> anyway.. in case anybody knowing enough about LLVM stumbles upon my pain, here it's the thing amdgpu-isel doesn't like: https://gitlab.freedesktop.org/-/snippets/7077
enunes has quit [Ping timeout: 480 seconds]
enunes has joined #dri-devel
chipxxx has joined #dri-devel
<alyssa> karolherbst: maybe what you really need for that sweet PR is rusticl on apple m1
<alyssa> :-p
<karolherbst> here is the deal. If an apple M1 shows up on my door out of myserious reasons, I might be inclined to get CL up and running on it.
<alyssa> :-p
<alyssa> here is the deal. We haven't plumbed in compute kernels yet :-p
<karolherbst> but if one would let's say, just give it to me to make CL work, I have to expleicitly state, that giving me the hardware doesn't mean I actually do it, otherwise I'd get into legal troubles :P
<karolherbst> ehhhh
<karolherbst> I knew there is a catch
<alyssa> r/e'd enough to get basic compute with SSBOs working
ybogdano has quit [Read error: Connection reset by peer]
<karolherbst> alyssa: that's all I need
<karolherbst> well.. and images
<alyssa> haven't r/e'd atomics or images yet
<alyssa> soon(tm)
<karolherbst> does texturing work?
<alyssa> or as i'm inclined to say
<alyssa> eventually(tm)
<karolherbst> like.. txl and the likes?
<alyssa> yes
<alyssa> mostly i'm working through the gles versions in order
<alyssa> gles2 is basically passing deqp
<karolherbst> so.. readonly images are actually working then :P
<alyssa> gles3 is ~90%
<karolherbst> good enough for luxmark v3.1 at least
<alyssa> all the compute goodness is in gles31
<alyssa> of course, gles3 requires MRT
<karolherbst> yeah.. the GL bits are more crazy
<alyssa> and the driver has to emulate MRT with compute kernels in some cases
<alyssa> so that'll be... fun
<karolherbst> but CL is really slim in what it needs
<karolherbst> don't even need atomics if CL 1.0 is enough
<alyssa> lol
<karolherbst> yeah.. those becaomse core on 1.1
<karolherbst> *in
<karolherbst> CL 1.0 is really really small
<karolherbst> atm I always export support for atomics though because generally all drivers doing compute shaders support that :D
<zmike> > I have two choices: make ACO work, which is a lot lot lot work, or deal with LLVM :(
<zmike> THERE IS ALWAYS A THIRD OPTION
<karolherbst> zmike: I mentioned that.. right after :P
<karolherbst> ohh you meant zink :P
<karolherbst> though I am really close on radeonsi, just LLVM bugs me
<swick> vsyrjala: have you ever seen a display change the EDID according to the display configuration?
<alyssa> zmike: so how do you feel about making zink work on asahi linux
<zmike> alyssa: I'm willing to make minor changes myself as needed and do reviews for code other people write, but I'm not planning to work directly on it for the foreseeable future
<zmike> i.e., write a vulkan driver and we'll talk
<airlied> alyssa: MRT needs compute wtf? do I dare ask why?
iive has quit [Quit: They came for me...]
<karolherbst> cursed vector: v6f32 = BUILD_VECTOR t204, t203, undef:f32, undef:f32, undef:f32, undef:f32
illwieckz has quit [Ping timeout: 480 seconds]
<alyssa> zmike: oh yeah you writing the vulkan driver was the catch ;p
<alyssa> airlied: uhhh
<alyssa> it's a tiler.
<alyssa> hardware tilebuffer is only big enough for 64 bytes per pixel at the maximum size
<alyssa> that's enough for MRT 4x RGBA16F with no MSAA
<alyssa> but if you have MRT 8x like desktop GL needs
<alyssa> or probably MSAA
<alyssa> then... whoops.
<alyssa> what do?
<alyssa> spill to main memory, of course.
<zmike> alyssa: nice meme
<alyssa> (Apple calls this case "large MRT")
illwieckz has joined #dri-devel
gawin has quit [Ping timeout: 480 seconds]
Jeremy_Rand_Talos__ has joined #dri-devel
<alyssa> Curiously, I can't find a single reference to it in Apple docs
<ajax> that's... remarkable.
<alyssa> even though it should cause a pretty significant perf hit
<karolherbst> does metal even need this?
<alyssa> karolherbst: yes, apple's driver does this for MRT 8x with RGBA32 and no MSAA (for example)
<karolherbst> ahh
<alyssa> (and Metal does allow that combination on M1)
<alyssa> (the "large MRT" name I got from a failed assertion IIRC)
<alyssa> It's odd to me, tbh
<alyssa> The tilebuffer is 32KiB which is plenty big
<alyssa> There just are only 3 supported tile sizes in metal (16x16, 32x16, 32x32)
<ajax> uh. do you have working sample shading? could you have multiple ms images and do your own clever resolves?
<alyssa> (Mali has a much smaller tilebuffer but never needs to spill like this, because the driver can drop all the way down to 4x4 tiles if needed.)
<ajax> kinda the same thing i guess
<alyssa> I don't think AGX supports sample shading
Jeremy_Rand_Talos_ has quit [Ping timeout: 480 seconds]
<alyssa> The driver just sticks a "for (int s = 0; s < # of samples; ++s) { ... }" around your fragment shader
<alyssa> also AGX doesn't really have a tilebuffer
<alyssa> just very fast local memory (i.e. shared memory for compute)
<alyssa> also AGX fragment shaders are just compute shaders
<alyssa> with 1 workgroup == 1 tile
<alyssa> and the tilebuffer == local memory
<alyssa> and load/store tile instructions == formatted load/store from local memory
<alyssa> there's no fragment writeout stage
<karolherbst> sounds cursed
<alyssa> just a "blit entire block of pixels from tilebuffer to a shader image"
<alyssa> and you can specify an "end of tile" (powervr name) program that runs once for each tile after everything else
<alyssa> (without MRT, that's just a single logical instruction: blit the tile to an image)
<alyssa> (with MRT, it's that *n for each render target. but you can imagine doing mulitsample resolves there or whatever.)
<alyssa> karolherbst: I mean, traditional tilers are organized in basically the same way, they just have more fixed function blocks encoding graphics API concepts, whereas AGX exposes a much lower level programmable interface
chip_x has joined #dri-devel
<alyssa> MRT, MSAA / sample shading, whatever pixel formats you want, programmable blending, logic ops ... everything can be lowered efficiently.
<alyssa> But you also get entirely new graphics APIs concepts in Metal like "tile shaders"
<alyssa> which are compute shaders that execute within a fragment batch and can access the tilebuffer as if it were workgroup shared memory
<ajax> is 16x16 a hardware minimum tile size?
<alyssa> ajax: AFAICT..
<alyssa> Hard to see, the encoding is pretty sparse :-(
<alyssa> If the driver can go smaller, I don't know how...
<ajax> i'm wondering if you could do something by making your kernel fizzle if the invocation id meant you were outside of an 8x8 subset
<ajax> or however small you want the tile to be
<ajax> i mean, you're the one kicking off all these tile jobs, right?
chipxxx has quit [Ping timeout: 480 seconds]
<alyssa> oh, that's... novel
<karolherbst> jo.. let's see if LLVM_ENABLE_EXPENSIVE_CHECKS is any helpful
<mareko> I wonder why CI jobs time out, they seem to be stuck on deqp-runner suite
aravind has joined #dri-devel
<mareko> I had to manually cancel a CI job and restart it while Marge was running a pipeline, some script could do the restart automatically
<karolherbst> the virgl one, right?
<mareko> virgl-on-gl 3/3
<karolherbst> yeah.. same happened to me on virgl-on-gles 2/3
<karolherbst> but restarting didn't fix it
<mareko> and llvmpipe-deqp-asan and softpipe-asan-gles31
<karolherbst> maybe a runner is dead or something?
<karolherbst> mhh
<karolherbst> same there
<mareko> I didn't want Marge to reject it, so I restarted the jobs one by one to fool Marge that the pipeline is always busy
<karolherbst> something is completely busted there...