ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
nchery is now known as Guest255
nchery has joined #dri-devel
nehsou^ has joined #dri-devel
Guest255 has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
unerlige has left #dri-devel [#dri-devel]
ced117 has quit [Ping timeout: 480 seconds]
Lucretia-backup has joined #dri-devel
Lucretia has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
ced117 has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
slattann has joined #dri-devel
mdnavare has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
mhenning has joined #dri-devel
stuarts has quit []
mbrost_ has quit [Ping timeout: 480 seconds]
slattann has quit []
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
stuart has quit []
ngcortes has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
kurufu has quit [Remote host closed the connection]
slattann has joined #dri-devel
kurufu has joined #dri-devel
janesma has quit [Quit: Leaving]
slattann1 has joined #dri-devel
Duke`` has joined #dri-devel
slattann has quit [Ping timeout: 480 seconds]
slattann1 has quit [Ping timeout: 480 seconds]
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
mhenning has quit [Quit: mhenning]
lemonzest has joined #dri-devel
tzimmermann has joined #dri-devel
itoral has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
<cyrozap>
I really shouldn't find `DRM_FORMAT_Y0L0` as funny as I do, but I just couldn't help but chuckle when I first saw it 😂
dri-logg1r has joined #dri-devel
dri-logger has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
flto has quit [Remote host closed the connection]
flto has joined #dri-devel
maxzor has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
frieder has joined #dri-devel
danvet has joined #dri-devel
rpigott has quit [Read error: Connection reset by peer]
rpigott has joined #dri-devel
ahajda has joined #dri-devel
maxzor has quit [Ping timeout: 480 seconds]
tursulin has joined #dri-devel
mszyprow has joined #dri-devel
<ccr>
:D
frankbinns has joined #dri-devel
lynxeye has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
ahajda has quit [Remote host closed the connection]
tzimmermann has joined #dri-devel
<tzimmermann>
:D
<javierm>
haha, "I'll set the format to whatever I want"
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
ahajda has joined #dri-devel
<tzimmermann>
javierm, sorry for throwing random comments into the discussion
<javierm>
tzimmermann: on the contrary, thanks for chiming in
<javierm>
tzimmermann: so many layers that it's hard to follow :)
<tzimmermann>
i fell like i can't wrap my mind around this.
<javierm>
yeah, same
<tzimmermann>
i've looked at this code quite a bit, but it's really not easy to read
pcercuei has joined #dri-devel
<javierm>
agreed. I'll do some tests and post the patch suggested by Andrzej today, but I'll take a look to make drm_fb_helper_fini() private and post as RFC at some point
<javierm>
tzimmermann: a drmlog + user-space console (i.e: systemd-consoled) would be nice to have but much more complicated to be a drop-in replacement as a first step
dj-death_ has joined #dri-devel
dj-death has quit [Ping timeout: 480 seconds]
dj-death_ has quit []
dj-death has joined #dri-devel
ella-0_ has joined #dri-devel
ella-0 has quit [Read error: Connection reset by peer]
gio has quit [Remote host closed the connection]
gio has joined #dri-devel
rasterman has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit []
dj-death has quit [Quit: Lost terminal]
dj-death has joined #dri-devel
rkanwal has joined #dri-devel
nchery has quit [Read error: Connection reset by peer]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<karolherbst>
*huge sigh*
gio has quit []
devilhorns has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
gio has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
technopoirot has joined #dri-devel
mclasen has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<tzimmermann>
"When a frame buffer device receives a video= option it doesn't know, it should consider that to be a video mode option." what does that mean?
<karolherbst>
jekstrand: what would help a lot with rusticl would be to get https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/15988 in. I have some fixes to your previous version, which I need to figure out how to get into this. But now we also have some conflicts on the latest AMD stuff.
<karolherbst>
I'll try to move over, but I also need to reshuffle a few things around, let's see how annying that will be
<javierm>
tzimmermann: the way I read that is that if mode specified in video= isn't one specific to a driver, then it should consider that's one defined in drivers/video/fbdev/core/modedb.c
<tzimmermann>
i see
<tzimmermann>
thanks
aknautiy has quit []
itoral has quit [Remote host closed the connection]
mclasen has quit []
mclasen has joined #dri-devel
apinheiro has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: the framebuffer_release() move to drm_fbdev_fb_destroy() will have to wait then, since we first will need to fix all the drivers to provide a .fb_destroy() callback
<javierm>
otherwise we will introduce fb_info leaks
<tzimmermann>
javierm, yeah. but it's not urgent as we (usually) never unload the native drivers until reboot
<javierm>
I wonder how many of the drivers not using the generic fbdev helpers really need something custom
<javierm>
tzimmermann: yes, and it's only when removing *while* having the emulated fbdev opened
<tzimmermann>
javierm, i heard that i915 does something special
<tzimmermann>
but i never really checked
<tzimmermann>
some need BO placement in vram, which could be solved
<tzimmermann>
some provide HW-accel, which they might not want to give up
<javierm>
tzimmermann: btw, even with drm-misc-next I tried with a couple of aarch64 DRM drivers and removing while running fbtests is broken anyways
<tzimmermann>
that could also be solved
<javierm>
the only driver that worked for me was simpledrm :)
<javierm>
so I guess most drivers can't really cope with this case currently so not something urgent to fix
<tzimmermann>
i also have that patchset that enables direct fb_mmap for GEM shmem. but hand-over hangs for ~30 secs. i suspect that some step of releasing fbdev creates an issue
<javierm>
I see
<javierm>
I'll keep this patch in a local just in case I ever have time to go thorugh all the drivers
<tzimmermann>
well, i don't know: apparently simpledrm unloads. then i915 load. but i915's console is stuck in probing outputs. and after half a minute it continues.
<javierm>
interesting, I wonder what could be causing that
<tzimmermann>
but i don't see how fbdev mmap would affect this
<javierm>
yeah, me neither. Hence the wondering
<tzimmermann>
i have to try with different hardware. maybe it's related to i915
<tzimmermann>
javierm, can we make all of fb_mmap's vmas go SIGBUS after we unloaded an fbdev driver?
sdutt has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
<javierm>
tzimmermann: that's what daniel suggested as well
<tzimmermann>
but is it easily possible?
<javierm>
tzimmermann: I don't know. Looked at little bit and didn't figure out how to implement that
<javierm>
but didn't spend that much time on it
<javierm>
and the close is orthogonal anyways. The problem is with .fb_destroy being called later and things to boom
<javierm>
*go
<tzimmermann>
something like: for (<range of fbdev memory>) { invalidate_vma_at(...) }
<tzimmermann>
it's ok
<javierm>
tzimmermann: just try the following if you have a rpi4: cat < /dev/fb0 &; echo gpu > /sys/bus/platform/drivers/vc4/unbind; kill %1
<javierm>
and you will see a crash. That would fail even if we invalidate all the mapped vma
<javierm>
although I agree that makes sense to do that as well
sdutt has quit []
sdutt has joined #dri-devel
mclasen has joined #dri-devel
<javierm>
tzimmermann: so about drmcon. Noralf implemented the console as a DRM client, and since we can always rely on simpledrm to work on a system, there will always be a VT
<javierm>
I think that could be a good solution to disable CONFIG_FB for good
<javierm>
and on hand-over the real DRM driver could also have a console DRM client and use that as VT instead of fbcon + emulated fbdev
<javierm>
tzimmermann: I'll try to make some time to look at his patches closer
sumoon has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
<karolherbst>
jekstrand: anyway, what would help me here specifically is, to land 15759 first, rebase 15988 on top of it, then I can rebase my stuff on top of that and figure out what we have to do to fix clover (the image lowering pass specifically)
<karolherbst>
and then we can add that to the MR
<jekstrand>
mareko: Mind givin the third patch of !15988
<jekstrand>
a quick look again? The rebase on some of your GFX11 changes was a bit rough.
RSpliet has joined #dri-devel
Haaninjo has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: If you wanted to review " util/bitset: Support larger ranges in BITSET_TEST/CLEAR_RANGE ", that would help me land most of 15988 today.
<jekstrand>
karolherbst: Also, I added your patch and one more for ntt info stuff. If you could review the one from me, that'd be good.
<karolherbst>
jekstrand: yeah, sure, will do. I think we still need to fix the clover lowering pass though
<karolherbst>
but I don't have any solid patch, because it's after a bunch of rework :(
<jekstrand>
karolherbst: Sure.
<jekstrand>
karolherbst: But this lets us land the big shader_info churn which should help with rebase pain all around.
devilhorns has quit [Remote host closed the connection]
<karolherbst>
ohh that's actually your patch I think :)
<karolherbst>
and it's duplicated.. guess I failed to rebase
<karolherbst>
ehh no, it's images and samplers
<karolherbst>
anyway, we'll need this I figure
<karolherbst>
(just in the old location and stuff)
<jekstrand>
karolherbst: Yeah, that's because of rebase weirdness
<karolherbst>
yep
<jekstrand>
Well, maybe we need to do something in the clover pass but with you moving it, things got weird.
<karolherbst>
I noticed the difference and decided to wait until we land that stuff :)
<karolherbst>
correct
<jekstrand>
Let's focus on getting shader_info landed, then we can deal with clover.
<karolherbst>
we simply need to use samplers_used and images_used though
<karolherbst>
*set
<jekstrand>
Sure
<jekstrand>
Well, we want to set textures_used too
<karolherbst>
that's already done
<jekstrand>
But, yeah, we need to adjust those when we rework images.
<jekstrand>
Yup
<karolherbst>
huh? but I think we need that because you actually change that stuff inside 15988 already, no?
<karolherbst>
at least the samplers_used part
<karolherbst>
I think not having that caused llvmpipe to segfault
<jekstrand>
There's two things going on there. One is fixing up samplers_used to not use _INSIDE_WORD which seems to have been rebased badly.
<karolherbst>
correct
<jekstrand>
The other is to set images_used
<jekstrand>
which we aren't doing at all now
<karolherbst>
ahh
<jekstrand>
Also, the samplers fix starts zeroing the samplers_used before setting bits so we don't have stale data.
<jekstrand>
So that may also be a fix
<jekstrand>
Would you rather we fix that pass in clover and then move it or move then fix?
<karolherbst>
I think we need to fix it now, because 15988 breaks things, but not 100% sure on that. If it doesn't break anything there, then it doesn't matter, but if it does, we have to do it there :)
<jekstrand>
I don't think 15988 breaks anything relative to upstream.
<jekstrand>
Which is to say that I think upstream is already broken.
<jekstrand>
:)
<karolherbst>
that might also be the case :)
<jekstrand>
Like upstream doesn't set images_used or samplers_used at all today
<karolherbst>
yeah...
<karolherbst>
let's wait on CI then and I'll send out a new MR to fix it up or something
<jekstrand>
Ok. Also, I've got a plan to drop the one weird radeonsi patch so we don't need to wait on mareko for 15988.
<jekstrand>
So if you can review those two patches, I I think we can merge pending one quick fixup and CI.
<karolherbst>
jekstrand: btw, you saw that clang fail in CI already?
<jekstrand>
Well, merge all but iris patches.
<jekstrand>
Oof. Yeah, that's a bug. :)
<karolherbst>
sounds like a plan
<karolherbst>
ping me when CI is happy, then I'll go ahead and review things :)
tzimmermann has quit [Quit: Leaving]
<jekstrand>
I'll re-base with the iris patches on top, too.
<karolherbst>
cool
devilhorns has quit []
devilhorns has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
stuart has joined #dri-devel
<jekstrand>
karolherbst: Ugh... It appears it does break images with llvmpipe somehow. :(
<karolherbst>
well...
<karolherbst>
in CL or GL/Vk as well?
<jekstrand>
Oh, I bet it's the PIPE_MAX_IMAGES bump
<karolherbst>
yeah, most likely
<karolherbst>
we might want to put in the old limits for llvmpipe
<jekstrand>
Yeah.
<karolherbst>
also, can we drop TGSI already? :D
<jekstrand>
hehe
<jekstrand>
anholt is getting really close
<jekstrand>
karolherbst: How do I force CL to use llvmpipe again?
<karolherbst>
LP_CL=1
gouchi has joined #dri-devel
<karolherbst>
jekstrand: the painful part are the drivers which rely on ntt now though :(
<karolherbst>
so I guess we are stuck with it for quite some time
<jekstrand>
karolherbst: Yeah.
gouchi has quit []
<karolherbst>
a nir backend for nv30 would be a fun project though....
<jekstrand>
karolherbst: But it's better than keeping the glsl_to_tgsi path alive
<karolherbst>
true
nchery has joined #dri-devel
* karolherbst
does even own a nv35, nv42, nv43, nv44 and g73
shashanks has joined #dri-devel
<jasuarez>
hi! I have a question about ARB_get_program_binary extension
<jasuarez>
according to mesamatrix.net page, it is supported by a bunch of drivers
<jekstrand>
karolherbst: How do I select lavapipe as the device piglit uses?
<jasuarez>
but shouldn't this be supported actually by all drivers?
<jasuarez>
after all, we are using dummy_true to enable it, and according to spec, the number of binary formats supported can be 0
<karolherbst>
jekstrand: uhhh... good question. I suspect it defaults to some device, but I guess there is a flip somewhere, let me check
<karolherbst>
jekstrand: mhh, seems like piglit doesn't enforces any device type
<karolherbst>
so something must be wrong on your end? dunno, does clinfo work?
<jekstrand>
Ok. I'll disable iris in my build for now then
<jekstrand>
It also fails on iris, so IDK what's going on there. :-/
<karolherbst>
probably something with libclc
<karolherbst>
in gdb do a "catch throw" and see where it fails
sdutt has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
<karolherbst>
(well I assume you test with clover, as I doubt you did the rebase for rusticl :P )
<jekstrand>
Yeah, something broke somewhere. It goes pass -> fail on iris too
<karolherbst>
I suspect you have to take the patch setting sampler_used, at least that's my bet
<jekstrand>
Ugh... It's your patch. :P
<karolherbst>
oh no :(
<jekstrand>
Let me see if I can figure out why
<karolherbst>
but why would that break iris?
<jekstrand>
idk
<jekstrand>
Maybe I am getting llvmpipe now?
<jekstrand>
Anyway, I can repro so I'll try to fix
<jekstrand>
Oh, I bet I know what's going on
rsalvaterra has quit []
<karolherbst>
ahh yeah...
<karolherbst>
I see it now as well :)
rsalvaterra has joined #dri-devel
<karolherbst>
we could leave the old sampler_mask code in I guess, or...
<jekstrand>
Turns out, we need that clover patch. (-:
<jekstrand>
Done. Let's see how CI likes it now.
<karolherbst>
🙃🙃
<jekstrand>
I could believe your NTT patch might break lavapipe too but we'll see.
<karolherbst>
yeah.. it could
<jekstrand>
Vulkan drivers really shouldn't be using samplers/textures/images_used but lavapipe is SPECIAL.
<karolherbst>
I hope one day we can get rid of gallium or something (thinking like 20 years ahead)
<jekstrand>
All zink all the time?
mclasen has quit []
<karolherbst>
yeah
<karolherbst>
in 20 years CPU overhead might not be relevant anymore
<karolherbst>
I am sure people thought the same 20 years ago
<jekstrand>
lol
<karolherbst>
I am sure in the future we have a full shader pipeline per pixel
<karolherbst>
"every pixel is perfect" or something
<jekstrand>
We'll build a tiny quantum GPU into each of the LEDs in the display.
<karolherbst>
we compile shaders to quantum programs, who just emit the correct light then
<jekstrand>
Yup
sdutt has joined #dri-devel
<jekstrand>
WTF does my MR affect llvmpipe polygon stipple?!?
nehsou^ has quit [Remote host closed the connection]
<jekstrand>
I wonder if someone is calling nir_tgsi_scan_shader without nir_gather_info()
<karolherbst>
probably
<jekstrand>
karolherbst: I think we need to split this up. Let's try to land the shader_info refactor and I'll keep poking at this NTT thing.
<karolherbst>
fine by me
<jekstrand>
karolherbst: Ok, Dropped everything but the patches I intend to land. CI is running but should be clean. There are 3 patches that need review.
shashank_sharma has joined #dri-devel
tjmercier has joined #dri-devel
shashanks has quit [Ping timeout: 480 seconds]
shashank_sharma has quit [Ping timeout: 480 seconds]
<jekstrand>
ugh... pstipple...
rasterman has quit [Quit: Gettin' stinky!]
dviola has quit [Quit: WeeChat 3.5]
heat has joined #dri-devel
maxzor has joined #dri-devel
<jekstrand>
karolherbst: Ok, I think I found all the things (TM)
<karolherbst>
jekstrand: seems like there are more bugs :(
<jekstrand>
karolherbst: Yeah, something's still wrong with lavapipe
<jekstrand>
Working on it
<jekstrand>
lavapipe has so much plumbing....
<karolherbst>
soo.. I know that invalid memory access and that happens if the amount of samplers/images/textures isn't properly set, but I guess you figured as much already
<jekstrand>
Oh, I wasn't looking at that. Nice!
<karolherbst>
mhhh
<karolherbst>
I had to debug things like that too often for my taste :D
<jekstrand>
I know it's something like that. Why they're not properly set is the real question.
<karolherbst>
soo.. it doesn't have a format attached to the image
<karolherbst>
ehh wait.. it probably overflows in a weird way
<karolherbst>
so this static_state array is shared, which is annoying
<karolherbst>
so it might make sense if it's a texture/sampler
<karolherbst>
that's what I pointed out in the past
<karolherbst>
could be something similar
<jekstrand>
It's similar but worse
<karolherbst>
not surprised :)
<jekstrand>
llvmpipe just doesn't know what to do with zero samplers. :-(
<jekstrand>
You know, like if all you use is texelFetch() :)_
<karolherbst>
oh no
<karolherbst>
that's like horrible :)
unerlige has joined #dri-devel
_franck_ has left #dri-devel [#dri-devel]
<jekstrand>
idk why airlied put an `if (file_max[] != -1)` around things...
<jekstrand>
whatever
<karolherbst>
I've heard there are plans to split this struct apart :)
Duke`` has joined #dri-devel
shashanks has joined #dri-devel
<jekstrand>
Fixed one bug so it should now be building a valid shader (I hope!)
<jekstrand>
Still doesn't pass, though.
<karolherbst>
jekstrand: I could probably take a look, but I need to eat something now :D
<jekstrand>
I'm looking.
lynxeye has quit [Quit: Leaving.]
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
* jekstrand
is so very confused
Danct12 has quit []
<jekstrand>
How does anything even work?!?
* jekstrand
wonders what lavapipe uses this access stuff for. 'cause it's clearly bogus. :-/
<jekstrand>
Nothing!
<jekstrand>
Awesome.
heat has quit [Remote host closed the connection]
maxzor has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
Danct12 has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
anholt_: Is the plan to delete all of lower_instructions in favour of the NIR lowerings? (all of which should exist at this point because of VK?)
<anholt_>
That would be my goal, but as shown, untangling can be tricky.
<alyssa>
errr except maybe T760, which is 750 confusingly
<anholt_>
ah, went looking for a panfrost/drm-shim/README
<alyssa>
Oh. That would be sensible place, yes...
<alyssa>
provided it got wired into the sphinx so I can link it at people easily
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<anholt_>
midgard does 64-bit?
<alyssa>
yes
<alyssa>
int64, at least
<alyssa>
of unknown levels of brokenness, but it's enough for address arithmetic
<anholt_>
without a pack_64_2x32_split!
* alyssa
covers eyes and ears
<alyssa>
unknown levels of brokenness!
<anholt_>
becoming increasingly known!
<alyssa>
noooo!
<anholt_>
anyway, I can probably throw another lowering bit at it
<alyssa>
_split opcodes are intended for scalar ISAs, non-split for vector ISAs, Midgard is vector and so doesn't handle _split
<alyssa>
at least, I think that was the thinking
<alyssa>
admittedly we don't seem to handle pack_64_2x32 either.. so.. um..
<anholt_>
found the lowering flags needed, looks plausible now
<alyssa>
:+1:
<alyssa>
midgard is supported as-is, it's not conformant (first conformant impl is mali-g52, though mali-g72 would probably pass if someone bothered to do a CTS run)
<alyssa>
I'm not saying regress it, but...
<alyssa>
(ES3.1 anyway, which is where 64-bit kicks in... ES2.0 would be conformant if someone did the submission, ES3.0 is one issue away.)
dj-death has joined #dri-devel
eukara has quit [Remote host closed the connection]
mbrost has joined #dri-devel
jfalempe_ has joined #dri-devel
jfalempe_ has quit []
iive has joined #dri-devel
shashank_sharma has joined #dri-devel
<karolherbst>
uhhh.. guess it's rebasing time?
<alyssa>
karolherbst: good luck
<alyssa>
it's dangerous to go alone, take this!
* alyssa
hurriedly looks around her desk for something to give karolherbst
* alyssa
hands karolherbst a crappy pen
* karolherbst
thankfully accepts the crappy pen
columbarius has joined #dri-devel
adjtm has quit [Quit: Leaving]
<ccr>
:)
shashanks has quit [Ping timeout: 480 seconds]
<jekstrand>
karolherbst: Ok, I've got lavapipe passing again after fixing its descriptor set woes. :-/
<karolherbst>
yay
<jekstrand>
karolherbst: Not sure how comfortable you feel reviewing that.
<jekstrand>
Well, at least the asan run passes. We'll know about the normal one in 10-15 minutes.
<karolherbst>
yeah.. I'll rebase and see how well it works here
<karolherbst>
we might want to merge those MRs? dunno
<karolherbst>
but doesn't look terrible to resolve
<karolherbst>
jekstrand: "info->samplers_declared = nir->info.textures_used[0];" I assume that's on purpose?
<karolherbst>
I have a local change to use samplers_used for that
<karolherbst>
huh
<karolherbst>
soo.. in the old code it uses both
<karolherbst>
I'll use yours and see where this gets me
eukara has joined #dri-devel
<jekstrand>
karolherbst: Uh... I'm not too worried about 15759. We should land the binding table patch but I've got a better version of the sampler patch somewhere.
<karolherbst>
ahh
<jekstrand>
karolherbst: samplers_declared... Not sure. That one's weird. I don't know if drivers look at it to see textures or samplers. On the chance they look at it for both, I figured textures would be a superset of samplers in GL.
<karolherbst>
I honestly have no idea, I put there samplers_used and it worked for me (more or less)
<jekstrand>
More "Why is my format NONE" searching to do. :-/
mszyprow has joined #dri-devel
<karolherbst>
yay, more bikeshedding
* karolherbst
goes into the deep cave of pointless discussions
dviola has joined #dri-devel
* karolherbst
thinks he is done for today
<karolherbst>
*for
<karolherbst>
airlied: I am so closed to just throw in a nack, but now I feel like I am this unreasonable person who just dislikes this perfectly fine feature :( *argh*
<jekstrand>
karolherbst: What feature?
<airlied>
karolherbst: like for the very small niche of r600 it's probably the "best" way, but it's a quite small corner case
<karolherbst>
jekstrand: somebody wants to load llvm bitcode for r600 in clover through clCreateProgramWithIL :)
<jekstrand>
uh...[6~
<karolherbst>
16124
<karolherbst>
jekstrand: that was my first reaction as well
nchery has quit [Ping timeout: 480 seconds]
<karolherbst>
but apparently I am only doing "whataboutism" by bringing up potential problems, so...
<alyssa>
karolherbst: Hmmm do you want me to do the NAK?
<karolherbst>
:D
<karolherbst>
please go ahead
<alyssa>
I have no qualms about NAKing that for you! :p
<karolherbst>
well
<karolherbst>
you should nack it because you think it's a terrible idea :P
<karolherbst>
if I am fed up I'll nack it myself! :D
<jekstrand>
karolherbst: Wow...
<karolherbst>
but I'll put an epic statement besides it.. like "we solution is less LLVM not more"
<karolherbst>
*the
<airlied>
jekstrand: btw the code used by llvmpipe isn't NTT, it's just some info conversion, NTT is a lot more than that and is orthogonal
<airlied>
and I've tried to refactor the hell that is the samplers/image tracking a few times, and fallen over
frieder has quit [Remote host closed the connection]
<jekstrand>
airlied: I know.
<jekstrand>
airlied: I've had some success today but, aparently, vertex shaders are giving me heartburn.
nchery has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
<karolherbst>
jekstrand: yeah.. so if you'd land 15759 and adjust the other MR on top of it, that would be helpful, because the conflict is super annoying to deal with :(
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
ehh wait
<karolherbst>
yeah.. no, I was thinking about it wrongly, maybe it works out in the end
<jekstrand>
karolherbst: Naked
<jekstrand>
NAK'd?
<jekstrand>
Not sure how you're supposed to type that.
<karolherbst>
not sure, but I also never saw why it's nak and not nack
<jekstrand>
idk
<jekstrand>
Anyway, we'll see how pissed he gets with me. :)
<karolherbst>
:)
<jekstrand>
Ok, back to trying to figure out how I broke lavapipe
danvet has quit [Ping timeout: 480 seconds]
<karolherbst>
okay.. seems like my rebase compiles
<alyssa>
jekstrand: "NAK'd" is when you sugarcoat the nak
<alyssa>
if there's no sugarcoating on the nak
<alyssa>
it's naked
<alyssa>
:-p
<karolherbst>
or nak with style: "Naked-by: ..."
<karolherbst>
so one can add it to their patch
<ajax>
you can always say 'nacked' if you want to have fewer entendres
<Lyude>
I just had the realization that if we just made sure graphics work in kdump we have technically also added support for printing kernel panics to the screen in any situation where the GPU is in/can be put into working order
<Lyude>
kinda shocked this thought never crossed my mind until now
adjtm has joined #dri-devel
<Sachiel>
you could make it print the panic in white over a blue background
<Lyude>
lol seeing a windows bsod and asking myself "how they do that" again is how I realized this
<ccr>
are you sure that's not somehow (tm)(c)(r) Microsoft?
<karolherbst>
there is a software patent for sure, but.. meh
<Lyude>
i don't think we really need any tricks besides that, though. in fact i'm almost curious whether that's exactly what windows does
<karolherbst>
I am sure it is
<ccr>
I would bet there's one at least for the new-ish QR code panic, but who knows ..
<DrNick>
the QR codes are just hardcoded URLs
<karolherbst>
let's put an QR code generator into the kernel and get the microkernel cultist to trash talk linux even more
<karolherbst>
"wait, they put a _QR_code_generator_ inside the kernel? how ridiculous"
<Sachiel>
no need for a generator, just put a hardcoded one pointing to rick astley
<karolherbst>
but make it look different every time
<alyssa>
karolherbst: okay okay hear me out
<alyssa>
add a userspace QR encoder
<alyssa>
and just call out to userspace after the kernel panics
<alyssa>
it's a microkernel design
<Lyude>
actually yeah i was going to say
<alyssa>
what could go wrong?
<ccr>
!
<Lyude>
you probably want it in userspace
<Lyude>
hence why I mentioned kdump :P
<ccr>
/sbin/kqrcode
<karolherbst>
alyssa: but what if it panics because the fs got trashed?
<ajax>
kernel crash handler to play sixel-animated rick astley videos to every pty/tty on panic
<Lyude>
karolherbst: would happen anyway on trying to dump anything
<karolherbst>
Lyude: well.. that's why we dump it into an QR code :P :D
<karolherbst>
ohhh doing it in kdump... mhhh
<karolherbst>
mhhhhh
<Lyude>
karolherbst: also JFYI that isn't quite how kdump works (at least if you're not looking at dumping things to the disk), kdump has it's own initramfs so any qr utilities would be in there
<karolherbst>
yeah...
<karolherbst>
I forgot about kdump
<karolherbst>
yeah.. it's probably fine then
<Lyude>
and the reality is while it isn't 100% reliable: it's no less reliable then what we currently have anyway
<karolherbst>
Lyude: uhh.. I have a terrible idea
<karolherbst>
couldn't the kdump kernel instruct drivers to do a full reset/repost on their devices?
<karolherbst>
although I guess that wouldn't bring back the firmware framebuffer thing...
<Lyude>
karolherbst: well yeah you'd have to anyway. ideally drivers should either bail out if they can't recover things properly, or just read in the current hw state (fastboot style) and go from there
<Lyude>
so it's basically what we're already doing
<karolherbst>
yeah.. just annoying if drm got trashed and you don't have any working state to rely on
<karolherbst>
okay.. let's see how much I failed to rebase :)
<jekstrand>
karolherbst: Ok, lavapipe CI is now green. \o/
<karolherbst>
\o/
<jekstrand>
karolherbst: That said, maybe airlied would be better to review those 4 patches.
<karolherbst>
if they are about llvmpipe, I bet he is
<jekstrand>
They are
<jekstrand>
I'm honestly surprised we got lavapipe to pass conformance with some of the bugs I found. /o\
<airlied>
jekstrand: they aren't real bugs then :-P
<airlied>
point me at things, and I'll look at them later, my main internet is down so it's all slow
mvlad has quit [Remote host closed the connection]
* jekstrand
goes back to working on his blog post
<karolherbst>
oh wow...
<jekstrand>
karolherbst: ?
<karolherbst>
no regressions with llvmpipe on first try
<jekstrand>
karolherbst: Sure you pushed the right branch?
<jekstrand>
:P
<alyssa>
mood
<karolherbst>
seems that way
<karolherbst>
there are regressions with iris though :P
<ajax>
pfft, nobody uses that
<alyssa>
* Kayden has entered the chat
<jekstrand>
hehe
icecream95 has joined #dri-devel
mbrost has quit [Read error: Connection reset by peer]
<karolherbst>
api min_max_constant_args crashes...
<karolherbst>
that's the only regression
mszyprow has quit [Ping timeout: 480 seconds]
<karolherbst>
iris_set_global_binding mhhh
<karolherbst>
that's probably my fault
<karolherbst>
yeah.. I forgot to bump IRIS_MAX_GLOBAL_BINDINGS to 128 :)
<alyssa>
wait, you have both iris and lavapipe passing cl3.0 conformance?
<karolherbst>
I don't
<karolherbst>
lp isn't that far off though
<karolherbst>
reall.. I can make lp pass if I really want to
<karolherbst>
:D
<karolherbst>
it's like three issues 1. CTS checks differently if you are a CPU thing, I pass more things if I force GPU as the type 2. uhm... some alignment crap and what was 3?
<karolherbst>
I think something with clamping
<karolherbst>
alyssa: you have to check the MR :D we were so close to let some pro video editing tool to run on both iris and llvmpipe :D but they use some weird CL 2.0 features I don't want to implement yet
<alyssa>
Woof
<karolherbst>
(stuff like darktable and gimp already works perfectly, besides bugs in those apps)
* alyssa
is trying to understand how to do SSA-based RA with function ABI
<alyssa>
for cursed blend shaders
<karolherbst>
uhhh
<alyssa>
and also for real function calls because apparently you guys want that
<karolherbst>
run away?
<karolherbst>
yeah...
<karolherbst>
sooo...
<karolherbst>
alyssa: the idea is to do RA per function
<karolherbst>
you start with those not calling anything
<karolherbst>
store their internal register usage
<alyssa>
right..
<karolherbst>
and in the function calling that, you have to move values out of that range
<alyssa>
and because APIs all forbid recursion, it works?
<karolherbst>
so if it uses reg 0-14 and reads from 0-6 and stores into 0-3, you know where you have to put args, read out results and what values need to be moved away
<karolherbst>
alyssa: yes
<alyssa>
mmh
<karolherbst>
that would be one idea
<karolherbst>
the other is.. function stacks
<karolherbst>
but let's not get into that
<alyssa>
stacks are expensive on Mali
<alyssa>
(and every GPU but come on)
<karolherbst>
they are expensive everywhere I figure
<karolherbst>
anyway.. a function call forces certain values to be live before it
<karolherbst>
and only inputs are allowed to be placed inside that
<karolherbst>
unless they are live after the function call, in which case you have to copy them
<alyssa>
*nod*
<alyssa>
Trying to figure out the least gross way to handle this and kick the rest of the function call can down a future MR, preferably written by icecream95 and not me ;-)
<karolherbst>
but I am no expert on that matter and there are probably good papers describing the perfect thing to do here :P
<alyssa>
just want to get the RA part sound
<karolherbst>
alyssa: what we do in nouveau I think is to move into live regs of functions
<karolherbst>
undefs for non inputs
<karolherbst>
so have a couple of those movs before a function call, so that RA moves things accordingly
<karolherbst>
but we don't do SSA based RA
<karolherbst>
(and we only use it for constant functions, not compiled at runtime)
<alyssa>
*nod*
<alyssa>
for now going to just insert some moves locally since I have bigger fish to fry
<karolherbst>
yay.. only 154 commits to go
eukara has quit []
<alyssa>
:D
<karolherbst>
you are laughing but I peaked at around 210
<karolherbst>
jekstrand: sooo.. do you know if there is proper hardware support on intel to use buffers as 2d textures/images? like texture buffers, but in 2D?
<karolherbst>
we... need it
<karolherbst>
(not for 3.0, but for some CL apps making use of this)
<jekstrand>
2D non-array? Yes.
<karolherbst>
yes
<karolherbst>
and only that
<jekstrand>
Yeah, that should be fine. As long as the row stride is a multiple of the pixel size (or a single component for 3-channel), Intel HW has pretty flexible linear 2D image support.
<karolherbst>
cl_khr_image2d_from_buffer is the CL extension
<jekstrand>
And it should work with the current userptr import path.
<karolherbst>
jekstrand: yeah.. so this ext is actually sane
<jekstrand>
We may need to come up with a non-userptr path, though.
<karolherbst>
you can report required stride alignments and stuff
<karolherbst>
jekstrand: ohh.. so it wouldn't work on non userptr?
<jekstrand>
karolherbst: It would, se just need a gallium hook for it.
<jekstrand>
*we
<karolherbst>
because my hope was I could simply go the texture buffer route, but hand in the stride
<jekstrand>
Sure, that can probably be made to work.
<karolherbst>
that's something I'd like to look at after getting it all merged
nchery has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
apinheiro has quit [Quit: Leaving]
rkanwal has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
eukara has joined #dri-devel
pcercuei has quit [Quit: dodo]
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<cwabbott>
alyssa: yes, function calls are tricky
<cwabbott>
for callee-saved registers, you can model them as special inputs/outputs that are live for the entire function - not *that* bad
<cwabbott>
(or just disable using those registers by pretending they don't exist)
iive has quit []
<cwabbott>
for caller-saved registers and arguments, you have to model them as values/definitions of the call instruction, and there you have to support fixed register arguments in the middle of control flow which is tricky
nchery has joined #dri-devel
<cwabbott>
conceptually it's not that bad - you just have to force it to pick those registers, and move things around just like in the case of register file fragmentation
<karolherbst>
cwabbott: I can imagine some also play around with things like "this function should only take up 5 regs, because surrounded code is hot and that function is hardly called... but I guess that's for later to figure out :)
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
<cwabbott>
karolherbst: yeah, figuring out how many registers should be caller vs callee saved etc. is sort-of orthogonal to implementing it in RA
<karolherbst>
argh "it's only useful for my usecase, please accept my patches" argh... why are people like this :(
<HdkR>
Only all the VA space in the world, seems fine
<HdkR>
Although saying that, other people technically have my use case as well. So it's not /completely/ one sided
<karolherbst>
you mean, using as much of the VA as possible, because not used VA is wasted VA?
<HdkR>
Something like that
<zmike>
dcbaker: likely going to do more backports tonight
<dcbaker>
zmike: okay, let me know when you’re done. I’m going to have to cut releases a bit early and do them tonight I think cuz I got a sick kiddo and won’t be working tomorrow
<zmike>
oh
<zmike>
😬
<zmike>
think I might have to eat some spurious ci fails then in order to avoid massive perf loss