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
<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
<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.
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]
<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"
<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
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
<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?
<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?