<zmike>
had to eat some ci regressions, but I don't think they're going to show up anywhere else
<dcbaker>
zmike: most of those are also queued for 22.0, should I just denominate them and move on?
<zmike>
dcbaker: yeah I'd say don't worry about it
<zmike>
mostly focusing on 22.1 at this point
<dcbaker>
awesome, thanks
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<dcbaker>
@zmike, only 92 patches since rc5, do you think you could come up with 8 more :D
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<zmike>
dcbaker: hm
<zmike>
you could probably pick some of the llvmpipe ones if I missed those
<zmike>
also I hacked in some changes to one patch randomly that I could split out into another patch if you're really set on rounding off to an even 100 :P
sdutt has joined #dri-devel
<dcbaker>
I picked a couple, and I even tried harder by adding a couple of patches from jekstrand and dj-death
<zmike>
hmm
<zmike>
you could grab ajax's dri cleanup series
<zmike>
that's a solid no-op 6
<dcbaker>
lol
<zmike>
oh is my blitter patch in?
<zmike>
I forgot about that one
<zmike>
38ab178c4ad
<dcbaker>
auto nominated
<zmike>
alright, lemme actually look at everything you pulled in
<zmike>
yea grab that dri series I think
<zmike>
should be Very Safe
<zmike>
that gets you to 98
<zmike>
the version bump is 99
<dcbaker>
well first it looks like I've got a regression, so I might get to remove or pull a few things in
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
LexSfX has quit []
frankbinns2 has joined #dri-devel
frankbinns1 has quit [Read error: Connection reset by peer]
LexSfX has joined #dri-devel
stuart has joined #dri-devel
<dcbaker>
zmike: I've got a patch of yours that fails to build on the 22.0 branch, "f1d1371e51 gallivm/draw: fix oob ubo reads"
<dcbaker>
it applies fine, but there's some missing groundwork I didn't find on a quick check
<dcbaker>
not sure what you want to do about it
<zmike>
uhhhhh
<zmike>
I think that one is on top of another patch that's only in 22.1?
<zmike>
so maybe just drop that
<dcbaker>
btw, if you only want to send patches for 22.1 you can do `cc: 22.1 mesa-stable`
<dcbaker>
and the script will ignore them on the 22.0 branch
<zmike>
oh is that syntax live now?
<zmike>
🤔
<dcbaker>
or, maybe it's `cc: "22.1" mesa-stable`
<dcbaker>
nope, no quotes needed
<zmike>
I thought I did fixes tags on those ones
<dcbaker>
that's always worked with the CC code. I've been meaning to do a `backport: 22.1` and do away with the `cc: mesa-stable` stuff but it's never happened
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
tzimmermann has joined #dri-devel
ahajda has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
kurufu has quit [Remote host closed the connection]
kurufu has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
sdutt_ has joined #dri-devel
frieder has joined #dri-devel
JohnnyonF has quit [Read error: Connection reset by peer]
JohnnyonFlame has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
Daanct12 has joined #dri-devel
stuart has quit []
lemonzest has joined #dri-devel
tursulin has joined #dri-devel
icecream95 has joined #dri-devel
JohnnyonF has joined #dri-devel
Johnny has joined #dri-devel
danvet has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
JohnnyonF has quit [Ping timeout: 480 seconds]
Johnny has quit [Read error: Connection reset by peer]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
thellstrom has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
lynxeye has joined #dri-devel
eukara has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
cheako has quit [Quit: Connection closed for inactivity]
hansg has joined #dri-devel
JohnnyonFlame has quit [Read error: No route to host]
<hansg>
mlankhorst, I just tried your latest patch for the BYT rendering issue caused by "Remove short-term pins from execbuf, v6.". Unfortunately it does not work.
<hansg>
Unlike the last 2 days I'm available the entire day (CET) today to test things, so I thought I would jump on IRC and see if we can speedup the debug cycle a bit, by me being available for testing in realtime
jkrzyszt has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
RSpliet has joined #dri-devel
rpigott has quit [Remote host closed the connection]
rpigott has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
frankbinns2 has quit []
frankbinns has joined #dri-devel
RSpliet has quit [Quit: Bye bye man, bye bye]
RSpliet has joined #dri-devel
ella-0 has joined #dri-devel
pcercuei has joined #dri-devel
ella-0_ has quit [Read error: Connection reset by peer]
rasterman has joined #dri-devel
rkanwal has joined #dri-devel
eukara has joined #dri-devel
Daanct12 has quit [Quit: Leaving]
Daanct12 has joined #dri-devel
mvlad has joined #dri-devel
devilhorns has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
<mlankhorst>
hansg: if still there, new version. :)
Daanct12 has quit [Read error: Connection reset by peer]
<danvet>
hwentlan____, agd5f_ for the psr-su damage tracking comments, do you want me to reply on amdgfx or ok with just the irc thoughts I dropped a few days ago?
sdutt_ has quit [Ping timeout: 480 seconds]
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
<zzag>
emersion: while the compositor holds client buffer's dmabuf file descriptors, can the underlying buffer data be actually destroyed? I've noticed that chromium with native wayland support (chromium --enable-features=UseOzonePlatform --ozone-platform=wayland) is not animated as expected when it's closed, the animation abruptly stops...
<zzag>
Same in weston, chromium doesn't fade out but immediately disappears.
<emersion>
nope, it can't
<emersion>
that's a weston bug
<emersion>
iirc
<emersion>
a dmabuf is ref'counted, and a FD opened in the compositor is a ref
<emersion>
so is an EGLImage
<daniels>
yeah and we do animate those out if you configure it to
<zzag>
Huh, other closed windows that provide dmabuf buffers are animated as expected in weston
<daniels>
you're not using wl_shm rather than dmabuf, are you?
<emersion>
wasn't there an issue about weston_buffer being destroyed when the wl_buffer is?>
<zzag>
No, chromium provides dmabuf client buffers
<daniels>
we don't animate out wl_shm because wl_shm is hugely irritating, but that is fixable now
<daniels>
emersion: was, not anymore
<emersion>
ack
<zzag>
FTR, I do not work on chromium just trying to debug why it doesn't work as expected in kwin
<daniels>
(even then dmabuf/EGLImages got kept via elaborate behind-the-scenes hax)
<zzag>
daniels: emersion: chromium uses drmPrimeHandleToFD() though. I've tried to port relevant code to gbm_bo_get_fd_for_plane(), it didn't help..
<daniels>
zzag: that shouldn't be making any difference though - as emersion says, the compositor has a totally separate ref to the underlying storage
<emersion>
bad drmPrimeHandleToFD usage would just result in corrupted GEM handles in the chromium process
<daniels>
I'd probably just walk back to proto - is it doing something fun with subsurfaces such that no-one ever sees a single toplevel destruction to fade out? is it attaching a NULL buffer to the surface before destroying? etc
<zzag>
daniels: hmm, right, didn't pay attention to subsurfaces
<javierm>
jfalempe: feel free to ping me if you need any help with the workflow
heat has quit [Remote host closed the connection]
<jfalempe>
yes, I was already on this page ;)
<javierm>
jfalempe: great :)
ivyl has quit [Quit: end of flowers]
<tzimmermann>
jfalempe, don't worry. if you really accidentaly commit garbage (that's hard with dim) danvet can roll-back drm-misc trees for you.
<graphitemaster>
Shot in the dark, is anyone aware of glClearNamedBufferSubData crashes on AMD with a clear size of 1 (ubyte). I'm hitting a null-pointer dereference in the driver on that call with clear sizes of 1 only. Not actually mesa though, this is the Windows AMD drivers
<danvet>
we've had to do that once thus far in years of drm-misc
<danvet>
and I think once more in drm-intel <- jani or do I misremember?
<HdkR>
graphitemaster: Sounds like you hit a driver bug. Good job
<graphitemaster>
:(
FireBurn has joined #dri-devel
itoral has quit [Remote host closed the connection]
calebccff has quit [Remote host closed the connection]
calebccff_ has joined #dri-devel
<karolherbst>
airlied: rusticl on crocus, how much work would you expect? And what would be something I need to fix within rusticl?
whald has quit [Remote host closed the connection]
lumag_ has joined #dri-devel
flto has quit [Quit: Leaving]
<tzimmermann>
javierm, thanks for providing me with concrete examples.
<javierm>
tzimmermann: you are welcome. Probably I should add something like that in the commit message
<javierm>
tzimmermann: basically what we want to prevent is modprobe vc4 && modprobe simpledrm to create two /dev/dri/card{0,1}
<javierm>
the latter whould be a no-op instead
<javierm>
*should
<tzimmermann>
javierm, i'll go through it
<javierm>
tzimmermann: thanks a lot for looking at the patches
<javierm>
tzimmermann: don't you prefer for me to re-send with the different split that you asked ?
ivyl has joined #dri-devel
<tzimmermann>
javierm, maybe for the next iteration. with your explanation, i'll manage for now
<javierm>
tzimmermann: Ok, perfect
rkanwal has quit [Ping timeout: 480 seconds]
<danvet>
tzimmermann, javierm once more trying to catch up on mails, I've dropped some comments on the huge fbdev hotunplug discussion
<javierm>
danvet: thanks. And sorry that this thread deralied that much
<danvet>
oh from skimming at least I think it covers a lot of really tricky questions
<danvet>
and it's probably good if we keep them in mind and make sure we have a rough agreement on what the code ideally should look like
<javierm>
danvet: right. The tl;dr I think is that the issues are not easy to fix and would require a lot of work but probably makes sense to distill them and at least have them in Documentation/gpu/todo.rst
<jfalempe>
tzimmermann, my v2 of gamma for mgag200 is almost ready.
<jfalempe>
But if I remove the call to drm_mode_crtc_set_gamma_size(), then it doesn't work anymore.
sdutt has joined #dri-devel
<jfalempe>
I didn't find why, if it's in the kernel, or mutter looking for legacy interface.
<javierm>
danvet: I'll try to do that btw to make sure that are tracked. But are too big issues for me to tackle :)
<danvet>
javierm, yeah sounds like a great idea, thanks a lot
<danvet>
(documenting in todo.rst I mean)
heat has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
ella-0 has quit [Remote host closed the connection]
<emersion>
atomic gamma goes through the GAMMA_LUT_SIZE prop
<emersion>
which can be different
<ajax>
tzimmermann: hey, you pinged me the other day about some horrid g200se patch. i think i do remember the context for that patch, what was your question about it?
<tzimmermann>
emersion, indeed. but what do i know what gnome does ;)
<tzimmermann>
jfalempe, it would finally make this compatible
<tzimmermann>
jfalempe, you've discovered a bug :)
<tzimmermann>
jfalempe, that's maybe worth a separate patchset to fix all drivers. for now, you're welcome to leave the drm_mode_crtc_set_gamma_size() in mgag200
<tzimmermann>
maybe with an updated comment
<jfalempe>
ok, I will do that.
<tzimmermann>
ajax, my question is why this is for g200se only
<tzimmermann>
?
<tzimmermann>
what about all the other devices with 2 MiB ?
<tzimmermann>
and the test covers devices with 'less than 2MiB' . how little memory does the g200se actually have. even the old matrox cards from the mid-90s had 2 MiB at least
<ajax>
there's not a "the" g200se, sadly
<ajax>
there's a few models and the very very early ones had something like 1.75M of vram
<ajax>
but then jumped to 8M or more later on
<karolherbst>
jekstrand: what kind of intel hw do you have available?
<ajax>
so that patch only addresses g200se because that's the only extant thing i cared about, because nobody has a 2M actual G200
<jekstrand>
karolherbst: Tigerlake and Haswell
<ajax>
if you wanted to generalize it to all low-memory devices, go for it, but probably that's better done inside xserver?
<jekstrand>
And I suppose Skylake if I can get ksim to work. :joy:
hansg has quit [Quit: Leaving]
* jekstrand
waits for krh to show up suddenly.
<karolherbst>
jekstrand: mhhhh.. haswell is crocus, isn't it?
<jekstrand>
karolherbst: yes
<karolherbst>
do I have to ask or do you already know what I'd ask next? :P
<tzimmermann>
1.75 MiB. that's terrible
<karolherbst>
jokes aside, I think iris should be good to go across all gens as long as we keep fp64 disabled
<ajax>
(actually now i remember why i didn't do that as an xserver heuristic, i don't think the drivers tell us available vram early/consistently enough to let us make that kind of decision)
<karolherbst>
should try it out here on CMT-H
<ajax>
tzimmermann: rhel5 still had barely enough 8bpp support that it was "plenty", in their minds
<tzimmermann>
ajax, that code has been ported into the kernel meanwhile. i was working on mgag200 and found that change, which i tracked back into the x11 mga driver.
<ajax>
but then rhel6 dropped pseudocolor
<ajax>
and the IHV still wanted the same machine to be certified with rhel6
<ajax>
so
<tzimmermann>
i see
rexbcchen_ has joined #dri-devel
<tzimmermann>
thanks for giving me some context
<ajax>
but yeah, 1.7M made me spit my coffee out
<karolherbst>
jekstrand: but how do we file for conformance from a practical pov, everybody runs it on their machine with the hardware, or should one have all the hardware and test some gens? Not sure what we should be end up doing
<ajax>
they had to go out of their way to be that dumb
<ajax>
even then, you couldn't _source_ ram that small
<tzimmermann>
:)
<tzimmermann>
i'll keep all this in mind when working on the code
ella-0 has joined #dri-devel
<tzimmermann>
1.7 mib. i'm getting ptsd from that number. my first computer's graphics card was a trident 9000 with 512 kib of vram. it was total garbage, even back then
rxbcchen has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: running the full CTS (with the actual cts-runner) is the tricky part
<karolherbst>
nah, that's fine
<alyssa>
once you have a passing run with the current CTS version (I screwed that up), actually doing the submission is trivial
<alyssa>
at least for GLES, I assume CL is similar
<karolherbst>
sure, but I mean how do you run it against multiple harwdare?
<alyssa>
so multiple people doing independent submissions for respective hardware would be fine
<karolherbst>
you just collect the outputs and submit them in one go?
<alyssa>
I mean
<alyssa>
iris and llvmpipe are going to be separate submissions, first of all
<karolherbst>
ahh
<alyssa>
llvmpipe would be just one submission
<alyssa>
iris... I guess you have some flexibility there
<alyssa>
it looks like a single submission for hardware in the same family is acceptable
<alyssa>
the realistic answer is that conformance submission is boring and you probably don't care to submit for every random Intel platform ever :-p
<karolherbst>
yeah...
ella-0_ has joined #dri-devel
<krh>
jekstrand: you rang?
ella-0 has quit [Read error: Connection reset by peer]
<karolherbst>
jekstrand: api min_max_read_image_args fails on gen9
<karolherbst>
not sure if I messed up rebasing or not: test_api: ../src/gallium/drivers/iris/iris_program.c:946: iris_setup_binding_table: Assertion `bt->sizes[i] <= SURFACE_GROUP_MAX_ELEMENTS' failed.
<karolherbst>
something is up with int64 lowering as well
<karolherbst>
oh well..
<karolherbst>
let's see when I'll have time for that 🙃
stuart has joined #dri-devel
<jekstrand>
karolherbst: Let me see if I can find a SKL NUC cheap on EBay
neonking has quit [Remote host closed the connection]
<alyssa>
looks like gl_simpleaaclip_aaclip flaked?
neonking has joined #dri-devel
ella-0_ has quit [Remote host closed the connection]
mszyprow has quit [Ping timeout: 480 seconds]
<jekstrand>
alyssa: :(
sdutt has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<MrCooper>
"llvmpile", now there's a Freudian slip
<alyssa>
blink
* alyssa
scalarizes her IR
<karolherbst>
alyssa: you are still using vectors?
* karolherbst
has a bad plan on how to scalarize nir
<alyssa>
Scalarize NIR how
<alyssa>
I mean in the sense of ACO
<karolherbst>
vectors are just big types, no?
<alyssa>
Yeah... in effect, forbidding vec4 but allowing 128-bit scalars
<alyssa>
with SPLIT and COLLECT pseudoinstructions
<karolherbst>
or well.. 1024 for CL
<alyssa>
Woof
<karolherbst>
that would even help us, because our tex instructions just take multiple 128 bit sources :P
<karolherbst>
although I slowly come to the conclusion that on nv hw, we literally only have 128 bit registers
<alyssa>
heh, that's the case on Midgard
<alyssa>
AGX only has 16 bit registers
<karolherbst>
we still index them in a scalar way though
<karolherbst>
but you can only allocate multiple of 4 regs (which are 32 bit)
<alyssa>
I'm undecided about Bifrost. I think all 32-bit but I guess there's some debate.
<tzimmermann>
MrCooper: c64?
<karolherbst>
alyssa: my thinking is more like.. if we just go for "128 bit all the way" you wouldn't need split/collect
<karolherbst>
mhhh
<karolherbst>
I should stop thinking about terrible ideas
<MrCooper>
tzimmermann: that was numbers 2 & 3, the first one was a Canon MSX
<alyssa>
That's what we do for Midgard, it works ok because the machine is natively vec4 with a 128-bit data path
Duke`` has joined #dri-devel
<karolherbst>
alyssa: ahh
<alyssa>
It's a terrible idea for a scalar ISA though, since the top 96-bits are almost always wasted and your memory footprint bloats up
<karolherbst>
we don't have 96 bit ops
<alyssa>
(Depending on impl details)
<karolherbst>
ehh wait
<karolherbst>
that's not what I meant
eukara has quit [Remote host closed the connection]
<tzimmermann>
i've not even heard the msx :)
<alyssa>
what data structures would you use for liveness analysis? etc
<karolherbst>
you still assign to "vector components"
<karolherbst>
and use them as sources
eukara has joined #dri-devel
<karolherbst>
and RA fills up vecs in a packed way
<karolherbst>
alyssa: the bad thing is, at least for nvidia hardware the RA needs to be vector aware
<karolherbst>
even if it's a scalar ISA by nature
<karolherbst>
it is really annoying
<karolherbst>
it's also just one register file, so 32/64/128 bit sources share the same index
<MrCooper>
MrCooper: MSX was a home computer standard, many of the big Japanese manufacturers made machines conforming to it; MS stands for Microsoft BTW (the BIOS and BASIC interpreter in ROM was from Microsoft)
<MrCooper>
err tzimmermann ^
tango_ has quit [Ping timeout: 480 seconds]
tango_ has joined #dri-devel
sdutt has joined #dri-devel
tango_ is now known as Guest397
tango_ has joined #dri-devel
eukara has quit [Remote host closed the connection]
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
eukara has joined #dri-devel
<karolherbst>
mhhh
<karolherbst>
float rtn/rtp/rtz conversions to (u)long are failing
<karolherbst>
the other way around
eukara has quit []
<karolherbst>
mhh, same for clz and popcount
<karolherbst>
I bet something is wrong with the int64 lowering :)
<karolherbst>
" Failure for popcount( (cl_long) 0x8c7f0aac ) = *33 vs 16" mhh
Guest397 has quit [Ping timeout: 480 seconds]
maxzor has joined #dri-devel
<jekstrand>
karolherbst: Other way around. SKL has "real" int64. :)
<karolherbst>
ahhh
<karolherbst>
well
<karolherbst>
looks broken :P
<karolherbst>
I bet the code assumes 32 bit for some opcodes though
<jekstrand>
Sounds believable
frieder has quit [Remote host closed the connection]
lynxeye has quit [Quit: Leaving.]
ambasta[m] has joined #dri-devel
<jekstrand>
tarceri: I'll try to get back to the loop unrolling MR today if I can but I didn't sleep well last night so my brain isn't running at 100% and that's definitely an at least 90% brain MR. :)
i-garrison has quit [Remote host closed the connection]
<danvet>
robclark, airlied I still think at least the gitlab yaml should be put quite a bit higher under drivers/gpu/ci or drivers/gpu/drm/ci
i-garrison has joined #dri-devel
<danvet>
and then filters to arm the hw tests per driver or something like that
<danvet>
if every driver tree rolls their own for this we have an endless mess
<danvet>
but that's maybe a bikeshed for us to figure out, not drag greg&linus in with
<danvet>
it might also help with making a better case if it's sw/build/kunit testing for everyone + a set of drivers with hw ci integration
<danvet>
maybe drivers/gpu/drm/ci so it's still drowned in the driver updates in the diffstat :-)
apinheiro has quit [Ping timeout: 480 seconds]
AndrewR has quit [Ping timeout: 480 seconds]
AndrewR has joined #dri-devel
gio has quit []
gio has joined #dri-devel
<danvet>
tomeu, ^^ too I guess
FireBurn has quit [Ping timeout: 480 seconds]
jeeeun84 has quit []
mbrost has quit [Read error: Connection reset by peer]
maxzor has quit [Ping timeout: 480 seconds]
jeeeun84 has joined #dri-devel
nchery has joined #dri-devel
<robclark>
danvet: perhaps.. although the current thing still allows and even encourages re-use.. the toplevel yml file is just a tiny shim
<robclark>
(it encourages in the sense of if you re-use it you don't have to write piles of yml yourself.. which seems like a pretty big incentive)
<zackr>
tzimmermann: is it ok if i cherry-pick those three vmwgfx patches to drm-misc-next-fixes from drm-misc-next or do you want to merge drm-misc-fixes into drm-misc-next-fixes first?
rkanwal has quit [Ping timeout: 480 seconds]
<tzimmermann>
zackr, it's not my turn. either mripard or mlankhorst is on duty
<danvet>
robclark, yeah but I kinda thing most of that should be pulled into the kernel anyway
<danvet>
robclark, also I'm mildly worried that if we start littering the entire project with ci/ directories there's going to be a kneejerk reaction
<danvet>
so one ci/ directory for everything that's hosted on fd.o sounds like a better approach
<tzimmermann>
zackr, in principle -misc-fixes should be forwarded to -rc6 state and you could put your fixes into it
devilhorns has quit []
<robclark>
danvet: but I assume you still end up w/ a drm/$driver/ci directory for expectation files.. possibly the .rst doc should move to something a bit less driver specific (but there isn't really too much driver specific in it already)
<danvet>
robclark, I guess we could stuff them all into one
<danvet>
or just into the driver dir directly if it's the only thing really
* airlied
would like to keep ci files with the drivers if possible, though how to we deal with uprevs of the igt in ci? mega commits in next/fixes?
<robclark>
hmm, I suppose I kinda defaulted to "put those in driver specific location" since that is how we do it for mesa and it works well there.. (the separate locations I think also helps with the rules about what CI jobs to run given which files changed)
<robclark>
airlied: the toplevel yml file should be (and will be in next rev of RFC) pointing at an explicit revision of drm-ci .. which in turn points at explicit revision of igt
<robclark>
I guess if we have same igt version for all drivers, then it would be a bit of a mega-commit
<robclark>
if we keep igt version per-driver, that seems a bit more manageable..
<airlied>
robclark: so when it pokes at the CI system, it will run the specific revision of the drm-ci per driver?
<airlied>
like I push drm-next and it will build, but then run separate revisions on each hw platform?
<airlied>
tomeu: ^?
<robclark>
I *think* so.. or hmm, I guess it depends on which gitlab tree is running the CI.. because that is where you configure where to pull the toplevel gitlab-ci.yml
<robclark>
we will anyways need separate builds for x86 vs arm.. it seems like separate builds per driver would make merging things thru per-driver next trees easier.. ie. I don't think we should try and use a single common version until all of drm-next is gitlab MR's in a single tree :-P
<zackr>
tzimmermann: got ya. thank you
<airlied>
robclark: ideally I'd like to be able to push drm-next without MRs and validate the in-tree CI results pass
<zackr>
mripard, mlankhorst: are you ok with me fast-forwarding drm-misc-next-fixes to rc6 and adding three small vmwgfx fixes or do you want to fast-forward yourself?
<danvet>
airlied, I'm also thinking of stuff like selftests and build tests
<airlied>
with a single toplevel gitlab-ci.yml
<danvet>
which would be really good to standardize across every driver
<danvet>
hw tests per-driver is the way to go ofc
<danvet>
but even there maybe we get to a point where we can run hw tests for core drm changes too
* danvet
can dream
<danvet>
airlied, yeah essentially top level gitlab-ci.yml for drm
<danvet>
that's the key piece, the other bits we can bikeshed around
<robclark>
airlied, tomeu: yeah maybe running the same thing in drm-next as in msm-next is a good argument for having drm/ci/gitlab-ci.yml instead.. but I think it is not going to be uncommon to need a scheme where we have a branch with a patch or two outside of drm which is required (since -next is usually branched off an early -rc)
* airlied
just feels it would be a conflict nightmare in-tree
<danvet>
meaning, as long as there's not too much copypaste between drivers doing the same stuff, I don't really care strongly one way or another
<danvet>
robclark, yeah but -next should then also keep the same frozen igt sha1 and test list and all that?
<danvet>
and if you then send in an msm update, you'd update the msm expectations
<robclark>
hmm
<danvet>
and it /should/ all keep fitting
<danvet>
and the top-level ci has the usual filters to only run msm hw tests when you guys think it's relevant
<danvet>
and since that hopefully matches the diffstat of the merge commit, it should all fire when the msm pull is integrated into drm-next
<robclark>
airlied: yeah, maybe the thing to do is, if we are going to do an igt uprev, do it immediately after drm-next branches, and before other drivers branch off of drm-next.. and then keep it stable over the release cycle
<danvet>
so if there's breakage in helpers/core it should show up
<danvet>
robclark, drm-misc and drm-intel don't base upon drm-next, they just keep floating
<danvet>
I think amd is similar-ish (at least the internal tree)
<robclark>
backmerge?
<danvet>
yeah, pretty much backmerges only
<danvet>
but upreving igt to latest every time we open drm-next sounds like a good idea
<robclark>
yeah, I think if we have single igt version for all drivers, we pretty much have to do it that way
<danvet>
flip side of this is also that igt should probably test against the latest kernel release to make sure it keeps working well enough
<danvet>
robclark, oh I was still thinking per-driver overwrite for at least the hw tests
<robclark>
fwiw, tomeu does have some patches to add gitlab ci job for igt itself ;-)
<danvet>
but stuff like vkms or anything else that's pure sw would upgrade in lockstep
<danvet>
anything else = maybe llvmpipe + virgl or so in a pure vm setup
<danvet>
as long as you only run kms tests that should be ok-ish
<danvet>
or very basic igt
<robclark>
hmm, I think vm or hw is kinda orthogonal to the question of per-driver igt version or not..
<danvet>
robclark, yeah maybe external dependencies matter more
<danvet>
but my reasoning here is that pure virtual you should be able to debug, so we could try to make sure it really always works
<danvet>
vs hw testing can go boom in funny ways, so if you want to uprev igt it might need some hw access or similar
<robclark>
oh, sure.. but I guess no one has ever debugged $other_hw via gitlab ci in mesa ;-)
<danvet>
also maybe igt eventually becomes solid enough so that this is much less a problem
<danvet>
robclark, sure you can do, I just mean it's getting more annoying
<danvet>
plenty of people use intel-gfx-ci the same way to debug stuff on hw they don't have
* karolherbst
wants to abuse intel-gfx-ci to run the CL CTS
<danvet>
but eventually you should bite the bullet and stop wasting a few weeks of machine time every time you move your printk around :-)
<karolherbst>
:P
<danvet>
karolherbst, we run piglit
<karolherbst>
meh
<danvet>
it just almost never breaks, so the results aren't even listed if you don't go digging real hard
<karolherbst>
I should probably fix the broken CL tests in piglit
<danvet>
I think we also at least planned to run crucible
<robclark>
danvet: yeah, after a couple tries you ping someone who works on the driver to beg for help ;-)
<danvet>
the thing is, imo running cts for userspace for kernel ci is massively wasted machine time if you don't bother to at least focus it somewhat on hw testing
<danvet>
like blowing through intel-gfx-ci time to run compiler unit tests is a bit silly
<danvet>
robclark, :-)
<robclark>
(I do want to run deqp.. but heavily cut down, not a full run)
<danvet>
robclark, yeah there's definitely some value in that to make sure render engine state doesn't get thrashed or some w/a or clock gating bit fell off and now some oddball sampler mode is busted
<danvet>
hence why we run piglit and like to add a few more of these
<robclark>
yeah, it could be piglit instead of deqp, although I think deqp generally does better result validation.. I don't have a strong preference, just want some sanity testing
<robclark>
and it is a bit much to construct cmdstream to get 3d pipe and shader core going in igt
LexSfX has quit []
tzimmermann has quit [Quit: Leaving]
<danvet>
robclark, yeah we only have a very basic one to do copy operations on the render engine
<danvet>
helps with some kernel validation, but very much _not_ mean to validate the render engine works correctly
<danvet>
and yeah if deqp has a nice test list for hw testing maybe we could switch to that in intel-gfx-ci too
<danvet>
or both
* danvet
dunno
LexSfX has joined #dri-devel
<robclark>
was kinda just thinking a fractional run (like 1 out of 10) of dEQP-GLES3 or something along those lines
eukara has joined #dri-devel
jhli has quit [Remote host closed the connection]
jhli has joined #dri-devel
<danvet>
robclark, hm yeah maybe, as long as your fraction is stable
<danvet>
I guess hash the testname
AndrewR has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
<alyssa>
danvet: I don't have a horse in the race, but my kneejerk preference is for dEQP over Piglit, given our experiences with the stability of each in Mesa CI
<robclark>
danvet: we could also manually generate a fractional test list.. ofc there is the same issue as with igt that the test names *could* change across deqp/piglit/whatever uprev.. but that could be handled the same way (ie. kernel commit that updates commit sha of drm-ci tree in sync w/ updating test list and expectations)
<alyssa>
robclark: I also think the subset depends strongly on the hardware
<alyssa>
for (current and old) Mali, the kernel interface is extremely thin. just pass a pointer from userspace and go.
<alyssa>
There's really not much for the kernel to screw up. If kmscube works and a deqp test doesn't, 99.9% chance it's a mesa bug, not a kernel one
AndrewR has joined #dri-devel
<alyssa>
compare with PowerVR (and Apple by extension), where the kernel knows all sorts of gross details about depth/stencil attachments, occlusion queries, etc
<alyssa>
suddenly getting specific coverage for those areas is critical
<alyssa>
[I would like to reaffirm my belief that having the kernel know about graphics state is batshit.]
<danvet>
+1
<danvet>
like wtf who designed that
<robclark>
I could see what (and if) other drivers want to run deqp as being driver specific.. for msm we do have some igt tests that exercise the CP but that doesn't mean that (for ex) we actually managed to power up other parts of the gpu
<robclark>
and doing enough cmdstream building in igt to validate that means *tons* of gen specific code
rkanwal has joined #dri-devel
* Lyude
is somewhat thankful it's really easy to do cmdstreams for nouveau from igt
<Lyude>
(we have to do this for clearing memory (which will likely be handled by the kernel eventually), and blitting between different image formats
rexbcchen has quit [Read error: Connection reset by peer]
rexbcchen has joined #dri-devel
<karolherbst>
nice
<karolherbst>
we have a fix for the half types in llvm :)
<karolherbst>
so we really only need to figure out what to do with the defined extensions
<karolherbst>
jenatali: there are plans to drop support for those opencl headers, and I think we should try to move over with llvm-15 (I have patches), but it would be good if you could verify that things will work for you as well. I'll submit an MR with all relevant clc changes for that soonish
<karolherbst>
but I'll wait until the patch made it into the tree
<karolherbst>
ehh.. the patch fixing vload/vstore for halfs
<ajax>
like why the kernel would know about framebuffer attachments
<heat>
is this legit? Am I dreaming?
* karolherbst
stops working for the day and deal with discussion on IRC
<emersion>
alyssa: one step at a time
<alyssa>
ajax: hey AGX wants that too! :p
<alyssa>
or at least macOS does, not sure
<karolherbst>
heat: yep, it is
<karolherbst>
(or at least I think so)
<airlied>
emersion: where did you get that url? seems to 404 here
<emersion>
airlied: in the nvidia.com link below
<emersion>
yeah it 404s right now
<karolherbst>
oh no :(
<emersion>
maybe they haven't pushed the "make public" button just yet
<karolherbst>
not here
<karolherbst>
well
<karolherbst>
it still works for me
<emersion>
"still"?
<karolherbst>
ohh you mean the github?
<emersion>
yes
<karolherbst>
I thought you meant the download
<emersion>
oh i don't really care about binaries
<karolherbst>
airlied: the URL is on the download page
<karolherbst>
"Published the source code to a variant of the NVIDIA Linux kernel modules dual-licensed as MIT/GPLv2. The source is available here: https://github.com/NVIDIA/open-gpu-kernel-modules"
<heat>
is it going to be useful?
<heat>
I've noticed they're not publishing the userspace part
<karolherbst>
yeah... not sure yet
<karolherbst>
I downloaded the archive to check if there is anything useful in it
<emersion>
if it has KMS in it, it'd be pretty cool
<danvet>
hm phoronix doesn't have an article ready
<emersion>
oh so the interesting stuff is in kernel-open/nvidia-drm it seems
<airlied>
that is old stuff
<airlied>
been open for ages
<airlied>
interesting stuff is in src
mbrost has quit [Read error: Connection reset by peer]
<karolherbst>
yeah
<karolherbst>
ignore everything besides src/
<emersion>
was it
<emersion>
ah
<karolherbst>
yeah
<karolherbst>
they needed some glue code to compile :P
<emersion>
damn
<heat>
emersion, dkms already builds that if you're using it
<emersion>
sorry, i haven't messed around with the proprietary driver too much
lemonzest has quit [Quit: WeeChat 3.4]
<danvet>
I'm just realizing how much amd's DAL was actually written for linux, because I'm pretty much completely lost on this thing :-)
<karolherbst>
:)
<karolherbst>
I love how they read sysfs files to get around GPL restirctions
<danvet>
orly?
<karolherbst>
sure
<airlied>
danvet: so they have nvidia-modeset which is their modesetting interface to their X driver
<karolherbst>
danvet: for runtime pm and stuff
<danvet>
I mean no longer needed, but hilarious if that stuff is still in there
<airlied>
then they have the drm driver which in theory does drm modesetting
<airlied>
but I think on top of the same core
<danvet>
airlied, yeah I guess that
<danvet>
but since its a 100% hal I'm lost at connecting with the backend code in src/
<danvet>
I guess when you're familiar with nv concepts it's a lot easier to find stuff
<airlied>
no it really isn't
<karolherbst>
the code isn't great :)
<danvet>
well it's still wading through vendor lasagna most likely
<danvet>
but at least you know a bit what stuff is about
<danvet>
I can't even tell what stuff is
<alyssa>
src/ feels like a windows driver
<airlied>
alyssa: ding ding :-P
<karolherbst>
alyssa: I'll ask a question and you answer it yourself: do you think any of this code is _new_?
<karolherbst>
:P
<alyssa>
karolherbst: :D
<emersion>
they say it in their README
<emersion>
"Though the kernel modules in the two flavors are different, they are based on the same underlying source code"
<graphitemaster>
Does anyone know of a *clever* way one can determine if a GPU is an iGPU or dGPU from just regular GL alone, like maybe some weird mapped buffer trick?
<graphitemaster>
Like some .. side channel observable behavior
<alyssa>
karolherbst: "NvU32"
<ajax>
graphitemaster: probably there's a way to coerce MapBuffer to give you a pointer into definitely vram not host ram? and you could time how fast readback is from that and guess whether it's uncached or other side of pcie from that
<alyssa>
"Nouveau can leverage the same firmware used by the NVIDIA driver, exposing many GPU functionalities, such as clock management and thermal management, bringing new features to the in-tree Nouveau driver"
<ajax>
however: by the time you're doing that i feel like it's easier to just build a pattern match for GL_RENDERER and/or whichever egl/glx extension
<airlied>
alyssa: turing+ reclocking should be solvable
<airlied>
leaves a bit of a gap in the support matrix
<alyssa>
airlied: ...Wait no i have 2 other drivers to finish first ;p
<ajax>
alyssa: my understanding is they've wanted to move reclocking control to the device side anyway
<karolherbst>
alyssa: yep
<danvet>
ajax, except igpu also can give you wc
<danvet>
like most actually do I think
<ajax>
danvet: sure, it's more does this latency feel like a pcie bus or not
<ajax>
if it's too fast then no
<danvet>
ah yes, that might work
<danvet>
either that or gen2 intel igpu :-P
<karolherbst>
alyssa: well, the firmware loading part is taken care of already anyway
<graphitemaster>
ajax, Anything more robust than that, I really only need this behavior for AMD cards. Maybe there's some inherent arch choices on mobile vs desktop that are observable as a side channel.
<danvet>
graphitemaster, on intel igpu is on a special pci bus:dev.fn
alyssa has left #dri-devel [#dri-devel]
<danvet>
and I think you can clean that from the mesa extension?
<danvet>
not sure it's the same on amd
<ajax>
graphitemaster: are you allowed to assume GLX_MESA_query_renderer because its "unified memory" bit seems like what you're after
<ajax>
or do people do fglrx on igp still
agd5f_ has quit []
agd5f has joined #dri-devel
<graphitemaster>
Need something that works on Windows too
<agd5f>
PCI ids?
<graphitemaster>
Can you fetch those from GL
<graphitemaster>
I didn't know if there was an extension or not
<ajax>
probably not on windows
konstantin has joined #dri-devel
<ajax>
what decision are you making based on this knowledge?
<graphitemaster>
None, it's just for telemetry purposes.
<karolherbst>
we missed the phoronix article from 20 minutes ago
anonymus1234 has joined #dri-devel
<danvet>
geez phoronix was asleep, apparently some embargo and it didn't go out right when nvidia published
* karolherbst
wonders if he should start trolling or not
* danvet
severely disappointed
<karolherbst>
danvet: I wouldn't be surprised if he didn't know
<danvet>
karolherbst, do it
<danvet>
karolherbst, says in the article the embargo lifted
<karolherbst>
ahhh
<ajax>
graphitemaster: i think collecting GL_RENDERER strings will get you that info as a side effect, product ids tend to be different for igp vs discrete
<danvet>
and it's a bit much text for usual furious breaking news typing
heat has quit [Read error: Connection reset by peer]
<karolherbst>
right...
heat has joined #dri-devel
<danvet>
I guess now it's time to start the lwn timer
<graphitemaster>
ajax, not on AMD >_>
gawin has joined #dri-devel
<graphitemaster>
AMD in their infinite fucking wisdom decided to make laptop GPUs with the exact names as their discrete GPUs
<graphitemaster>
NV did the same but you can determine the difference easily
<graphitemaster>
Anyways sorry for asking, the NV news is more exciting
<graphitemaster>
Whoo OPEN SOURCE KMD LETS GO </hype>
maxzor has joined #dri-devel
<karolherbst>
🎉🎉🎉
ella-0 has joined #dri-devel
<agd5f>
graphitemaster, I don't think any of the APU marketing names overlap with dGPU marketing names.
<karolherbst>
marketing names are all random, there is no sense behind it :P
<graphitemaster>
The naming scheme is horrible for all vendors, everyone should be fired.
<bnieuwenhuizen>
doesn't one of the EGL extensions tell you if it is an iGPU?
<Venemo>
graphitemaster: are you trying to determine laptop vs desktop or iGPU vs dGPU?
<bnieuwenhuizen>
err, GLX_MESA_query_renderer
<graphitemaster>
iGPU vs dGPU, I can already determine laptop vs desktop based on the existence of a battery
<graphitemaster>
I cannot tell if an AMD GPU is some APU thing or a dGPU though even based on the model name
<graphitemaster>
Since they report similarly in their Windows driver as just "Radeon Graphics"
<graphitemaster>
No model name in sight
<Venemo>
Can't you query the size of dedicated VRAM?
<graphitemaster>
It's kind of absurd, their windows driver just reports "AMD Radeon(TM) Graphics" for GL_RENDERER for like 8 different dGPUs and iGPUs
<graphitemaster>
No way to distinguish anything, not even model.
<graphitemaster>
So that's a separate problem now
<karolherbst>
graphitemaster: best bet is to check for d3cold runpm support :P
<karolherbst>
like if you got the firmware stuff wire up and all
<karolherbst>
because desktop gPUs don't have this, and I hope all laptops do
<karolherbst>
ohh wait.. it's iGPU vs dGPU
<bnieuwenhuizen>
karolherbst: iGPUs don't
<karolherbst>
ehh.. firmware buffer
<karolherbst>
but yeah.. I think all vendors suck on that
<Mis012[m]>
well, ideally you would check for the thing that makes you need to distinguish between iGPU and dGPU? :P
<Venemo>
karolherbst: why'd NV publish their own out of tree driver when they could have contributed to nouveau instead?
<Mis012[m]>
Venemo: so naive...
<Venemo>
Just curious
Haaninjo has joined #dri-devel
<agd5f>
Venemo, they have a working driver that works with CUDA today. making that happen with nouveau would take years?
<graphitemaster>
No no, nouveau will have reclocking for newer NV GPUs now in the next hour right, because that's how all this works, it's so easy, just press a button /s
sadlerap has joined #dri-devel
<Mis012[m]>
graphitemaster: actually, in a sane design, there wouldn't be any PCI(e) glue for the iGPU, but nevermind :P
<Venemo>
Hm
mvlad has quit [Remote host closed the connection]
<Venemo>
So it's easier to write this new driver from scratch than to add what was missing from nouveau?
<karolherbst>
Venemo: .... wellll....
<graphitemaster>
In a sane design OpenGL would have core features for querying something as basic as if a GPU is integrated or not, in addition to pcie vendor ids and what not.
<karolherbst>
now we have source code?
<agd5f>
Venemo, I think they just snapshot their existing driver for the most part
<karolherbst>
Venemo: I think it was easier this way
<emersion>
Venemo: it's not from scratch
<karolherbst>
they can just dump their code into the public
ella-0[m] has joined #dri-devel
<karolherbst>
and people can use it and fix nouveau
<agd5f>
graphitemaster, why do you need to know in the first place? doesn't seem relevant for OpenGL
<Venemo>
Huh, I thought they couldn't do that due to patents and stuff
<karolherbst>
we do get occasional contributions from nvidia people though
<karolherbst>
Venemo: well that stuff lives inside the firmware
<graphitemaster>
so it's not just some snapshot, it's also some other stuff they strip out or generate from description files they're not sharing, or some other programming language even
<Mis012[m]>
graphitemaster: how dare you impose pci vendor ids when sane iGPUs are not on a glue PCI bus :P
Duke`` has quit [Ping timeout: 480 seconds]
<Venemo>
Reading that blog post from the above link.
<graphitemaster>
The generated code just looks like someone whoo really badly wanted virtual methods in C but C did not have them so they wrote a tool to generate it instead
<Venemo>
Does RH really think they are "the only Linux vendor with the capacity to do so"?
<karolherbst>
Venemo: do you see others doing it?
<karolherbst>
well.. google I guess would be the only other one capable
<Venemo>
karolherbst: Valve?
<karolherbst>
not on this scale
<Sachiel>
they also talk about compute
<karolherbst>
yeah
<karolherbst>
compute > graphics
<karolherbst>
we'll get there eventually :D
<karolherbst>
(I hope)
<karolherbst>
ohh shit, do I have to say that rusticl has nothing to do with it, or won't people believe me anyway?
<bnieuwenhuizen>
also sounds like the requirement for Turing was due to that having an embedded processor they could move all the secret stuff to
<karolherbst>
bnieuwenhuizen: correct
<karolherbst>
well
<karolherbst>
the processors existed before already
<karolherbst>
but with turing it can live on the one big one
<Venemo>
The article specifically says this in context of creating a Vulkan driver
<bnieuwenhuizen>
yes, so who is bootstrappinjg the Vulkan driver? :P
<karolherbst>
we do :D
<Venemo>
All due respect to RH but they are not the only people capable of developing a Vulkan driver
<karolherbst>
Venemo: they are not, that's correct
<bnieuwenhuizen>
they didn't say that?
<Venemo>
It does say that
<karolherbst>
well.. if somebody wants to start writing a vulkan driver, they can just do so :P
<Venemo>
We already do
<karolherbst>
but they could have done it before any of this regardless
<karolherbst>
good luck with that then
<Venemo>
Well, I'd call RADV a successful driver, at leaat
<karolherbst>
yeah, and that was started by RH
konstantin has quit [Remote host closed the connection]
<karolherbst>
or not?
<bnieuwenhuizen>
it was, Dave and me
<karolherbst>
:)
<bnieuwenhuizen>
+ a whole lot of stuff from Intel ;)
<karolherbst>
right
<karolherbst>
I'll assume there will be some vulkan driver sooner or later :D
<Venemo>
I think it's pretty arrogant to say that RADV was made by RH
<karolherbst>
I didn't say that, I'd say it got started by it
<airlied>
RH has started the most vulkan drivers :-P
<airlied>
actually Collabora might be even
<airlied>
or has taken the lead, I should recount
<karolherbst>
yeah.. I think collabora caught up
<bnieuwenhuizen>
airlied: which ones did RH do? RADV + ?
<karolherbst>
in the end we as the community made those drivers
<airlied>
bnieuwenhuizen: lavapipe :-)
<karolherbst>
but it's always about who started it, because if nobody does, others might just rely on vendor drivers
<karolherbst>
maybe amdvlk would have beend the one everybody uses if airlied wouldn't have started radv with others, who knows
<Venemo>
RADV has one contributor from RH, and several from Valve so I think it's unfair to talk about it without acknowledging Valve. That's all I'm saying
<karolherbst>
(I don't think so, but...)
<bnieuwenhuizen>
really happy though that nouveau isn't this dreadful place of "we can't do anything interesting anyway" anymore
<karolherbst>
doesn't help if you are the only one and there are like 100 things falling apart left and right :)
<bnieuwenhuizen>
karolherbst: you're the one that stuck around anyway :P
<graphitemaster>
lovely url
<karolherbst>
bnieuwenhuizen: yeah..........
<karolherbst>
didn't do a great job though
<bnieuwenhuizen>
anyway, can I recommend a Vulkan driver + zink instead of yet another gallium driver?
<jekstrand>
Yeah, the GL driver leaves something to be desired but if we can run the GPUs at full clocks, that's going to motivate more people to make it work.
* karolherbst
should fix multithreading
* karolherbst
is saying this for years
<Venemo>
Exactly
<karolherbst>
bnieuwenhuizen: yes, that's my ideal solution
<bnieuwenhuizen>
might as well if we consider nouveau in need of a significant rewrite
<karolherbst>
we could even do vulkan on nv50 if we really wanted to
<graphitemaster>
karolherbst, honestly think it's better to focus on the vulkan driver and just let zink do GL :P
<bnieuwenhuizen>
and with imagination in there is some pressure to make that actually work well
<karolherbst>
graphitemaster: I just focus on CL :D
<jekstrand>
Regardless of whether there's a nouveau rewrite on the table, we should build Vulkan first.
<karolherbst>
yes
<karolherbst>
and fixing multithreading is mostly done
<karolherbst>
so that's fine
<Venemo>
do they also have any info about their ISA and other stuff?
<karolherbst>
the driver does work somewhat
<jekstrand>
Once we brought up ANV, Kayden was able to write iris by himself re-using all the pieces we built for ANV.
<karolherbst>
it's just not very stable
<graphitemaster>
Vulkan is the easiest path to getting GL and D3D12 on Linux with nouveau + NV kmd
<jekstrand>
Vulkan encourages you to do things in a better way if you actually care to do so.
<karolherbst>
Venemo: well.. I do
<jekstrand>
Then you re-use for GL.
<Venemo>
karolherbst: a reverse engineered one or do you actually have an official one?
<karolherbst>
jekstrand: yes, and I think if we keep this in mind, it should make it easy to write a new driver
<karolherbst>
Venemo: I have one I didn't reverse engineered :D
<Venemo>
I assume under NDA
<karolherbst>
correct
<bnieuwenhuizen>
up to where do the reverse engineered ones go?
<karolherbst>
it doesn't contain encoding though
<karolherbst>
but who cares about encoding
<bnieuwenhuizen>
did that ever go beyond maxwell?
<karolherbst>
bnieuwenhuizen: we do support ampere, more or less
<karolherbst>
it just misses firmware
<karolherbst>
ampere has the same ISA as volta+
<karolherbst>
we still need to figure out encodings, but the doc explain the instructions, which is nice
<bnieuwenhuizen>
so the ingredients are actually there if someone from the community wanted to start
<karolherbst>
ohh totall
<karolherbst>
but it was already there 3 years ago
<karolherbst>
(we do have a vulkan driver, it's just not finished and not public) :D
<Venemo>
karolherbst: so you're allowed to create open source software based on that doc, but you're not allowed to share the doc?
<karolherbst>
Venemo: correct
<Venemo>
I see
<karolherbst>
the source code drop really only solves the performance part
<bnieuwenhuizen>
karolherbst: but without hope to be useful it is pretty hard to start one
<karolherbst>
nothing else
<jekstrand>
karolherbst: If you figure out how to get my 2060 working (or tell me what other GPU to buy), I can help. :P
<karolherbst>
sure, performance matters the most
<karolherbst>
but....
<karolherbst>
what I am saying, we knew this was coming
<karolherbst>
if I wouldn't have known it, maybe I would have left, dunno
<karolherbst>
jekstrand: welll... the code is out there :P
<karolherbst>
:D
<karolherbst>
jekstrand: anyway.... I'd wait a little longer
<Venemo>
Turing is the 20xx series right?
<jekstrand>
karolherbst: Vulkan driver code?
<karolherbst>
there will be code making use of the new firmware, and there are some patches from Ben rewriting the host bits
<karolherbst>
jekstrand: everything
<jekstrand>
karolherbst: links?
<karolherbst>
jekstrand: that's the annoying part, Ben doesn't like to share shit if Ben thinks it's not ready :(
<karolherbst>
tease him :P
<karolherbst>
I am just failing at this
<karolherbst>
I already told him, that others will write a vulkan driver if he doesn't push :D
<graphitemaster>
Ah yes the infamous open-but-not-actually Vulkan driver that exists-but-doesnt that I keep hearing about
<karolherbst>
yeah...................
<bnieuwenhuizen>
so do we create a MR with skeleton just to provoke someone into pushing?
<karolherbst>
sounds like a plan
<karolherbst>
I have something alreayd :D
<karolherbst>
let me find it
anarsoul|2 has quit []
anarsoul has joined #dri-devel
<daniels>
karolherbst: you just can't trust Australians
<anarsoul>
Venemo: and 1650
<anarsoul>
karolherbst: does it mean that nouveau will eventually get reclocking support?
<graphitemaster>
This is all exciting news for graphics on Linux but I think I understand NV's strategy this time. In the past the concern was that they didn't want to give people their software. Now their new strategy is to give the software but make it impossible to get their hardware. It's quite brilliant. We can have an open sores NV platform but no one on earth can get their hands on a RTX GPU XD
iive has joined #dri-devel
<Venemo>
graphitemaster: wow, you figured it out
<zf>
it's going to be called nouveaulkan, right?
<karolherbst>
zf: of course
<zf>
:-)
<zf>
that's the only thing I care about
<karolherbst>
or mayube nouveaolcan?
<karolherbst>
it's closer to french
<bnieuwenhuizen>
novk
<zf>
nouveaulcain?
<karolherbst>
nok
<jekstrand>
nvk
<jekstrand>
3 letters are better than 4
<Venemo>
is it also time for an NCO?
<jekstrand>
Venemo: Thinking of starting on it. :)
<karolherbst>
let's take a new approach to writing a vulkan driver, everybody writes each N line and we put it alltogether and submit an MR
<bnieuwenhuizen>
yeas, the extra letter in radv resulted in so much overhead :(
<karolherbst>
Venemo: yeah.... a new compiler would be nice :D
<Venemo>
:)
<karolherbst>
so if somebody doesn't have anything better to do :D
<jekstrand>
Still, rand_u64() & 0xfffffffff000 ought to be pretty unlikely to collide.
<graphitemaster>
happy
<jekstrand>
(assuming a 48-bit address space)
<karolherbst>
graphitemaster: GPU is only 48 bits :P
<graphitemaster>
I still think statistically less likely to collide than any other random bug in the driver even for 48 bit address space
<karolherbst>
mhhh maybe
<jekstrand>
Or, you know, we can use src/util/vma_heap.h
<graphitemaster>
I bet vma_heap is slower than xorshift128
<karolherbst>
jekstrand: please do
sdutt has quit [Ping timeout: 480 seconds]
<karolherbst>
I am tired of having "nouveau only libs" for stupid reasons
<jekstrand>
I briefly tried to move the AMD drivers to util/vma_heap but theirs was pretty embedded into places.
<jekstrand>
But anything built today should use it unless there's a good reason to do otherwise.
<bnieuwenhuizen>
?
<karolherbst>
yeah....
<bnieuwenhuizen>
it isn't that embedded into radv no?
<karolherbst>
that's always the shitty thing about doing proper reworks on nouveau
<karolherbst>
you start looking
<jekstrand>
bnieuwenhuizen: It's embedded in the winsys stuff
<jekstrand>
And I didn't feel like ripping it out.
<karolherbst>
after 2 hours you give up, because writing from scratch takes less time
<bnieuwenhuizen>
though I guess I have to kill libdrm_amdgpu due to the shader drm fd
<karolherbst>
and solves the other 50 issues at the same time
<jekstrand>
karolherbst: I based it on the AMD one, I just didn't want to take the time in a driver I don't know well to make AMD use the shared one.
<karolherbst>
I am sure it's not better with nouveau
<karolherbst>
anyway...
<karolherbst>
we should have a proper vulkan driver :)
<jekstrand>
Looks like it's now being used in itnaviv, virgil, iris, pvr, and ANV.
<jekstrand>
karolherbst: Yes, we should. :)
<graphitemaster>
Just leak the one-that-exists-but-doesnt-actually-yet open-but-not-open exists-but-does-not-exist one smh
<karolherbst>
and I am sure I won't be useful on that besides compiler stuff, because people will move _fast_ :D but I also relied to much on others doing it anyway, so, that's fine :P
AndrewR has quit [Ping timeout: 480 seconds]
<bnieuwenhuizen>
jekstrand: did you mean vma.h?
<jekstrand>
bnieuwenhuizen: yes
<haagch>
is the time right for vulkan-only + zink or will it be worth it to write an opengl driver / rewrite nouveau?
<Venemo>
haagch: I think it's never been a better time for that
<karolherbst>
haagch: I'd start with zink honestly
<karolherbst>
the gl driver is in a really bad shape overall
<karolherbst>
I think rewriting it is the only sane solution
<karolherbst>
I'd still fix multithreading in a non breaking way, because that's so important to get fixed, but besides that?
<bnieuwenhuizen>
so is your plan rusticl on top of zink?
<karolherbst>
all I can think of "ehhh.. we want a new one anyway"
<Venemo>
esp. considering that the HW vendor isn't contributing to it, it's better for the community to focus all effort on the VK driver
<karolherbst>
bnieuwenhuizen: I suspect, or I'll change code around to target vulkan directly
<karolherbst>
thing is... what would zink offer here besides doing some vulkan abstraction?
<karolherbst>
we have to pass the original spir-v in
<bnieuwenhuizen>
I hear anv can already ingest CL SPIRV internally
<karolherbst>
otherwise it's a huge mess
<karolherbst>
yeah..
<karolherbst>
so we'd come up witha vulkan ext to just read CL spir-v
<karolherbst>
and I think that's it?
<karolherbst>
I've heard there is an ext for real buffers
<bnieuwenhuizen>
also have to set the kernel args
<Sachiel>
but you'd miss on the fun of having extra layers to debug
<karolherbst>
bnieuwenhuizen: that's boring stuff
<karolherbst>
it's literally an ubo
<bnieuwenhuizen>
VK_KHR_buffer_device_address yeah, though it isn't quite as flexible as CL wrt random casts AFAIU
<karolherbst>
yeah.. no idea how much we need at runtime
<karolherbst>
CL has image2d from buffer support e.g.
<karolherbst>
and this can be painful
<karolherbst>
and other random stuff
<karolherbst>
but...
<karolherbst>
I know that I don't really need much on top of GL gallium
<bnieuwenhuizen>
can you require some alignment on the image2d from buffer stuff?
<karolherbst>
yes
<karolherbst>
strides are explicit
<karolherbst>
and the API reports min alignment of the stride _and_ base addr
<bnieuwenhuizen>
then I think you can just do stuff with vulkanlinear images there
<karolherbst>
maybe
<karolherbst>
I don't know vulkan :)
<karolherbst>
I just now that on top of GL gallium I need 1. set_global_binding and... that's it :)
<karolherbst>
(well besides compiler stuff, but I lower a lot of things to make it work)
<karolherbst>
I'd need to change gallium APIS for 2D from buffer though
<karolherbst>
but besides that? nope, nothing
<ajax>
karolherbst: get a vulkan driver working and then just use zink
<bnieuwenhuizen>
you ... are not the first offering that advice :P
<Venemo>
You don't need to know vulkan to develop a vulkan driver
<ajax>
oh, not for gl, here
* ajax
hushes
<karolherbst>
Venemo: yeah... I also don't know much about GL :)
<Venemo>
Hehe
<karolherbst>
but I do know a lot about CL now :O
<karolherbst>
but if you start implementing on the API side you kind of have to
<Venemo>
🤣
<Venemo>
Yeah, to some extent it doesn't hurt to know it
<karolherbst>
bnieuwenhuizen: but yeah.. maybe it would be easier to use zink for now, now that things actually pass the CTS
<daniels>
zmike's claiming it's the reference GL driver now
<karolherbst>
but I kind of don't like the converting nir to spirv part
<karolherbst>
and would rather just pass the spir-v through
<bnieuwenhuizen>
karolherbst: just consider it a gallium driver and don't look under the hood :P
<karolherbst>
that's what I am already doing! :D
<karolherbst>
but honestly, you'll hate the nir you'd get
<karolherbst>
the bigger issue is just the complexity of the nirs
<karolherbst>
so.. we want to do real function calling at some point
<karolherbst>
and you'll end up with nirs having a lot of values
<karolherbst>
and I think it's easier to just require vulkan drivers to consume spir-v directly :)
<heat>
given that we have license-compatible nvidia drivers now, isn't it a good idea to ditch nouveau? at least the kernel side?
<bnieuwenhuizen>
yeah, we'll need to improve the compilers in the vulkan drivers too
<karolherbst>
heat: nope
<heat>
why not?
<karolherbst>
nvidias code can't go upstream for multiple reasons
<bnieuwenhuizen>
heat: sounds like a safe bet that the nvidia drivers are not upstreamable in their current form at least
<heat>
yes, but do you need it upstream?
<karolherbst>
yes
<Sachiel>
also support for older platforms
<heat>
you could do it like IIRC dri was done back then
<karolherbst>
please no
<anholt_>
there's a reason we stopped doing it like dri was done back in the bad old days
<karolherbst>
why are we even arguing if having a non upstream driver is okay? of course it has to be upstream :P
<karolherbst>
I am already annoyed by canonical saying "ahh yeah, we just ship this out of tree stuff"
<karolherbst>
but well.. it's cannonical :P
<jekstrand>
canonical has been shipping the blob for years
<karolherbst>
I didn't expect anything else
<karolherbst>
I know
<karolherbst>
but they didn't disable nouveau yet, which I expect them to do in the future
mbrost_ has quit [Ping timeout: 480 seconds]
<jekstrand>
:-/
<karolherbst>
well.. do you expect them to not do this once the out of tree driver covers all relevant devices?
<karolherbst>
well maybe they would just patch out support for newer devs in nouveau
<karolherbst>
who knows
<karolherbst>
maybe they wouldn't
<karolherbst>
point is, I don't trust them to not do it
<heat>
how's mesa going to do things then? no nvidia support and just nouveau?
<karolherbst>
heat: why would mesa want to target out of tree UAPIs? :P
<karolherbst>
that's a hell of a nightmare to support
<karolherbst>
the biggest problem is though.. nvidia needs UAPI for CUDA, but CUDA stays closed
<heat>
ideally someone brings it upstream (that may take a while, of course)
<karolherbst>
and we won't accept UAPIs without open userspace
<karolherbst>
so how would that stuff gets upstreamed?
<Venemo>
Okay, maybe a stupid question, but if they didn't write this from scratch but just opened their driver, why does this new one lack some features and HW support?
<karolherbst>
because they disabled it
<heat>
Venemo, what's it lacking?
<Venemo>
Why was it okay to open the Turing support but not the others
<karolherbst>
heat: it's mostly compute only at this point
<heat>
oh really?
<karolherbst>
Venemo: because turing has this big risc-v CPU which can load this huge firmware blob
<Venemo>
so?
<Venemo>
I don't see the connection
<karolherbst>
they obviously didn't want to open stuff which is in firmware :P
<Venemo>
The old GPUs also had something that loaded the FW, didn't they?
<karolherbst>
yeah, but not like this
<karolherbst>
on turing+ you can use this one risc-v one instead of all the others
danvet has quit [Ping timeout: 480 seconds]
<Venemo>
Sure, they don't wanna open the FW, but nobody expects them to do that anyway
<dcbaker>
I mean, it works be great if they did
<Venemo>
What is wrong with the old way of loading the FW that warrants keeping those closed?
anonymus1234 has quit []
<Venemo>
Also, why do they care? Those GPUs are obsolete by now anyway
<karolherbst>
why would it even matter?
<karolherbst>
they made a decision, and that's what we got
<Venemo>
sorry, my mistake for trying to make sense of it
<gawin>
some people are putting older gpus into PCs for compatility with 98/xp
Haaninjo has quit [Quit: Ex-Chat]
<karolherbst>
gawin: I think those are people you don't have to care about
maxzor has quit [Ping timeout: 480 seconds]
alanc has joined #dri-devel
* airlied
called my vulkan driver nouv :-P
<graphitemaster>
no.uv
<karolherbst>
airlied: it was your name and I think I used it then or soemthing
apinheiro has joined #dri-devel
ahajda has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<javierm>
Venemo: but maybe the old GPUs didn't have a big enough co-processor to push all their IP to the firmware ?
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
mmind00 has quit [Quit: No Ping reply in 180 seconds.]
unerlige has quit [Remote host closed the connection]
rsripada has quit [Remote host closed the connection]
jhli has quit [Remote host closed the connection]
jhli has joined #dri-devel
Ryback_ has quit [Remote host closed the connection]
nchery has quit [Remote host closed the connection]
unerlige has joined #dri-devel
Ryback_ has joined #dri-devel
mattrope has quit [Remote host closed the connection]
ramaling has quit [Remote host closed the connection]
pzanoni has quit [Remote host closed the connection]
tursulin has quit [Remote host closed the connection]
mdnavare has quit [Remote host closed the connection]
ramaling has joined #dri-devel
pzanoni has joined #dri-devel
mdnavare has joined #dri-devel
nchery has joined #dri-devel
<javierm>
in other words, maybe for turing they could push IP that was in the driver to the firmware but that maybe wasn't possible for older GPUs
mattrope has joined #dri-devel
aswar002 has quit [Remote host closed the connection]
rsripada has joined #dri-devel
mmind00 has joined #dri-devel
aswar002 has joined #dri-devel
CATS has quit [Ping timeout: 480 seconds]
CATS has joined #dri-devel
<FLHerne>
karolherbst: Why does CUDA need unique uapi that isn't required for CL and similar
<karolherbst>
because CUDA is huge
<FLHerne>
(?)
<karolherbst>
the uapi is out there, just look at it
<FLHerne>
yeah, but I thought most of the hugeness would end up being userspace stuff
<karolherbst>
it's mostly nvidia-uvm, but there are a looot of uapis
<FLHerne>
hm, ok
<karolherbst>
the problem is, are they willing to open up CL if we require a compiler or is that already a show stopper
<karolherbst>
so that's the second issue
tursulin has joined #dri-devel
OftenTimeConsuming is now known as Guest429
OftenTimeConsuming has joined #dri-devel
Guest429 has quit [Remote host closed the connection]
<jekstrand>
karolherbst: Truly aweful but also probably what we need to do thanks to CL barrier semantics. :-/
<karolherbst>
I didn't
<Venemo>
javierm: I didn't think about that, but maybe
<karolherbst>
jekstrand: yeah.. we need that :)
tursulin has quit [Ping timeout: 480 seconds]
<karolherbst>
but yeah.. it sounds horrible :(
<karolherbst>
is there no instruction to converge threads?
<jekstrand>
karolherbst: No. It's pretty horrible
<karolherbst>
:(
<jekstrand>
karolherbst: The OpenCL spec says:
<jekstrand>
If the barrier is inside a conditional statement, then all work-items in the work-group must enter the conditional if any work-item in the work-group enters the conditional statement and executes the barrier.
<jekstrand>
<jekstrand>
This is very different from GL where it's required to be in uniform control-flow.
<karolherbst>
yeah...
<karolherbst>
compute doesn't care about trivial things like "is this even feasible in hw?" :P
<jekstrand>
With CL, you have to allow for some of a wave to hit the barrier and another part to hit it on the next time around.
<jekstrand>
It may be that we can use a different kind of barrier on DG2 that works like CL wants it to.
<jekstrand>
I seem to recall there's something that might work but I no longer have access to those docs.
<karolherbst>
potentially
<jekstrand>
Hrm...
<jekstrand>
No, never mind. Not possible.
<karolherbst>
for what is this needed here anyway?
OftenTimeConsuming has quit [Ping timeout: 480 seconds]
<jekstrand>
What do you mean?
<karolherbst>
like why does vulkan need this?
<karolherbst>
or well.. I suspect it's for vulkan, but why is that needed?
<jekstrand>
Vulkan doesn't. OpenCL does and Vulkan ray-tracing uses some OpenCL kerne.s
<jekstrand>
*kernels
<karolherbst>
ahh, right, of course
apinheiro has quit [Quit: Leaving]
<karolherbst>
let me read something
<jekstrand>
So one of the cases where you can hit this with CL is if you do "while (true) { ... if (non-uniform) { barrier(); /* stuff */ break; } }"
<karolherbst>
soooo
<karolherbst>
I think for ifs it has to be uniform
<karolherbst>
for loops it doesn't
<jekstrand>
Yes
<jekstrand>
I think that's right
tursulin has joined #dri-devel
<jekstrand>
If the barrier is inside a loop, then all work-items in the work-group must execute the barrier on each iteration of the loop if any work-item executes the barrier on that iteration.
<karolherbst>
for loops we can force all threads to go through a barrier, might not be pretty but we could reorganize any loop in such a way
<jekstrand>
That seems to imply actual uniform
<karolherbst>
yeah.. soo there are two parts
<karolherbst>
uniform control flow
<karolherbst>
and converged/diverged threads
<karolherbst>
they all might reach the barrier, but not at the same time
<jekstrand>
It could be that we can just make the structurizer more barrier-aware.
<jekstrand>
I don't know how to do that, though. :-/
<karolherbst>
do all threads have to execute the barrier in lock-step on DG2?
<jekstrand>
all invocations in a wave? Yes.
<jekstrand>
All threads? That's kind of the point of barrier()
<karolherbst>
mhh, right
icecream95 has joined #dri-devel
<jekstrand>
Hrm...
<jekstrand>
Yeah, we may be able to just chalk this up to structurizer fail, actually.
<karolherbst>
hopefully
<jekstrand>
Not sure how to fix it, though. :-/
<jekstrand>
Reading Lionel's pass may be easier than trying to page in how the structurizer works. :-/
<karolherbst>
:D
<karolherbst>
I know that on nvidia we have to synchronize threads for stuff like this, which is annoying
nchery has quit [Ping timeout: 480 seconds]
<jekstrand>
We may also be able to get away with just a loop break hoisting pass.
<jekstrand>
Yeah, that's what the Intel barrier instruction does.
<jekstrand>
It does some sort of semaphore thing to sync threads
<jekstrand>
It's all in HW so I don't know the details.
<karolherbst>
right
<karolherbst>
we have a warpsync instruction with a constant thread mask
<karolherbst>
well on newer gens
gawin has quit [Ping timeout: 480 seconds]
<dschuermann>
I guess that could be done using ballot(non-uniform cond) != 0? modulo side-effects modulo messiness
nchery has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
<jekstrand>
airlied: Reminder: !16435 would like your eyes on the 4 llvmpipe patches.
<jekstrand>
I don't think any of them should be controvertial
<airlied>
will look once I run out of meetings to go to
<jekstrand>
airlied: So, August, maybe?
<jekstrand>
Of 2035
* jekstrand
gets some of his best code review done during meetings.
morphis has quit [Ping timeout: 480 seconds]
morphis has joined #dri-devel
<tarceri>
jekstrand: no problem. emma has given it a rb so up to you if you want to go over it as well :)
<jekstrand>
tarceri: I was going to. My brain might be working well enough now. I'll give it a go. Otherwise, I'll look tomorrow.
<jekstrand>
tarceri: Why is there nothing in the then side besides the break? Is that part of it being a terminator?
pcercuei has quit [Quit: dodo]
<anholt_>
how would I detect a vtn frexp or modf destination needing to be referenced with ->elems[i] instead of ->def? All the other cases seem to be fine with glsl_type_is_vector_or_scalar(value->type) to detect that the result is in ->def.
rkanwal has quit [Quit: rkanwal]
<tarceri>
jekstrand: yeah the continue side generally has all instructions moved outside the if via opt_if
alistairp has joined #dri-devel
<anholt_>
mediump looks like it's worth 5% on gfxbench vk-5-normal¸ putting us within 4% of freedreno.
<jekstrand>
tarceri: That's not the side I'm worried about. :-) Left you a comment on the MR.
<anholt_>
(I suspect once we sort out a bit of gmem allocation stuff, we'll get the rest and maybe pull ahead)