<jenatali>
I don't have something better, but I don't like it
<airlied>
so much lack of ABI and things work by happy accident
Danct12 has joined #dri-devel
* airlied
fixed const by setting setPreserveOCLKernelArgTypeMetadataThroughString
<airlied>
and parsing the strings
<airlied>
though I think my wrapper changes broke something else :-O
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
Danct12 has quit [Quit: Quitting]
gpoo has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
Danct12 has joined #dri-devel
nchery is now known as Guest3771
nchery has joined #dri-devel
nchery has quit []
mattrope has quit [Read error: Connection reset by peer]
Guest3771 has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
hikiko has joined #dri-devel
<airlied>
okay opencl cts api/basic/compiler are all passing for me now with my current hackfest :-P
<airlied>
(granted I've turned off images and 64-bit)
<airlied>
64-bit->doubles
<HdkR>
Anything special about 64bit?
<HdkR>
Beyond regular shader compute 64bit problems I guess :)
<airlied>
doubles fail some tests wierdly
<airlied>
i.e. segfault inside my compute JIT code
<HdkR>
oops :D
<airlied>
I suspect cosh(fp64) is doing something strange :-P
<HdkR>
Signaling NaN being mean or something?
<airlied>
might be calling a library funciton
<airlied>
or some global lut
danvet has joined #dri-devel
* airlied
is trying to get to at least a CL 3.0 baseline then I can add back the features
khfeng has quit [Remote host closed the connection]
khfeng has joined #dri-devel
itoral has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
vivijim has quit [Remote host closed the connection]
rcf has quit [Quit: WeeChat 3.3-dev]
tzimmermann has joined #dri-devel
mlankhorst has joined #dri-devel
frieder has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
zzag has quit []
zzag has joined #dri-devel
hanetzer has quit [Quit: WeeChat 3.2]
rcf has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
<tjaalton>
mattst88: it did get built though, though there's one build test that fails (lp_test_arit) but it isn't fatal for the pkg build
thellstrom has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
thellstrom has quit [Quit: thellstrom]
i-garrison has quit []
pcercuei has joined #dri-devel
rasterman has joined #dri-devel
i-garrison has joined #dri-devel
Ahuj has joined #dri-devel
thellstrom has joined #dri-devel
vivekk has joined #dri-devel
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
pnowack has quit [Remote host closed the connection]
pnowack has joined #dri-devel
vivek has quit [Ping timeout: 480 seconds]
hwentlan has quit [Read error: Connection reset by peer]
hwentlan has joined #dri-devel
eric_engestrom has quit [Read error: Connection reset by peer]
steev has quit [Read error: No route to host]
eric_engestrom has joined #dri-devel
steev has joined #dri-devel
lemonzest has joined #dri-devel
i-garrison has quit []
shfil has joined #dri-devel
bcarvalho_ has quit []
vivekk has quit [Ping timeout: 480 seconds]
vivek has joined #dri-devel
bcarvalho has joined #dri-devel
muhomor has joined #dri-devel
vivek has quit [Ping timeout: 480 seconds]
frieder_ has joined #dri-devel
frieder has quit [Quit: Leaving]
frieder_ has quit []
<shfil>
iirc, gcn 1.1 has a hardware based dsp, is there any sdk to use/access it?
xexaxo_ has quit [Remote host closed the connection]
xexaxo_ has joined #dri-devel
frieder has joined #dri-devel
i-garrison has joined #dri-devel
<tomeu>
airlied: btw, just a heads up that I'm moving the deferred command stuff from lavapipe to src/vulkan, for drivers for GPUs with cmdstreams that cannot be emitted without knowing the framebuffer
<daniels>
emersion: re KMS logging, you could write your own arbitrary markers to /dev/kmsg
<emersion>
daniels: interesting, but only writable by root it seems?
<emersion>
which makes sense
<emersion>
can be useful when i'm debugging something, but not too much when i'm asking users for a log file
<daniels>
yeah, if it's readable as non-root then you might be able to do reads before/after each commit and pull that in to your gamescope logging?
muhomor_ has joined #dri-devel
<emersion>
doesn't seem like it's world-readable
<emersion>
dmesg is restricted nowadays
<emersion>
thanks for the pointers still
<emersion>
(the question wasn't for gamescope, it was for sway :P )
muhomor has quit [Ping timeout: 480 seconds]
<melissawen>
danvet, is the sched dependency series still missing acks? I want to rebase v3d changes on top of that sched changes already...
<melissawen>
at least I think that names won't change
jc_ has joined #dri-devel
<airlied>
tomeu: oh interesting, glad it useful beyong lvp
<airlied>
beyond
jc_ has quit []
jc44 has joined #dri-devel
<danvet>
melissawen, no tested-by yet from etnaviv
<danvet>
also I think a tested-by/reviewed-by from robclark would be nice
<danvet>
atm I think there's only some minor adjustments to comments and commit message I need to make
<tomeu>
airlied: will have to remove some lvp-isms, guess there was no problem falling back to the vulkan types
jkrzyszt has joined #dri-devel
JohnnyonFlame has joined #dri-devel
<danvet>
karolherbst, dropped my thoughts on your mail
<danvet>
usual disclaimer: might not apply, feel free to ignore :-)
flacks_ has quit [Quit: Quitter]
alatiera3022 has joined #dri-devel
anarsoul|2 has joined #dri-devel
flacks has joined #dri-devel
anarsoul has quit [Remote host closed the connection]
alatiera302 has quit [Ping timeout: 480 seconds]
Net147_ has joined #dri-devel
jc has joined #dri-devel
Net147 has quit [Read error: Connection reset by peer]
rcf has quit [Quit: WeeChat 3.3-dev]
rcf has joined #dri-devel
lynxeye has joined #dri-devel
<karolherbst>
danvet: cool thanks!
muhomor_ has quit [Ping timeout: 480 seconds]
itoral has quit [Ping timeout: 480 seconds]
imgui-quest has joined #dri-devel
Company has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
imgui-qu_ has joined #dri-devel
imgui-quest has quit [Read error: Connection reset by peer]
<zmike>
pepp: I think I finally got the last of the problem cases fixed...will look at updating the MR again soon
<zmike>
I'm checking it out on radeonsi now though and noticed an odd issue
<zmike>
how is z24s8 supposed to be sampled from in gallium semantics? it looks like radeonsi just treats this as z32 always?
xexaxo_ has quit [Read error: No route to host]
muhomor has joined #dri-devel
adjtm is now known as Guest3802
adjtm has joined #dri-devel
xexaxo_ has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
pcercuei_ has joined #dri-devel
HdkR_ has joined #dri-devel
lplc has quit [Ping timeout: 480 seconds]
tagr has quit [Ping timeout: 480 seconds]
HdkR has quit [Ping timeout: 480 seconds]
Guest3802 has quit [Ping timeout: 480 seconds]
mtretter has quit [Ping timeout: 480 seconds]
Namarrgon has quit [Ping timeout: 480 seconds]
valentind has quit [Ping timeout: 480 seconds]
pcercuei has quit [Ping timeout: 480 seconds]
tagr has joined #dri-devel
gpoo has joined #dri-devel
xexaxo has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
frieder_ has joined #dri-devel
frieder_ has quit []
imgui-qu_ has quit [Read error: Connection reset by peer]
<zmike>
my brain hurts too much right now to think about it very deeply
<zmike>
I slapped some duct tape on it for now and moved on
<imirkin>
there's an esp annoying bit with sampling depth where in glsl you want the single depth value, whereas in FF (and ARB programs?) you want it as (0,0,0,x)
<imirkin>
simplest if you just return it as (x,x,x,x) and let swizzling solve any problems
<mareko>
z24s8 is really just z24,z24,z24,z24
<mareko>
x24s8 is s8,s8,s8,s8, that's the swizzle
<mareko>
then apply the sampler view swizzle
<imirkin>
agreed.
lemonzest has joined #dri-devel
macromorgan has quit [Quit: Leaving]
thellstrom has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
ppascher has quit [Ping timeout: 480 seconds]
<jekstrand>
How nuts would it be to get an Android builder in CI?
<jekstrand>
Even just an NDK build would be sufficient. Just enough that we can stop breaking the Android build.
<jekstrand>
s/we/I/ 😂
<alyssa>
nuts
<jekstrand>
🥜🔩
<krh>
we have that
<krh>
for freedreno
<alyssa>
krh: oh hi
<jekstrand>
Can it be in Mesa CI?
<krh>
it is
<jekstrand>
Can we build the Intel drivers in that build?
<krh>
alyssa: hi!
<krh>
jekstrand: I think we should
<jekstrand>
krh: I suppose you're probably doing an ARM build there, though. So we'd probably need a different CI for x86 Android drivers.
<jekstrand>
krh: Does Android seriously not have zlib?
<krh>
jekstrand: do you need it without dumping?
<jekstrand>
No, but the dep goes all the way up to src/util so it's a real pain to decouple
* jekstrand
wonders how the ARM drivers do it
<imirkin>
what do you need zlib for?
<jekstrand>
The genxml we embed is zlib-compressed
<jekstrand>
We don't actually need it at runtime if we don't have batch decoding
<imirkin>
ahh, it's for batch decoding. i see.
<imirkin>
that wasn't immediately clear why you might need the genxml
<alyssa>
can't tell if my code is broken or the hardware
<jekstrand>
Why not both?
<alyssa>
wise.
<jekstrand>
Nah, just snarky
<imirkin>
but also wise :) assuming that there's only a single bug is why debugging goes wrong
<alyssa>
jekstrand: looking like maybe booth
<alyssa>
There is a buggy interaction between opaque output (bypassing the blender) and dithering with formats with <8 bits per channel (i.e. rgb5_a1)
shfil has joined #dri-devel
* cwabbott
fixes xfb bug and then immediately purges xfb knowledge
<imirkin>
cwabbott: can you teach me how to purge knowledge?
<jekstrand>
cwabbott: If only it were so easy....
<cwabbott>
well, it's more aspirational
<jekstrand>
Uh, oh.... Sanity jobs aren't running for some reason. :(
<cwabbott>
judging by how much knowledge I apparently purged since implementing GS streams for turnip, I think I did a good job
<jekstrand>
lol
<imirkin>
it all just sticks around for me :( like scars
JohnnyonFlame has quit [Read error: Connection reset by peer]
khfeng has quit [Ping timeout: 480 seconds]
<alyssa>
i find childhood memories easier to purge than details of the IEEE 754 spec
jc44 has joined #dri-devel
jc44 has left #dri-devel [#dri-devel]
<Sachiel>
replacing one traume with an even bigger trauma
gouchi has joined #dri-devel
<shfil>
also pumping lemma causes holes in brain
<shfil>
from cs this and ieee 754 I'm not able to forget
<alyssa>
shfil: you don't want to prove things are irregular?
<ajax>
who has an opinion about vulkan device uuids?
<shfil>
alyssa: I like, but we had tasks like this "Determine if language X a) is regular (construct minimal finite machine and justify it) b) is context-free but not regular (show it's not regular and make pda with justification of its correctness) c) show it's not context-free"
<alyssa>
Oof
<ajax>
this in re !12311 where i'm supposed to return the same device uuid from egl as from vulkan
<shfil>
usually on exam there were 2 tasks like this and construction of parser (for example lalr)
<ajax>
but i don't really have a way to do that? because one i don't think we're consistent across vulkan drivers and two an EXTDeviceEXT doesn't have any real driver state so it's not like i can call down to the driver for the answe
<jekstrand>
ajax: I may have opinions.
<jekstrand>
ajax: Why does EGL want device UUIDs?
<emersion>
jekstrand: sharing state between EGL and Vulkan
<emersion>
ajax: imho the "EGLDeviceEXT is generic and doesn't need any driver info" stance is getting a bit annoying
<emersion>
i have other cases where EGLDeviceEXT would need to probe the driver
<emersion>
to query the render node being used for instance
<jekstrand>
What extension is this? And was it written by Nvidia people? (probably)
<jekstrand>
emersion: Oh, so you're the one who asked for them to correlate. :P
<emersion>
ah, yes
<emersion>
it would make my life so much better :P
<jekstrand>
Sadly, it makes life a real PITA for the people who have to provide those IDs.
<emersion>
is it that much of a hassle?
<emersion>
well, apart from mesa's weird stake on EGLDeviceEXT
<emersion>
i imagine you coudl just have a single UUID generator in src/intel/ for both anv and iris
<jekstrand>
We do
<jekstrand>
intel_uuid.c
<emersion>
ok, nice. then what's the issue?
<jekstrand>
But it requires opening the DRM file descriptor and making kernel calls.
<emersion>
indeed
<jekstrand>
Not sure if that's a problem for EGL
<jekstrand>
Generally, I kind-of hate the Vulkan UUID system.
<jekstrand>
Maybe "hate" is too strong
<jekstrand>
I get why it's useful. But it's always seemed fragile to me.
<emersion>
because it's complicated to get them right?
<jekstrand>
And the rules are complicated.
<emersion>
right
<jekstrand>
It's supposed to persist across reboots, but what if you change your machine configuration?
<jekstrand>
If you have two identical cards and swap them, are the UUIDs supposed to follow the card? Or can they get swapped?
<jekstrand>
What if you change your RAM configuration? That means new UUIDs on Intel.
<emersion>
that's a "port vs sink" issue
<emersion>
ah, eh
<emersion>
that's fun
<jekstrand>
Yeah, the Vulkan spec has all sorts of weasel words so it only says they usually don't change and provides no hard guarantees whatsoever.
<emersion>
"port vs. endpoint" maybe better for this case
<emersion>
yeah
<jekstrand>
What if you're running in a VM? Should the guest and host match?
<jekstrand>
If they do match, is that a feature or a security hole?
ngcortes has joined #dri-devel
camus has joined #dri-devel
<jekstrand>
In the datacenter world, some people want an actual HW UUID so that, when a GPU breaks, can look at vulkaninfo and then look up in a spreadsheet somewhere to figure out which machine to fix.
camus1 has quit [Remote host closed the connection]
<jekstrand>
In the consumer world, a device UUID is a tracker. We don't want those.
<ajax>
emersion: re generic egldevice: omg yes
<alyssa>
jekstrand: loonix is spyware confirmed????
<jekstrand>
Anyway.... Now you all know why deviceUUID is thorny and why I kind-of hate that it exists. :)
jernej has quit [Remote host closed the connection]
<ajax>
jekstrand: intel_uuid.c and freedreno_uuid.c do different things
frieder has quit [Remote host closed the connection]
<ajax>
so unless libegl can get this out of the driver itself, it also can't just copy whatever the driver does
K`den has joined #dri-devel
Kayden has quit [Read error: Connection reset by peer]
K`den is now known as Kayden
<emersion>
would it be acceptable to load drivers on egl device enumeration?
<jekstrand>
ajax: Yup. You have to get it out of the driver.
<alyssa>
VNC is magical
<jekstrand>
I mean, I guess we could probably stop hashing in the bit6 swizzle. It probably wouldn't cause any actual issues in practice.
<jekstrand>
But oof
<ajax>
emersion: i mean... probably. you're not going to enumerate them unless you intend to load something, and there's only one driver binary anyway....
<jekstrand>
If we did that, then it'd just be PCI ID.
<ajax>
i wouldn't create a screen or anything
<jekstrand>
So a hash of PCI ID and PCI path would probably work for PCI-based devices.
<bnieuwenhuizen>
wait, was it supposed to be a hash
<jekstrand>
ajax: Currently, Intel requires a screen to get the UUID
<jekstrand>
bnieuwenhuizen: Doesn't have to be
<emersion>
it's just bytes
<ajax>
jekstrand: you're being too clever with the bit6 thing, i think. at least from egl's perspective.
<robclark>
for non-pci devices, there isn't really a way to get you a uuid without opening the device file
<robclark>
(OTOH it isn't like you are going to have both a mali and adreno gpu on the same SoC)
<bnieuwenhuizen>
robclark: who knows with our potential chiplet future?
<robclark>
heh
<emersion>
but could you have something like two mali drm devices on the same SoC?
<robclark>
I wouldn't expect it.. maybe having separate 2d and 3d cores (but the former isn't going to have much to do with egl)
<jekstrand>
ajax: If someone ever scrapes the contents of a VkDeviceMemory object and saves it to disk along with UUIDs, we may have a problem.
<ajax>
jekstrand: if they did that without also keying their hash to the driver uuid? i'd call that a sin.
<bnieuwenhuizen>
or they better be using modifiers
<ajax>
*shrug* i don't really care how the driver does it, and _ideally_ it would be by calling down to the driver so it can do whatever it needs, even if that's often just "hash the pci address and device ids"
<emersion>
agreed
<ajax>
but that's also kind of a lot of work when all i really want right now is the DeviceQueryString bit
<ajax>
no good yak goes unshaved i guess
jernej has joined #dri-devel
jessica_24 has quit [Ping timeout: 480 seconds]
<emersion>
is it really that much work?
<jekstrand>
ajax: Yeah, but if they pull out a stick of RAM and reboot, they'll get the same driver UUID since the driver hasn't changed but, as far as memory tiling goes, they have a different GPU now.
jessica_24 has joined #dri-devel
<emersion>
"just" need to establish a new DRI driver extension for EGL devices, plumb gallium…
<ajax>
you'd get the same driver uuid if all you computed that from was the git hash
<jekstrand>
We could probably move that to the driver UUID, though. I'd have to look at the rules.
<ajax>
but that's the place where i'd stash things like swizzle conventions
<jekstrand>
There are other cases too where "is it the same GPU" requires kernel interactions.
Company has quit [Read error: No route to host]
<jekstrand>
But those only affect shader compiles and that's allowed to change at the drop of a hat
Company has joined #dri-devel
<dcbaker>
bnieuwenhuizen: "b2b1e8e40a radv: Use correct signedness in misalign test." doesn't apply at all to the 21.2 branch, the function it patches up isn't in the branch
<dcbaker>
what would you like me to do about it
lynxeye has quit []
JohnnyonFlame has joined #dri-devel
<kisak>
dcbaker: hmm? it applied cleanly to my 21.2.0 PPA build without alteration.
* kisak
goes and checks it
<dcbaker>
For me the entire function becomes an insertion
lemonzest has quit [Quit: Quitting]
<bnieuwenhuizen>
dcbaker: I think it got moves from src/amd/vulkan/radv_cmd_buffer.c
<bnieuwenhuizen>
moved*
<dcbaker>
I did some `git grep` and couldn't find it, let me look again
<dcbaker>
well sure enough, my git grep-foo failed me
<bnieuwenhuizen>
you found it now?
<dcbaker>
yeah, it did move
<dcbaker>
now why can't git figure that out...
<bnieuwenhuizen>
cool, thanks!
<dcbaker>
This might be the dumbest git cherry-pick issue I've ever seen
<dcbaker>
It can't figure out that the function moved in the same file
<kisak>
ah, so the difference is that patch -p1 figured it out over here instead of git cherry-pick
<airlied>
jekstrand: could.move.uuid gen to kernel
<ajax>
now we're talking
<airlied>
just have it in sysfs
<DrNick>
you mean /proc/sys/kernel/random/uuid
<DrNick>
oh a per-driver UUID nvm
<emersion>
i mean that technically is a valid driver UUID :P
<alyssa>
UUID=$(hexdump /dev/urandom | head -n 1)
<alyssa>
the "u" stands for "UUID"
<alyssa>
anholt_: looks like LAVA needs some changes for suite support..?
boistordu_ex has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
<airlied>
I think Windows does a uuid device id in the kernel level
<airlied>
danvet: ooh merging greg trees, what fun :-P
<danvet>
airlied, tbh I'm not sure we have to, the conflict looks very simple and will keep linus busy
<danvet>
otoh it also doesn't hurt
<airlied>
danvet: I'll pull it in and see how it goes :-P
dviola has quit [Remote host closed the connection]
* airlied
ponders put CL CTS into CI for test basic/api at least
muhomor has joined #dri-devel
muhomor_ has quit [Ping timeout: 480 seconds]
<jenatali>
airlied: it'd be even better if we could add it as CI for the SPIRV-LLVM-Translator
<jenatali>
But I'm onboard with putting it in ours. We've got CL piglits already
macromorgan has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
<alyssa>
jenatali: x q no los 2
imre has quit [Remote host closed the connection]
<mdnavare>
danvet: airlied: Do we know if with AMD Hybrid gfx, they support the clone mode with displays connected on DG + IG
boistordu_ex has quit [Remote host closed the connection]
<mdnavare>
danvet: How can this be supported in general in KMS, since now the same buffer needs to scanned out across device boundaries and it cannot be pinned to just lmem or smem
<airlied>
mdnavare: I think clone in that scenario is just the compostior creating two scanouts with same content
<airlied>
or one GPU has a shadow copy that is synced from the main compositor
<airlied>
but I can't say I've ever tried/tested anything like that
imre has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
<mdnavare>
airlied: Yes the concern is that if it has to scanout on IG and DG then the buffer needs to be on smem as well as lmem, since the DG cannot scanout from smem so how does that work
<agd5f>
mdnavare, hw doesn't support it. IG can't scan from dGPU vram and dGPU can't scan from sys mem.
<agd5f>
plus, it's likely the 2 GPUs have different tiling requirements
boistordu_ex has joined #dri-devel
<alyssa>
jekstrand: this is probably obnoxious but is (('fabs', ('ftrunc', a)), ('ffloor', ('fabs', a))) valid? 😋
<mdnavare>
agd5f: So this use case where displays connected across IG and DG in cloning mode is not supported by AMD?
<jekstrand>
alyssa: Uh.... maybe?
sdutt has quit [Ping timeout: 480 seconds]
<jekstrand>
krh: Ugh.... This Android build is getting annoying. It tries to build via a cross file but with the regular build scripts. The regular build scripts build tests. Our tests require expat because, hey, we test genxml. :-/
<jekstrand>
This might need some anholt_ magic...
Duke`` has quit [Ping timeout: 480 seconds]
<robclark>
jekstrand: maybe disable those tests if with_platform_android?
<robclark>
or maybe there is a way to check for expat dependency?
sdutt has joined #dri-devel
sdutt_ has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
xexaxo has quit [Read error: Connection reset by peer]
<karolherbst>
what are current OpenGL drivers do once they notice the GPU context is gone? I know that some drivers try to recover, but what are the ones doing which do not try such an attempt?
xexaxo has joined #dri-devel
<agd5f>
mdnavare, I think most compositors handle it automagically
<robclark>
karolherbst: in userspace or kernel? drm/msm attempts to replay submits after the faulting one.. userspace does nothing (other than report the context-lost if the application asks)
<karolherbst>
robclark: userspace
<agd5f>
mdnavare, just another case of cross GPU multi-head
<imirkin>
robclark: but userspace gets away with it because kernel replays submits ... and the context isn't completely gone, just that submit failed
<robclark>
right.. I'm not sure how/what userspace could try to do.. kernel seems to be the better place to handle that
<karolherbst>
robclark: well.. sure, in our case nouveau reaps the channel
<karolherbst>
but because we don't have this "wait on this fence ioctl", we do busy waiting
<karolherbst>
it's stupid, I know
<karolherbst>
but anyway
<karolherbst>
once we detect that our channel/context is gone, we have to handle it somehow
<imirkin>
really the "Wait on this fence" thing should be an ioctl
<imirkin>
rather than being done in userspace like we do
<karolherbst>
yeah, it should be
<imirkin>
the kernel can wait on it with an interrupt
<imirkin>
so it wouldn't have to spin
<imirkin>
("with an interrupt" -> "by making hw report an interrupt when the fence is reached")
<karolherbst>
well if the kernel would busy loop that would already be better because checking for a dead channel there is essentially for free :O
<karolherbst>
but yeah...
<karolherbst>
but other drivers also don't have this GPU context thing as nvidia does
<karolherbst>
so the question is a different one anyway
<karolherbst>
and it maps terribly to other drivers
<karolherbst>
maybe "how do you handle the case once submissions from userspace can't be worked on anymore"
<imirkin>
hw contexts are definitely a thing
<imirkin>
in non-nvidia hardware
<karolherbst>
sure, but differently
<imirkin>
but they don't magically die forever
<imirkin>
(afaik)
<karolherbst>
yeah.. dunno for sure
<karolherbst>
but I think none other driver hands out a GPU context if userspace asks for one
<airlied>
I'm broken on the inside, please somebody fix me.. ruh roh
<robclark>
imirkin: for added fun, in adreno land (and I guess amd too) "context" is something completely different.. it is really the context or state for a given draw
sdutt_ has quit [Ping timeout: 480 seconds]
<imirkin>
on nvidia it's the register state backing + mystery
* karolherbst
gives WD-40 and tape to airlied
<airlied>
anholt_: marge having issues or gitlab?
<robclark>
yeah, it's the register state backing on adreno too.. but you can have different parts of the pipeline chewing on different draws each looking at their own "current" view of the register state
HdkR_ is now known as HdkR
<HdkR>
For when duct tape doesn't work. Gorilla tape
<robclark>
airlied: I think anholt is out this week.. maybe daniels can look?
<daniels>
as ever, links really help please
<imirkin>
daniels: cgit is unresponsive :)
<daniels>
wooho
<daniels>
airlied: just looked and no logs for your failure but is generally working totally fine, just try again
<agd5f>
yeah, on AMD hardware, the context is a pipeline state. The CP firmware handles the context state rolls to keep everything pipelined.
jc has quit [Remote host closed the connection]
<agd5f>
There are also GPUVM contexts on AMD hardware which represent a GPU virtual address space
<agd5f>
Those are explicitly controlled by the driver
gouchi has quit [Remote host closed the connection]
adjtm has quit [Ping timeout: 480 seconds]
adjtm has joined #dri-devel
sdutt has joined #dri-devel
<imirkin>
on nouveau (and nvidia blob), the driver ties gpu vm + hw context state together, but technically they're unrelated
<imirkin>
but in practice, since the hw context contains tons of VA addresses, probably not a great idea to mix and match :)
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
<karolherbst>
imirkin: well, but you can create a new context and keep the old vm
<imirkin>
yea
<alyssa>
airlied: I'm looking at IEEE 754 compliance of fpow
<karolherbst>
alyssa: uhhh
<karolherbst>
why?
<alyssa>
meh
<imirkin>
if that doesn't call for duct tape, i don't know what does...
<alyssa>
AFAICT, the fpow lowering we have in NIR is wrong for some of the special cases.
<karolherbst>
alyssa: correct
<karolherbst>
but
<alyssa>
but probably nothing cares except for CL, and for CL we call out to libclc unless native_ or half_ is used, so it's fine?
<karolherbst>
it's easy to fix
<karolherbst>
alyssa: we have correct lowering in codegen.. wait
<alyssa>
jenatali: ^ as well
<imirkin>
karolherbst: we have a 0*x = 0 mul variant
<karolherbst>
alyssa: the yeah is that the MUL has to flush denomrs
<karolherbst>
*denorms
<imirkin>
i don't think that's generally available
<karolherbst>
s/yeah/key/
<imirkin>
karolherbst: dnz != ftz
<imirkin>
karolherbst: dnz = zero wins
<karolherbst>
ohhhhh
<karolherbst>
right
<alyssa>
imirkin: we do as well, that fixes a bunch of special cases
<alyssa>
but what about, like
<alyssa>
pow(0, k) = +inf
<karolherbst>
alyssa: so we need a mul in nir with a "zero wins" behaviour
<karolherbst>
alyssa: that's fine
<alyssa>
where k is a negative odd integer
<karolherbst>
The result is undefined if x<0 or if x=0 and y≤0.
<imirkin>
---^
<imirkin>
that.
<alyssa>
I'm looking at the IEEE 754 spec, what are you looking at?
<imirkin>
don't do that. :)
<karolherbst>
alyssa: the glsl spec
<alyssa>
I imagine OpenCL has stricter rules..?
<karolherbst>
let's check
<alyssa>
(With the NIR lowering, you get log2(+0) = +inf, +inf * k = -inf, exp2(-inf) = +0)
<alyssa>
..I think
<jenatali>
alyssa: You can look at the libclc implementation
<alyssa>
wait log2(0) should be -inf
<alyssa>
is this bifrost being stupid
<karolherbst>
alyssa: yeah.. for CL you should just use libclc pow
<imirkin>
all i know is that inf - inf = log(2)...
<alyssa>
-inf & k = +inf, exp2(+inf) = +inf is ok. right..
<karolherbst>
hence CL to have powr
<mdnavare>
agd5f: How does the compositor solve the issue here of scanning out the same buffer on IG as well as FG i mean across multi GPUS? Does it kind of maintain 2 copies somehow? But that means the driver doesnt need to do anything special here?
<alyssa>
jenatali: what about for half_pow(r)
<karolherbst>
alyssa: the hardware isn't precise enough for pow anyway
<karolherbst>
so you have to use libclc
<alyssa>
Yeah, that's the real issue indeed.
<karolherbst>
unless you have a real pow instruction
<karolherbst>
and even that could fail
<karolherbst>
but I doubt it
<mdnavare>
agd5f: I understand that extended case it would just create 2 separate buffers and scanout from respective memories but clone mode how does compositor solve the cross memory problem
<karolherbst>
I mean.. that any hw has real pow
<jenatali>
alyssa: It's the same rules for specials, but for non-specials it just needs 10 bits of accuracy
<karolherbst>
alyssa: so powr -> fpwo and pow -> libclc pow
<karolherbst>
I think
hanetzer has joined #dri-devel
<karolherbst>
but that's always the issue with lowering those buitlins
<karolherbst>
same issue with sqrt
<alyssa>
meh I'm going to say the NIR lowering with zero-wins is good enough :p
<karolherbst>
alyssa: for powr maybe :D
<karolherbst>
"powr Computes x to the power of y, where x is greater than or equal to 0."
thellstrom has quit [Remote host closed the connection]
<alyssa>
until someone pays me(collabora) for opencl i can pretend this doesn't exist..
thellstrom has joined #dri-devel
<karolherbst>
alyssa: we already have libclc support :p
<karolherbst>
ohhh wait
<karolherbst>
we already use libclcs impl for CL
<alyssa>
Ohh there's no half_pow, derp
<karolherbst>
so...
<alyssa>
got it got it thanks
<karolherbst>
alyssa: ohh, that as well
<agd5f>
mdnavare, Do wayland based compositors even support single buffer clone mode?
nirmoy has quit []
<agd5f>
I thought they always did per display buffers even for clone
<alyssa>
karolherbst: Maybe it'd be clearer if we renamed the NIR op to fpowr?
<karolherbst>
alyssa: meh
<karolherbst>
but maybe?
<karolherbst>
we can think about it once there is a GPU with native and correct pow support :)
<karolherbst>
imirkin: did you know that we have nativ tanh support? :O
<karolherbst>
since turing actually
<karolherbst>
the hell
<HdkR>
Turing is cute like that
<karolherbst>
I was already surprised by that sqrt in maxwell2
<imirkin>
karolherbst: i did not.
<imirkin>
i barely know what tanh is.
<karolherbst>
hyperbolic tangent
<imirkin>
+ instead of - iirc?
<imirkin>
oh, yes, that explains it exactly.
<karolherbst>
I think it's only important for CL actually...
<imirkin>
tan = a / b. what's tanh? :)
<karolherbst>
sinh / cosh :)
<imirkin>
anyways, iirc the hyperbolic ariants are like e^x + e^-x instead of e^ix - e^-ix or whatever?
<karolherbst>
something
rsripada has quit [Remote host closed the connection]
rsripada has joined #dri-devel
ramaling has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
Ryback_ has quit [Remote host closed the connection]
ramaling has joined #dri-devel
<karolherbst>
"In mathematics, hyperbolic functions are analogues of the ordinary trigonometric functions, but defined using the hyperbola rather than the circle"
<imirkin>
but what that signifies on a right triangle ... unclear.
<imirkin>
i know what hyperbol*e* is ... what's a hyperbola?
mattrope has quit [Remote host closed the connection]
vivijim has quit [Remote host closed the connection]
vivijim has joined #dri-devel
<karolherbst>
sinh x = (e^x - e~-x) / 2
<karolherbst>
ehh
<karolherbst>
sinh x = (e^x - e^-x) / 2
Kayden has quit [Remote host closed the connection]
unerlige has quit [Remote host closed the connection]
vivek has quit [Remote host closed the connection]
mattrope has joined #dri-devel
<imirkin>
right. and sin has the i's in it.
<alyssa>
imirkin: the shape of the shadow cast by a lamp that's open on both ends.
unerlige has joined #dri-devel
shankaru has quit [Remote host closed the connection]
shankaru has joined #dri-devel
<imirkin>
alyssa: closest i remember is a hyperbolic parabolloid, which is a saddle.
Kayden has joined #dri-devel
<karolherbst>
imirkin: yeah, something like that
<karolherbst>
I am wondering why tanh...
<imirkin>
they don't really teach geometry (or spatial concepts) in USA, so i'm pretty weak on all that stuff.
<karolherbst>
I am wondering if that's precise enough for CL actually
<karolherbst>
and if a hw tanh makes lowering of the other functions much easier or so
<karolherbst>
I am sure nvidia had a very good reason to put it in there
Ryback_ has joined #dri-devel
* imirkin
&
<karolherbst>
ohh apparently machine learning uses tanh for... some stuff
<karolherbst>
inside activation functions of neurons
<karolherbst>
ehh
<karolherbst>
without the "of neurons"
<alyssa>
karolherbst: this is true
<karolherbst>
interesting
<alyssa>
although their use of it has nothing to do with the geometry
<alyssa>
and everything to do with "well, it's vaguely S shaped"
<karolherbst>
a pretty flat S
<karolherbst>
but I am wondering if libclc uses tanh actually and if it can make lowering of the others faster as well
<karolherbst>
mhh, at least not atm
hanetzer has quit []
shfil has quit [Quit: Konversation terminated!]
pcercuei_ has quit []
imre has quit [Ping timeout: 480 seconds]
iive has quit []
<jekstrand>
robclark: Disabling the tests should work. Thanks!
<robclark>
np
vivijim has quit [Ping timeout: 480 seconds]
<jekstrand>
Oof. This Android CI MR is finding so many little things...
mdnavare has quit [Remote host closed the connection]
unerlige has quit [Remote host closed the connection]
mdnavare has joined #dri-devel
Kayden has quit [Remote host closed the connection]
shankaru has quit [Remote host closed the connection]
unerlige has joined #dri-devel
mbrost has quit [Remote host closed the connection]
Ryback_ has quit [Remote host closed the connection]
aswar002 has quit [Remote host closed the connection]
sdutt has quit [Remote host closed the connection]
aswar002 has joined #dri-devel
Ryback_ has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
pzanoni has quit [Remote host closed the connection]
mbrost has joined #dri-devel
Kayden has joined #dri-devel
pzanoni has joined #dri-devel
sdutt has joined #dri-devel
mattrope has quit [Remote host closed the connection]
ramaling has quit [Remote host closed the connection]
ramaling has joined #dri-devel
ngcortes has joined #dri-devel
dolphin has quit [Remote host closed the connection]
dolphin has joined #dri-devel
mattrope has joined #dri-devel
shankaru has joined #dri-devel
rsripada has quit [Remote host closed the connection]