<javierm>
but that file doesn't currently exists. Do you mind if I just do the kerneldoc bits and do that later, to prevent bikesheed about the text on that new file ?
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
MajorBiscuit has joined #dri-devel
<danvet>
emersion, fix the bugs, since "shouldn't reuse so aggressively" is a bit unclear semantics
pcercuei has joined #dri-devel
<danvet>
it's either "can reuse" or "we make the id space big enough to newer reuse"
<emersion>
well there's no "bug" to fix, apart from the uAPI having no good synchronization
<danvet>
javierm, huh, I grepped that in some tree
<emersion>
we'd need to add a serial to the hotplug event, and a way to check the information fetched from a GET* ioctl is still up-to-date given a hotplug serial
<javierm>
danvet: ohh, I would had swear that did a find Documentation/ -name other_interfaces.rst before asking
<javierm>
danvet: sorry, I see it now
<javierm>
cool, I'll add it there then
<jadahl>
the dumbest way to make sure fetched drm state is correct is to add a get-serial ioctl, that one would fetch before and after ones gets the drm state. no need to add it to any udev events. if it increased between those calls, drop everything, wait for an udev event and try again
mceier has joined #dri-devel
mceier is now known as Guest1467
mceier has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
Guest1467 has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
h0tc0d3 has quit [Remote host closed the connection]
rasterman has joined #dri-devel
<danvet>
jadahl, yeah we internally added a seq count now, but it's not yet exposed
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<danvet>
jadahl, btw for the sysfb pieces I guess would be good to get an ack from gregkh
<danvet>
drivers/fw is a bit a mess where lots of different people just push, but can't hurt to play good citizen
<danvet>
jadahl, or maybe we officially add drm-misc in a MAINTAINERS entry for these
rasterman has quit [Quit: Gettin' stinky!]
<jadahl>
sysfb is what simpledrm hooks up to?
<danvet>
yeah
rasterman has joined #dri-devel
<danvet>
and maybe even eventually all fw fb drivers
<danvet>
offb atm doesn't create a platform_dev
<danvet>
and I think vga16fb creates it internally
<jadahl>
but a theoretical "get seq" ioctl would live in drm land though is there any agreement with drivers/firmware needed for any uapi?
<danvet>
jadahl, oh that was 2 different topics
<danvet>
nothing to do with each another
<jadahl>
ah, that explains it :)
<danvet>
jadahl, oh I wanted to ping javierm not you for the 2nd thing, apologies for the confusion
<danvet>
javierm, ^^ see sysfb comments from me above
soreau has quit [Ping timeout: 480 seconds]
<javierm>
danvet: ah, missed indeed. /me reads
<javierm>
danvet: absolutely. I in fact added Greg to Cc list for the next version
<javierm>
danvet: and also thought the same about MAINTAINERS after I missed some patches in my original RFC post due that
rasterman has quit []
<javierm>
will post a patch. At least to make sure that we (dri-devel) get patches to sysfb since is relevant for us
<javierm>
jadahl: and yeah, sysfb just register the platform device that matches a generic system framebuffer driver (that could be fbdev or DRM)
<javierm>
jadahl: what the DRM driver does is not relevant to sysfb, it just register a device and forgets :)
<javierm>
in fact is an __init function
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
<jadahl>
javierm: the confusion came from danvet auto-complete making it seem like sysfb would have a say in 'get-seq' drm ioctls, but that's not the case
rasterman has joined #dri-devel
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
<javierm>
jadahl: yeah
toolchains has quit [Ping timeout: 480 seconds]
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
toolchains has joined #dri-devel
Company has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
MrCooper has joined #dri-devel
itoral has quit [Remote host closed the connection]
Duke`` has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
itoral has quit [Remote host closed the connection]
itoral has joined #dri-devel
dviola has quit [Remote host closed the connection]
mclasen has joined #dri-devel
dviola has joined #dri-devel
jkrzyszt_ has quit [Remote host closed the connection]
slattann has joined #dri-devel
heat has joined #dri-devel
devilhorns has joined #dri-devel
jkrzyszt has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
toolchains has quit [Remote host closed the connection]
pcercuei has quit [Read error: Connection reset by peer]
Thymo has joined #dri-devel
toolchains has quit [Read error: Connection timed out]
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
nchery has quit [Read error: Connection reset by peer]
mareko has quit [Remote host closed the connection]
dri-logger has quit [Remote host closed the connection]
mslusarz has quit [Remote host closed the connection]
mslusarz has joined #dri-devel
glisse has quit [Remote host closed the connection]
glisse has joined #dri-devel
toolchains has joined #dri-devel
mareko has joined #dri-devel
dri-logger has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
toolchains has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
itoral has quit []
rkanwal has joined #dri-devel
shankaru has quit [Quit: Leaving.]
toolchains has quit [Remote host closed the connection]
toolchains has joined #dri-devel
shankaru has joined #dri-devel
toolchains has quit [Ping timeout: 480 seconds]
heat_ has quit [Read error: Connection reset by peer]
dri-logger has quit [Read error: Connection reset by peer]
heat has joined #dri-devel
dri-logger has joined #dri-devel
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
mceier has quit [Ping timeout: 480 seconds]
shankaru has quit []
shankaru has joined #dri-devel
shankaru has quit []
<zmike>
MrCooper: fridays are hard.
<MrCooper>
hehe, yeah
<imirkin>
don't worry, there's a monday coming soon.
<MrCooper>
as are Mondays, according to one famous cat
rgallaispou has quit [Read error: Connection reset by peer]
aravind has quit [Ping timeout: 480 seconds]
jkrzyszt has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
jkrzyszt has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
MajorBiscuit has joined #dri-devel
mbrost has joined #dri-devel
Net147 has quit [Quit: Quit]
<cwabbott>
hakzsam: I was looking at your commit for how radv implemented vk_sync2, and there's this quote from the spec: "Additionally, scoping the pipeline stages into the barrier structs allows the use of the MEMORY_READ and MEMORY_WRITE flags without sacrificing precision." but radv doesn't seem to really care
<hakzsam>
hmm, I might have missed that
<cwabbott>
it seems like now we need to filter on stage and memory type to figure out what to flush, to handle the old and new styles
<cwabbott>
well, what caches to flush
<cwabbott>
or else someone actually trying that is gonna have a bad time
Net147 has joined #dri-devel
<hakzsam>
I will check, thanks for the info
Net147 has quit []
<jekstrand>
karolherbst: The asserts in the conversino tests are because we don't support fp64 on recent Intel HW.
<karolherbst>
ahh
<jekstrand>
It's an optional feature in CL 3.0
<jekstrand>
It looks non-optional in 1.2, maybe?
<karolherbst>
well, iris reports it
<karolherbst>
and I do run fp64 lowering
<jekstrand>
karolherbst: I don't see nir_lower_fp64 in rusticl
<karolherbst>
no? I thought I added it
<jekstrand>
Looks like it is optional in CL 1.2
<karolherbst>
it's not really
<jekstrand>
CL_DEVICE_PREFERRED_
<jekstrand>
Last Revision Date: 11/14/12 Page 39
<jekstrand>
CL_DEVICE_PREFERRED_
<jekstrand>
VECTOR_WIDTH_LONG
<jekstrand>
VECTOR_WIDTH_INT
<jekstrand>
CL_DEVICE_PREFERRED_
<jekstrand>
VECTOR_WIDTH_FLOAT
<jekstrand>
CL_DEVICE_PREFERRED_
<jekstrand>
VECTOR_WIDTH_DOUBLE
<jekstrand>
CL_DEVICE_PREFERRED_
<karolherbst>
it's optional for the embedded profile
<jekstrand>
VECTOR_WIDTH_HALF
<jekstrand>
vector.
<jekstrand>
If double precision is not supported,
<jekstrand>
CL_DEVICE_PREFERRED_VECTOR_WIDTH_
<jekstrand>
DOUBLE must return 0.
<jekstrand>
If the cl_khr_fp16 extension is not supported,
<jekstrand>
CL_DEVICE_PREFERRED_VECTOR_WIDTH_
<jekstrand>
HALF must return 0.
<jekstrand>
CL_DEVICE_NATIVE_
<jekstrand>
VECTOR_WIDTH_CHAR
<jekstrand>
CL_DEVICE_NATIVE_
<karolherbst>
jekstrand: yeah so if you don't have fp64 you get EMBEDDED_PROFILE
<jekstrand>
VECTOR_WIDTH_SHORT
<jekstrand>
CL_DEVICE_NATIVE_
<jekstrand>
VECTOR_WIDTH_INT
<jekstrand>
CL_DEVICE_NATIVE_
<daniels>
o\
<karolherbst>
also.. never paste from the spec :D
<jekstrand>
VECTOR_WIDTH_LONG
<jekstrand>
CL_DEVICE_NATIVE_
<jekstrand>
VECTOR_WIDTH_FLOAT
<karolherbst>
the pdf is..... broken
<jekstrand>
CL_DEVICE_NATIVE_
<jekstrand>
VECTOR_WIDTH_DOUBLEbah
<jekstrand>
bah
<jekstrand>
CL_DEVICE_NATIVE_VECTOR_WIDTH_DOUBLE can return 0
<karolherbst>
I actually check all of that already
<karolherbst>
only for the embedded profile
<karolherbst>
but anyway, iris reports support for FP64 :p
<karolherbst>
otherwise I wouldn't claim it
<jekstrand>
karolherbst: It seems to say that doubles are optional even in the part of the spec outside the embedded profile.
<jekstrand>
It's int64 that's additionally optional in embedded
<karolherbst>
mhhh, weird
<karolherbst>
let me check
<jekstrand>
And... we're returning 0 for NATIVE_VECTOR_WIDTH_DOUBLE and the CTS tests are running anyway. :-/
<karolherbst>
yeah well
<karolherbst>
tough
<karolherbst>
anyway, I am sure fp64 is required
<karolherbst>
mhh maybe I am wrong, let me read more stuff
<karolherbst>
jekstrand: ohh seems you are right and I confused it with int64 being required
<jekstrand>
I'm asking on the Khronos slack. Hoping to snag a spec editor who actually knows. :joy:
pcercuei_ has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
<jekstrand>
I'm gonna modify the CTS :)
<jekstrand>
Ooh, it seems like it tries to check
<jekstrand>
we advertise fp64...
<jekstrand>
Ok, we just need to fix rusticl to not advertise fp64 on iris
soreau has joined #dri-devel
<jekstrand>
karolherbst: What do you think about having PIPE_CAP_DOUBLES/INT64 return a boolean: NOT_SUPPORTED = 0, EMULATED = 1, NATIVE = 1?
<jekstrand>
Kayden, mareko: ^^
<jekstrand>
s/boolean/enum
<imirkin>
and probably one of those should be a "2" :)
<jekstrand>
Yes, I was thinking native would be 2
<jekstrand>
It's Friday morning. That means almost week-end. :P
<karolherbst>
jekstrand: potentially
<imirkin>
fwiw i've gotten around stuff like that with GLSL/etc versions
<jekstrand>
idk how much I care about knowing that int64 is emulated. That stuff's pretty cheap compared to fp64.
<karolherbst>
fp64 is slow nearly everywhere...
<imirkin>
e.g. if you only emulate some feature
<imirkin>
return 0 for the feature flag
Net147 has joined #dri-devel
<imirkin>
but indicate support for it by claiming a higher GLSL version
<imirkin>
so that the state tracker knows to do the lowering
<jekstrand>
karolherbst: There's "hw runs at 1/32 rate" slow and then there's "we emit 300 instructions for fadd" slow.
<imirkin>
(or only enable the ext if the other conditions are met)
<jekstrand>
Also, emulating fp64 currently requires the GLSL compiler which is problematic for OpenCL. :)
<karolherbst>
jekstrand: we have both on nvidia
<karolherbst>
we have like dadd and dmul?
<karolherbst>
and dset (bcsel) :)
<jekstrand>
karolherbst: Intel Gfx11+ has NOTHING
<imirkin>
i did that for indirect draws with ES 3.1
<karolherbst>
jekstrand: that sucks
<jekstrand>
karolherbst: It sucks real bad, yes.
<imirkin>
jekstrand: not even conversion?
<imirkin>
i.e. f64 <-> f32
<jekstrand>
imirkin: Nope
<karolherbst>
jekstrand: guess we shouldn't expose fp64 support there then
<jekstrand>
No 64-bit types whatsoever
dviola has quit [Remote host closed the connection]
<karolherbst>
you only get those with 1/32 speed on 50 grand "workstation" cards
tursulin has quit [Quit: Konversation terminated!]
dviola has joined #dri-devel
* karolherbst
currently doing a huge rebase *sigh*
Net147 has quit []
Net147 has joined #dri-devel
Haaninjo has joined #dri-devel
Net147 has quit [Remote host closed the connection]
cyrozap has quit [Ping timeout: 480 seconds]
Net147 has joined #dri-devel
cyrozap has joined #dri-devel
Net147 has quit []
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #dri-devel
<karolherbst>
jekstrand: CL has a flag for emulated fp64 btw
stuartsummers has quit []
stuartsummers has joined #dri-devel
stuartsummers has quit []
stuartsummers has joined #dri-devel
Net147 has joined #dri-devel
<jekstrand>
karolherbst: I don't want to run the CTS with emulated fp64. :P
Net147 has quit []
gouchi has joined #dri-devel
Net147 has joined #dri-devel
Net147 has quit []
<karolherbst>
jekstrand: :D I do that with llvmpipe
<karolherbst>
it's not too bad
<karolherbst>
add a -w flag to the runner
<karolherbst>
then it cuts off like 95% of the work
Net147 has joined #dri-devel
<jekstrand>
karolherbst: I also don't want to figure out how to get NIR fp64 lowering working without GL.
<karolherbst>
ohhhh, right....
<karolherbst>
ask libclc?
<jekstrand>
libclc has fp64 lowering?
<karolherbst>
no idea
<karolherbst>
maybe some?
<jekstrand>
LLVM definitely does somewhere
<jekstrand>
But that's way too early
dviola has quit [Remote host closed the connection]
<karolherbst>
yeah.. doesn't really work for spirv stuff anyway
dviola has joined #dri-devel
<karolherbst>
yeah.. I think libclc only implements the builtins
<jekstrand>
For now, I've got a patch to just disable fp64
<karolherbst>
sounds fine
<jekstrand>
And I did it without a new cap
<jekstrand>
I look for nir_lower_fp64_full_software in nir_shader_compiler_info::lower_doubles_options
LexSfX has quit []
<karolherbst>
mhh
<karolherbst>
maybe
<karolherbst>
fp64 lowering is quite annoying
<karolherbst>
jekstrand: I think we might have to check for that being set for now
<jekstrand>
If you need emulated sin/cos or something, that works without having to load a GLSL shader
<karolherbst>
as we can't lower it anyway
<karolherbst>
ahh
<karolherbst>
what does require glsl shader?
<jekstrand>
It's just full software that requires it
<karolherbst>
1. it flushes automatically and you have to sync on the returned fences 2. we are in control what operations are allowed on the context
<karolherbst>
so we could only allow buffer_subdata and texture_subdata
<karolherbst>
but using it is a bit annoying
<karolherbst>
(still working on fixing mapping)
caef^ has joined #dri-devel
<jekstrand>
karolherbst: Yeah, it feels a bit messy but it does fix those two
ybogdano has joined #dri-devel
mceier has joined #dri-devel
<cwabbott>
jekstrand: dj-death: looks like anv has the same problem as radv with vk_khr_synchronization2
<dj-death>
cwabbott: which is?
<cwabbott>
dj-death: "hakzsam: I was looking at your commit for how radv implemented vk_sync2, and there's this quote from the spec: "Additionally, scoping the pipeline stages into the barrier structs allows the use of the MEMORY_READ and MEMORY_WRITE flags without sacrificing precision." but radv doesn't seem to really care"
LexSfX has joined #dri-devel
<cwabbott>
if you actually tried to do what the spec suggests (just specify a stage and do MEMORY_READ/MEMORY_WRITE) you'd have a bad time
nchery has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<dj-death>
ah right
<dj-death>
that's interesting indeed
<dj-death>
I think our implementation just doesn't ever care about the stage right now
<dj-death>
I have some changes to start looking at them
<jekstrand>
Ugh... there are a lot of convert tests....
<dj-death>
is the last NIR block of a function supposed to have successors[0] != NULL ?
<dj-death>
sounds wrong
<dj-death>
but somehow SPIRV parsing seems to generate that
mbrost has quit [Ping timeout: 480 seconds]
khfeng has quit [Ping timeout: 480 seconds]
<jekstrand>
dj-death: That does seem a bit off. Does validation say anything about it?
<jekstrand>
Hrm... It seems we assert block->successors[0] != NULL
<jekstrand>
It probably points at the dummy end block.
<dj-death>
no
<dj-death>
not sure to what it points
<dj-death>
grep src/compiler/nir/ it seems some parts assume it's going to be NULL
<karolherbst>
jekstrand: got blocking maps to work with mapping in the worker thread :) just need to figure out how to make the code not look annoying
<jekstrand>
karolherbst: \o/
<karolherbst>
Condvars are quite nice in Rust, but it's verbose as hell
<javierm>
danvet: hmm, your revert patch again was delivered with an empty body...
<danvet>
javierm, last time around it was the other way round iirc :-)
<javierm>
so strange
<javierm>
danvet: anyway, addressed all the issues you pointed out so I kept your R-B tag. Let me know if you see something else that needs work there
<danvet>
javierm, 4/5 was the only one with and that looks good
<javierm>
danvet: great, thanks
iive has joined #dri-devel
mszyprow has quit [Ping timeout: 480 seconds]
<jekstrand>
conversions passed
<jekstrand>
PASSED 765 of 765 sub-tests.
<jekstrand>
PASSED test.
<jekstrand>
\o/
<zmike>
!
<jekstrand>
I feel slightly compelled to disable conversion lowering for iris but I'm not sure if I'm going to do that today or not
* jekstrand
runs a bunch of image tests
<jenatali>
\o/
<zmike>
what's the quickest way to end an instr at the very end of a shader?
<zmike>
last_block -> last_instr I assume?
<jekstrand>
it's annoying
<zmike>
yea
<jekstrand>
If you assume returns are lowered, `b.cursor = nir_after_cf_list(&impl->body)` will work, I think.
<zmike>
hm
<zmike>
I think I can do it before too
mbrost has joined #dri-devel
<jekstrand>
If returns aren't lowered, then you need to insert it at the end of every predecessor block to end_block.
<zmike>
I meant I could put it at the start of the shader
<jekstrand>
that works too
MajorBiscuit has quit [Ping timeout: 480 seconds]
<jekstrand>
hrm.... /me thought USE_HOST_PTR was only allowed for 1D and 2D images.
idr has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mhenning has joined #dri-devel
toolchains has joined #dri-devel
DanaG has quit [Remote host closed the connection]
Duke`` has joined #dri-devel
<graphitemaster>
I see someone tried to copy paste from a PDF in here
eukara_ has joined #dri-devel
eukara has quit [Read error: No route to host]
<graphitemaster>
Classic mistake
<graphitemaster>
You'd think in the year 2022 we'd figure out how to make copy-paste useful.
<graphitemaster>
Someone should apply some AI to clipboards, I sense formatting is something a NN can deal with easily.
<karolherbst>
I am sure the problem is within the PDF parsing though
<karolherbst>
don't have to copy every EOL
<karolherbst>
that would probably fix 99% of those issues copying from PDFs
<graphitemaster>
Oh for sure, just stripping newlines and doing regular word-wrap at say 80 columns would probably be a better copy than most PDF copies.
<karolherbst>
no word-wrap please :P
<graphitemaster>
Who doesn't like word-wrap
<karolherbst>
if the sentence contains "80 columns" then it's wrong :P
<graphitemaster>
Humans are exceptionally bad at reading long lines of text, there's thousands of objective research studies on this, somewhere between 50-75 characters is optimal, 80 is overly conservative if anything.
<karolherbst>
what does it have to do with copy pasting text?
<graphitemaster>
The thing you're pasting it in probably wants it in that domain.
<karolherbst>
no it doesn't
<karolherbst>
it just wants text
<karolherbst>
it can wrap stuff on its own
<graphitemaster>
True
<karolherbst>
maybe I copy something which is fixed at 100 columns, then what?
<karolherbst>
or nice ASCII grpahs or whatever
<graphitemaster>
What if we just sent each other images instead of characters, then none of these issues would happen.
<karolherbst>
good idea
<bnieuwenhuizen>
I'd rather have my tables be text than an image, much better for partial copy support
<karolherbst>
let's put the clipboard on a blockchain, then we even now if something changed it mid way
<graphitemaster>
If you need to copy the text just copy the image, duh.
<karolherbst>
let's make an app and sell it for $5 and get 500k as funding from governments hyping blockchains
<karolherbst>
graphitemaster: something evil like the CPU could modify the image
<karolherbst>
or myself
<karolherbst>
can't have that
<graphitemaster>
We can digitally sign the image with a PGP key
<karolherbst>
nah, that won't get you investors money for an app
<karolherbst>
need to use blockchain, because security and shit
<graphitemaster>
But the PGP keys are generated randomly by a process of brute forcing a mathematical equation we will call "mining"
<karolherbst>
you think we could turn PGP keys into NFTs?
<karolherbst>
the private ones of course
<karolherbst>
the NFTs make sure there is just one owner
<graphitemaster>
Pretty Good Non Fungible Privacy: PGNFP
<karolherbst>
finally a user friendly solution to email encryption
<graphitemaster>
As Per My Previous PGP Key
<jekstrand>
karolherbst: Did we ever get image_format or image_order wired up?
<karolherbst>
nope
kts has joined #dri-devel
eukara_ has quit [Ping timeout: 480 seconds]
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
eukara has joined #dri-devel
agd5f has joined #dri-devel
agd5f_ has quit [Ping timeout: 480 seconds]
<karolherbst>
so let's see how much I messed up
<karolherbst>
jekstrand: I am still not looking forward implementing that stuff for non blocking maps... *sigh*
<karolherbst>
nice, deadlocks
<karolherbst>
ehh a paniced thread actually
<karolherbst>
ahhhh
<karolherbst>
jekstrand: soo uhm.. I don't know if you know, but you can call CL stuff within event callbacks :(
<jekstrand>
Yup. It's awesome!
<karolherbst>
anyway... my worker crashed but that's not as easy to propagate if you wait on something to happen :)
<karolherbst>
like an assert e.g.
<karolherbst>
mhh I thought I fixed this issue though
<karolherbst>
anyway.. the conversions tests are mapping non blocking :(
adjtm has quit [Read error: Connection reset by peer]
<karolherbst>
hopefully nothing else does
dviola has quit [Remote host closed the connection]
<Kayden>
jekstrand: 0/1/2 for PIPE_CAP_DOUBLES sounds good to me
<Kayden>
huh.
adjtm has joined #dri-devel
<Kayden>
ah, right, brw doesn't call the pass anymore, it just sets options, good
sb has quit [Remote host closed the connection]
toolchains has quit []
<Kayden>
jekstrand: then again, if we just made st_extensions.c check (nir_options->lower_doubles_options & nir_lower_fp64_full_software) in addition to PIPE_CAP_DOUBLES when enabling fp64/va64 extensions...
<Kayden>
then we could just stop reporting it
<Kayden>
(there's a "not-emulated" check on the other use of that cap already)
devilhorns has quit []
Sanskar_Bhushan has joined #dri-devel
Sanskar_Bhushan has left #dri-devel [#dri-devel]
Sanskar_Bhushan has joined #dri-devel
eukara has quit [Read error: No route to host]
eukara has joined #dri-devel
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
<anholt>
I've unmarked https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8044 as WIP. I would like some help getting reviews and acks on it since it's big, including acks for the general plan of "no, you don't get glsl-to-tgsi's behavior any more, even if you were used to it", and "yeah, virgl/r600/nouveau can live with these changes in test results"
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
mvlad has quit [Remote host closed the connection]
tanty has quit []
tanty has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
<karolherbst>
mhh only having core rust available is kind of restricting :(
<graphitemaster>
oh shii kopper is in
<HdkR>
karolherbst: As restricted as writing code in C89? :P
<karolherbst>
kind of
idr has quit [Quit: Leaving]
ngcortes has joined #dri-devel
<karolherbst>
jekstrand: I think I have to rewrite the entire mapping stuff from scratch.. so here is the deal with mappings: a resource can have unlimited read mappings, but just one writing one. new maps invalidate/sync the mapped area (offset + size). I am wondering if we should always map the entire resource and just return an offseted pointer, or if we should keep multiple pipe_transfers around, or if we only have one transfer covering the entire
<karolherbst>
mapped regions
<karolherbst>
the thing which annoys me the most about the current situation is, that I can't easily know if I have a mapping at offset already
<karolherbst>
the biggest issue we have when we create a shadow buffer for non blocking maps is, that we have to sync the existing one when we get a call to mapBuffer
mszyprow has joined #dri-devel
<karolherbst>
although I am sure I can rely on base + offset == ptr, but if I never map at the base... mhh well.. I could also back caluclate the base address or something
<karolherbst>
anyway, it's annoying and I don't really know what path I want to go here
LexSfX has quit [Ping timeout: 480 seconds]
ybogdano has quit [Read error: Connection reset by peer]
LexSfX has joined #dri-devel
<jekstrand>
karolherbst: Are you allowed to have read maps open while you have a write map open?
<jekstrand>
Or is it like rust references: one read or N writes?
<karolherbst>
jekstrand: you can do it, but then it's undefined. But you can have multiple write mappings as long as they don't overlap
<karolherbst>
"5.5.3. Accessing mapped regions of a memory object" describes that stuff
ngcortes has quit [Remote host closed the connection]
<jekstrand>
Oh, and we have to return an error on overlap. Awesome.
<karolherbst>
yeah...
<karolherbst>
but that's the simple part
<jekstrand>
I don't see anything in that section that's a problem
<karolherbst>
nothing in that section is a problem in itself, but we only know the pointer after we mapped, which we also only do after we enqueue stuff to the context
<jekstrand>
Yeah, for enqueue, you either have to sync or do shadows
<karolherbst>
unless I would know in advance what's the base address of the mapping
<jekstrand>
Which you do for host_ptr or if you can use a persistent map
<karolherbst>
sure, but not in the other cases
<jekstrand>
yup
<karolherbst>
I am wondering if we have to change gallium here so nothing of this sucks tbh
<jekstrand>
Some of it is going to suck
<jekstrand>
We're going to have to manage shadows
<karolherbst>
I am wondering if we could convince drivers to hand us back a base pointer where things will get mapped into, without actually doing the mapping
<karolherbst>
this little piece alone would make evertyhing super trivial do implement
<karolherbst>
maybe I should check what other CL stacks are doing there
ybogdano has joined #dri-devel
<karolherbst>
*pfffft*
<karolherbst>
annoying
<karolherbst>
jekstrand: so Intels runtime knows the pointer one mem object creation time
<karolherbst>
s/one/on/
<jekstrand>
karolherbst: For buffers, yeah, that's totally possible. For images, no. They want tiling.
<jekstrand>
It's called a persistent map. :P
<karolherbst>
yeah, I am aware
<karolherbst>
so if the stuff can't be mapped to the CPU they do transfers and all that stuff
<jekstrand>
Someone does, yeah.
<jekstrand>
When you call map_resource on an image, iris creates a temporary and does a blit.
<karolherbst>
yeah, makes sense
tanty has quit []
<jekstrand>
We just need to do that in rusticl for enqueued maps
<karolherbst>
sure
<karolherbst>
I think it would be nice if we could tell the driver to map/blit into a given pointer
mszyprow has quit [Ping timeout: 480 seconds]
<Lyude>
What's rusticl?
<karolherbst>
in the blocking case, we can just wait what the driver gives us, so that's totally fine. In the non blocking case I think I'd prefer to cut out some VM space via anonymous mapping or something and tell the driver to use that
<karolherbst>
Lyude: the name kind of gives it away, no?
<Lyude>
I mean I assumed some kinda rust intel driver for mesa but I figured I should check in case icl stood for something else
alyssa has joined #dri-devel
* alyssa
can never remember why C++ linking doesn't work right
<karolherbst>
yeah.. would be too much to ask if compiler would assume c linking for all functions declared in... *.h files :)
nchery is now known as Guest1501
nchery has joined #dri-devel
<alyssa>
heh
<karolherbst>
Lyude: a "little" side project I've been working on
<karolherbst>
and now jekstrand apparently as well :D
<alyssa>
karolherbst: that did it thanks <3
<karolherbst>
jekstrand: anyway.. the actual problem I have is, that I need to know if I already have a mapping or not.. but I guess I could key that on the offset
<Lyude>
btw, speaking of rust - a friend of mine's been working on a vulkan library for rust called vulkano, figured I'd mention this issue here in case anyone has any feedback for it since they've been stuck for a while on trying to figure out a good design for this in vulcano: https://github.com/vulkano-rs/vulkano/issues/1870
<alyssa>
IRC debugging: faster than Twitter! :p
<Lyude>
oops, *vulkano
<karolherbst>
Lyude: there is MaybeUninit in rust
HankB_ has quit [Remote host closed the connection]
HankB_ has joined #dri-devel
<jekstrand>
karolherbst: Why do you need to know you have a mapping?
<karolherbst>
jekstrand: because I have to update the content of the shadow buffer or GPU buffer when the client maps again
<jekstrand>
create a new one every time?
<karolherbst>
wellll.... no
<karolherbst>
so
<karolherbst>
imagine the client maps at the same offset 5 times
<karolherbst>
and now it unmaps with the returned pointer
dviola has quit [Remote host closed the connection]
<karolherbst>
which mapping do you kill?
Guest1501 has quit [Ping timeout: 480 seconds]
<karolherbst>
keep in mind: they can have different sizes
<jekstrand>
If you create a new one every time, they get 5 maps and you kill whichever one they just unmapped
ybogdano has quit [Ping timeout: 480 seconds]
<jekstrand>
You only need two cases: Persistent, unmap does nothing. Shadow, each map is unique and you create a new one every time.
<karolherbst>
what if the returned pointer is every time the same?
dviola has joined #dri-devel
<jekstrand>
That's the persistent map case
<jekstrand>
Or else you're overcomplicating things
<karolherbst>
sure, but they can have different sizes
<karolherbst>
so you map at +0x100 with 0x50 as the size, then with 0x100 in size. the returned pointer is the same
<karolherbst>
which mapping do you kill on unmap?
<jekstrand>
For persistent maps, you map the whole thing either on allocation or the first time someone tries to map it. From then on map just computes "base_map + offset" and unmap does nothing. You tear down the map when the memory object is destroyed.
<karolherbst>
okay, then we will go with map the whole thing
<karolherbst>
but we can have multiple write mappings which don't overlap
<karolherbst>
so I still have to synchronize part of it
<karolherbst>
well.. probably not for persistant ones
<jekstrand>
If we really care about GPUs with lots of memory with a 32-bit app, we may have to re-consider but as long as we can assume a 64 or 48-bit CPU address space, we don't need to care about leaving maps lying around.
<karolherbst>
yeah.. I am not concerned about too many maps
<karolherbst>
I am concerned about what to unmap
<jekstrand>
There aren't multiple write mappings. There aren't multiple mappings. In this case, there is one map for the lifetime of the cl_mem, everyone gets an offset into it, and unmap is a no-op. There's nothing to synchronize.
<karolherbst>
yeah.. well unless you drop the last one
<karolherbst>
okay, I think I have some idea on how to do it now
<jekstrand>
cool
RSpliet has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: how much of a runtime overhead in iris are mappings with PIPE_MAP_PERSISTENT?
mhenning has quit [Quit: mhenning]
mhenning has joined #dri-devel
<karolherbst>
specifically resources with PIPE_RESOURCE_FLAG_MAP_PERSISTENT?
<karolherbst>
although I am sure that sucks with discrete GPUs
<jekstrand>
On integrated, zero.
ybogdano has joined #dri-devel
<jekstrand>
GPU and CPU even share a last-level cache so everything's always coherent and you don't even have to flush to main memory.
<karolherbst>
I am wondering if we should _try_ to create a persistent mapping and use that, if not, do some fallbacks
<jekstrand>
For buffers, yes. For images, probably not.
<karolherbst>
we don't need a coherent one as we would sync on our own
<karolherbst>
yeah.. I'd just rely on the driver to fail or not
<karolherbst>
oh well.. I need to implement the worst case anyway
<jekstrand>
Why is this kernel taking forever to compile?
<jekstrand>
value = 0x7fff8c0117c0 "__kernel void test(__global long *srcA, __global long *srcB, __global long *dst)\n{\n int tid = get_global_id(0);\n\n dst[tid] = srcA[tid] + srcB[tid];\n}\n"
<jekstrand>
*sigh*
<karolherbst>
jekstrand: dunno?
<karolherbst>
does it?
<jekstrand>
LLVM is just not returning AFAICT
<karolherbst>
heh
<jekstrand>
I mean, it's got a reputation for long compile times but you wouldn't think a 1-liner would take forever. :D
<karolherbst>
:D
<karolherbst>
I am sure there is some valid reason
<karolherbst>
okay.. time to rewrite the entire map/unmap thing :)
<karolherbst>
but not today
<Lyude>
karolherbst: I think the problem is though figuring out the least cumbersome API to use without making things too implicit
<karolherbst>
yeah...
<karolherbst>
hard to judge without having seen the code
<karolherbst>
also I am a rust noob :p
<karolherbst>
somebody used clover to learn C++, so it's just fair I do the same with Rust :D
* karolherbst
is sure that when somebody looks at the code like in 10 years the scream and jump out of windows
tanty has joined #dri-devel
dviola has quit [Remote host closed the connection]
dviola has joined #dri-devel
i-garrison has quit []
i-garrison has joined #dri-devel
lemonzest has quit [Quit: WeeChat 3.4]
<jekstrand>
I'm starting to think LLVM is failing at threading...
<jekstrand>
🤯
<mhenning>
anholt: how soon are you hoping to land 8044 ?
<mhenning>
I was hoping we'd have a release with glsl-to-tgsi still present after the default switched to something nir-based for the sake of debugging nvc0, but I realize we're holding things up here.
<mhenning>
In my tests, native-nir on kepler actually fixes more tests than it regresses at this point, so I could imagine us turning that on sometime soon - although there are still tens of test regressions when flipping that switch
<mhenning>
I tried a test run with ntt on nvc0 ~a week ago and it regressed a lot of stuff (more than 1200 test regressions)
<anholt>
mhenning: I have nvc0 coming hopefully in a day or two, I'll make sure it's pretty healthy before we flip the switch.
<mhenning>
okay, that helps :)
<mhenning>
fwiw, I've been trying to chip away at the native-nir regressions
<anholt>
I've noticed! definitely excited to see that happening.
<anholt>
I am expecting to find a few more ntt fixes for nvc0, since I think that's going to be the most feature-rich driver that ntt has seen.
<mhenning>
That's fair
<anholt>
and, given the atomics changes, it'll need a bit more perf testing than nv50 got (though nv50 testing was mostly limited by how it just hangs left and right)
<karolherbst>
jekstrand: how so?
<karolherbst>
ohh parallel compilations?
<karolherbst>
uhm....
<jekstrand>
karolherbst: Yeah
<karolherbst>
I did not look at that _at_all_ yet
<karolherbst>
maybe I should
<karolherbst>
maybe llvm or clc are not thread safe :)
<jekstrand>
It seems to be getting stuck in llvm::TargetRegistry::lookupTarget
<alyssa>
anholt: very excited for 8044
<karolherbst>
jekstrand: I would assume something racey happens
<karolherbst>
*racy?
<jekstrand>
karolherbst: Yeah. I'm not immediately seeing what, though. :-/
<karolherbst>
try b_sanitize=thread :D
Duke`` has quit [Ping timeout: 480 seconds]
<karolherbst>
but that's spammy as hell
<karolherbst>
I saw some issues though
<karolherbst>
one reason I started to fix up the helper context stuff as well
<karolherbst>
there are many false positives though
<karolherbst>
:/
<karolherbst>
somehow it can't see that I use stuff in event tasks and thinks it races :/
<mhenning>
anholt: also, 14386 should help with the atomic counter failures with ntt on nvc0
<anholt>
yeah, not sure why that MR is stalled out?
<mhenning>
I don't know if any of the other stuff I have in flight will fix things there
<anholt>
I also still don't understand why nv thinks that atomic counters should have different cache behavior than ssbos
RSpliet has joined #dri-devel
<mhenning>
imirkin, karolherbst: any comments on the latest version of 14386 ?
<mhenning>
it isn't that atomic counters have different behavior than atomics in ssbos - nouveau just had broken atomics in ssbos before
<mhenning>
and the atomic counter stuff hacks around that
<anholt>
so we don't need the ATOMIC flag in TGSI on atomic-counters-lowered-to-ssbos after your MR?
<mhenning>
nope, it won't be necessary for correctness
<anholt>
excellent
<mhenning>
although the code generated is different, so there could be perf implications
LexSfX has quit [Ping timeout: 480 seconds]
LexSfX has joined #dri-devel
<anholt>
cool. apparently all of my shader-db doesn't have any instances of atomic access, except for gfxbench carchase.
rkanwal has quit [Ping timeout: 480 seconds]
<jekstrand>
anholt: We really need to add more UE4 content, then. UE4 is pretty atomic-heavy.
<jekstrand>
But the demos may not be.
<jekstrand>
anholt: Oh, do you have the "open" shader-db?
<anholt>
I synced up with Kayden some time post-intel
<anholt>
I was mostly using shader-db to see if I could even come up with a benchmark we could use for nvc0 atomics.
<jekstrand>
nvc0 needs a Vulkan driver for these things....
<jekstrand>
karolherbst: Now iris is running out of BOs. :D
* jekstrand
needs to find the leak
<karolherbst>
oh no :(
<karolherbst>
jekstrand: probably some non atomic counter
<karolherbst>
I had to fix some stuff for lp as well
<jekstrand>
karolherbst: It may be unrelated.
<jekstrand>
Annoyingly, it takes a while to get it to blow up
<karolherbst>
so I wouldn't be surprised if iris has something like that as well :)
<karolherbst>
but yeah.. could be something else
<karolherbst>
maybe we take too many refs or ... something
icecream95 has joined #dri-devel
paulk2 has joined #dri-devel
heat_ has quit [Read error: No route to host]
heat has joined #dri-devel
<macromorgan>
hate to be a bother, but is there a way to get a patch series looked at again? (should I ping someone or just resubmit it?)
paulk1 has quit [Ping timeout: 480 seconds]
<Lyude>
macromorgan: just ping folks if no one's looking
<macromorgan>
okay, thanks
<macromorgan>
it's some drm stuff I had the raspberry pi folks backport (while I was upstreaming the work). The raspberry pi kernel already accepted it while the upstream stuff is still in limbo.
Haaninjo has quit [Quit: Ex-Chat]
<jekstrand>
karolherbst: Looks like this test uploads 4GB of kernels. :-/
<jekstrand>
karolherbst: We need some shader caching somewhere. Not sure if iris should be doing something or rusticl.
Lightsword has quit [Quit: ZNC]
<jekstrand>
Kayden: Does iris have any nir-hash-based caching?
xroumegue has quit [Ping timeout: 480 seconds]
gouchi has quit [Remote host closed the connection]
<Kayden>
see ish->nir_sha1
<jekstrand>
Kayden: That says disk cache. Do we have an in-memory cache?
<Kayden>
for detecting isomorphic shaders and coalescing them to the same state objects? no. there's u_live_shader_cache for that, and idr had been looking at hooking it up, and I think has some code, but there were some bugs and it got left by the wayside for now
demarchi has quit [Remote host closed the connection]
<jekstrand>
Ok
<Kayden>
we should probably do that...
<jekstrand>
It's also likely that rusticl is leaking kernels
<jekstrand>
Because destroying the compiled shader should free it, right?
demarchi has joined #dri-devel
xroumegue has joined #dri-devel
Lightsword has joined #dri-devel
<Kayden>
if you delete the shaders they should mostly go away, yes
<Kayden>
some bits may hang around for a while
<Kayden>
for example...the BO might contain the assembly for multiple shaders. it'll hang around and we won't reuse that space until all of them are dead
<Kayden>
which works fine if you temporally make shaders, then delete the shaders from that time-period. it could be an issue if you hang on to every other shader
<Kayden>
also, shader variants will live on as long as they're bound
<Kayden>
but if you unbind them they should go away
<Kayden>
it's unfortunately just refcounting all the way down
alyssa has quit [Quit: leaving]
<Kayden>
pipe_shader_state (iris_uncompiled_shader) has refcounts, iris_shader_variants have refcounts, the BO with the assembly has a refcount
<jekstrand>
Yeah
<jenatali>
jekstrand: Which test?
<jekstrand>
test_integer_ops long_math
<jenatali>
Sounds like a leak... I don't remember any ridiculous number of kernels growing out of control when I was running those
<jekstrand>
Yeah, it's only compiling 184 kernels at a time. That should be fine.
<jekstrand>
So someone's leaking.
<jekstrand>
I'll have to look into it later.
<jekstrand>
It's week-end
mszyprow has joined #dri-devel
Company has quit [Quit: Leaving]
ahajda has quit [Read error: Connection reset by peer]
danvet has quit [Ping timeout: 480 seconds]
caef^ has quit [Remote host closed the connection]
<karolherbst>
jekstrand: rusticl uses the driver shader_cache for the libclc nir shader and I planned to use it for OpenCL C -> spirv and spirv -> nir things as well, but no good idea yet how
<karolherbst>
jekstrand: there is one huge issue though, so CL applications tend to create kernels from an existing program thing and normally runtimes are expected to compile down to the hardware when creating the program, not kernel
<karolherbst>
I am atm not sure on how to implement that, because that requires the cso to be either shareable or created by a screen
<karolherbst>
well.. I guess we could preprocess it
rsripada has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
nchery has quit [Remote host closed the connection]
rsripada has joined #dri-devel
<karolherbst>
and generate all the nirs at least when compiling the programs
stuartsummers has quit [Remote host closed the connection]
nchery has joined #dri-devel
stuartsummers has joined #dri-devel
pcercuei has quit [Quit: dodo]
<karolherbst>
jekstrand: I can check if we leak the kernel objects, could be the case actually
<karolherbst>
or... something else
<karolherbst>
anyway.. have to fix mapping first :D
jfalempe has quit [Remote host closed the connection]
jfalempe has joined #dri-devel
calebccff has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
mszyprow has quit [Ping timeout: 480 seconds]
zamundaaa has quit [Quit: ZNC 1.8.2+deb1+bionic2 - https://znc.in]