ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<imirkin_>
and i sorta figured they knew what they were doing
alanc has quit [Remote host closed the connection]
<mwk>
if we're still talking Tesla, that'd because the 0*x = 0 setting is global for shader, not per-instruction
<imirkin_>
mwk: yeah
<imirkin_>
no clue where i looked
<imirkin_>
but the code i changed was in the nvc0-specific lowering
<imirkin_>
where it's per-op, as you know well
<mwk>
right
<imirkin_>
ah no, i changed both nv50 and nvc0
<imirkin_>
changed in c1e4a6bfbf015801c6a8b0ae694482421a22c2d9
<imirkin_>
can't say my memory of this day 5y ago is extremely crisp :)
<imirkin_>
"Secondly the current approach (x * rsq(x)) behaves poorly for x = inf - a NaN is produced instead of inf."
<mwk>
hmm
<imirkin_>
so i guess switching it to x * rsq(x) would work for nvc0, flipping the dnz flag on
<mwk>
doesn't 0*x = 0 still break it?
<mwk>
like inf * 0 is also 0
<imirkin_>
i just hadn't thought to flip it?
<imirkin_>
mwk: what's the problematic case?
<mwk>
x= Inf
<imirkin_>
oh right.
<imirkin_>
yes.
<imirkin_>
we could make it go NaN -> 0
<imirkin_>
but that's not what we want :)
<mwk>
yep
<imirkin_>
so we want 0*x = 0, but x*0 = x ;)
<mwk>
that might be a problem
<alyssa>
imirkin_: I have a .left mode
<alyssa>
with the semantic "(a == 0 || b == 0) ? a : (a * b)"
<imirkin_>
fun
<alyssa>
so i think I can do mul_left(x, rsq(x))
<mwk>
... huh
<imirkin_>
so then it should work?
<alyssa>
for x = 0, that is mul_left(0, inf) = 0
<alyssa>
for x = inf, that is mul_left(inf, 0) = inf
<alyssa>
...right?
<imirkin_>
seems so!
<alyssa>
the Arm driver uses that mode but actually it does something... even more funny
dliviu has quit []
<alyssa>
first it does a range reduction with a special sqrt mode of frexpm/frexpe
vivek has quit [Ping timeout: 480 seconds]
<alyssa>
then it does sqrt(m) with mul_left(X, rsq(x))
<mwk>
.. I seem to recall nvidia also did some exponent dance
<alyssa>
and then it biases the exponent of that with the result of frexpe / 2
<mwk>
but I don't recall if it was sqrt or div
<alyssa>
I guess it might have better precision but idk
<alyssa>
oh also, mul_left(NaN, rsq(NaN)) = mul_left(NaN, NaN) = NaN which is still right
dliviu has joined #dri-devel
orbea1 has joined #dri-devel
orbea has quit [Ping timeout: 480 seconds]
<alyssa>
oh even more fun, that's only for 32-bit
<alyssa>
for 16-bit on valhall, they do (x == 0)? 0.0 : (x * rsq(x)), with an ordinary multiply
<alyssa>
(and an explicit csel)
<alyssa>
uhmmm
<alyssa>
...but on Bifrost fp16 they just do mul_left(x, rsq(x))
<alyssa>
so I guess valhall removed fp16 mul_left
<mwk>
mul_left is such a cursed concept
<mwk>
I love it
<alyssa>
mwk: it's a massive FMA_RSCALE instruction that does (a*b + c) * 2^d with 4 saturation modes and 4 special case handling options and not all combinations are valid.
<alyssa>
real fun
<mwk>
mmmm
<alyssa>
and the rounding/special case handling is "wrong" so it's only used to lower transcendntals
<mwk>
"here, we give you all the control signals of the ALU, have fun"
<mwk>
lol
<alyssa>
yep yep :p
Lucretia has quit []
<HdkR>
mwk: Nvidia exponent dance should be removed on latest generations if I remember correctly :D
<mwk>
yeah, probably
<mwk>
I did look at it a *long* time ago
ngcortes has quit [Ping timeout: 480 seconds]
<HdkR>
Should be removed in Volta or Turing, I forget which. So quite new
pnowack has quit [Quit: pnowack]
ngcortes has joined #dri-devel
khfeng has joined #dri-devel
vivek has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
cef is now known as Guest3938
cef has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
Guest3938 has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
cef has quit [Ping timeout: 480 seconds]
cef has joined #dri-devel
<imirkin_>
is it expected that virgl-traces and zink-piglit-timelines sometimes fail?
<alyssa>
"is it expected that [....] sometimes fail?"
<alyssa>
the answer is no for any value of [...]
<alyssa>
daniels: ^
<imirkin_>
alyssa: not always. sometimes it's a known issue.
<imirkin_>
hence expected
<alyssa>
imirkin_: maybe this is an unpopular opinion, but if an issue is known the correct answer is to remove the job from CI on sight.
<imirkin_>
i'm such a rare contributor these days that i don't always know the current state of things
<jenatali>
I saw flakes in llvmpipe and stony traces the other day too
<jenatali>
I think if we applied the "if it flakes, remove it" philosophy we'd have basically 0 coverage :)
<alyssa>
jenatali: That seems pesimistic... CI should be rock solid. I suppose we've already had this discussion ... I can't remember the GLon12 CI flaking on me so you're good :0
<jenatali>
alyssa: Yeah we've already ratholed on it :P
<jenatali>
Our public CI is way better than our internal test automation :)
<alyssa>
(and correct me if i'm wrong but panfrost has been solid all summer?)
<jenatali>
I haven't been trying to merge enough changes to comment definitively, but I haven't seen it flake at least
<alyssa>
(I did a lot of work on the driver side to get things robust for CI, and daniels does /so/ much behind the scenes to keep the infrastructure happy)
<alyssa>
anyway errr back to hacking at PCIe
<airlied>
I hope you mean hacking a PCIe card with a hacksaw to fit into a 1x slot or something
cef has quit [Quit: Zoom!]
cef has joined #dri-devel
* airlied
has forgotten how many conversion tests CL CTS has, at 391 after 29 hrs
<jenatali>
airlied: I think you've still got a ways to go...
<jenatali>
I want to say it's ~800 or so
slattann has quit []
slattann has joined #dri-devel
orbea1 has quit []
<airlied>
jenatali: yeah my brain is saying ~900
<airlied>
I wonder have I got an old log file sitting around :-P
slattann has quit []
orbea has joined #dri-devel
<airlied>
I think it took 44 hrs last time
<jenatali>
I'm sure I do
<jenatali>
airlied: 765 is what I have in my log
<jenatali>
Oh, that's how many I ran... we skipped doubles. Total test count is 900
<airlied>
jenatali: ah cool, I'm skipping doubles as well in this run
<airlied>
so over half way there :-P
<jenatali>
Yeah...
<airlied>
or not actually, but close to it
<jenatali>
I mean props for making an exhaustive test, but damn do you really need to test every permutation of a vec16 with every possible integer?
<airlied>
yeah it's pretty messed up test strategy
<alyssa>
WTF
<airlied>
woah spending 30% of my time in a mutex unlock path
<jenatali>
:O
soreau has quit [Read error: Connection reset by peer]
soreau has joined #dri-devel
<airlied>
I assume the test is launching a kernel per integer
<jenatali>
It's not that bad
<airlied>
my threadpool is just going brrrrr
<jenatali>
They do a kernel for an array of vectors
* airlied
should possibly consider optimising this pathalogical corner case :-P
Danct12 has quit [Quit: Quitting]
Danct12 has joined #dri-devel
anujp has quit [Ping timeout: 480 seconds]
anujp has joined #dri-devel
jhli has quit [Ping timeout: 480 seconds]
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
mbrost_ has joined #dri-devel
boistordu_ex has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
thellstrom1 has joined #dri-devel
thellstrom has quit [Read error: Connection reset by peer]
<DrNick>
isn't there a CTS test that blends every color with every other color?
rcf has quit [Quit: WeeChat 3.3-dev]
Duke`` has joined #dri-devel
rcf has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
mattrope has quit [Remote host closed the connection]
slattann has joined #dri-devel
sdutt has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Read error: Connection reset by peer]
itoral has joined #dri-devel
mlankhorst has joined #dri-devel
K`den has joined #dri-devel
Kayden has quit [Remote host closed the connection]
danvet has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
rando25902 has joined #dri-devel
frieder_ has joined #dri-devel
frieder has joined #dri-devel
frieder_ has quit []
frieder has quit []
frieder has joined #dri-devel
rando25892 has quit [Ping timeout: 480 seconds]
K`den is now known as Kayden
Kayden has quit [Quit: reboot to try and fix some rubbish]
Ahuj has joined #dri-devel
Kayden has joined #dri-devel
rasterman has joined #dri-devel
Daanct12 has joined #dri-devel
agd5f_ has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
slattann has quit []
Lucretia has joined #dri-devel
itoral_ has joined #dri-devel
itoral has quit [Read error: Connection reset by peer]
camus1 has joined #dri-devel
pnowack has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
pochu has joined #dri-devel
slattann has joined #dri-devel
lynxeye has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
tzimmermann has joined #dri-devel
bcarvalho has joined #dri-devel
mlankhorst has quit [Ping timeout: 480 seconds]
slattann has quit []
nroberts has joined #dri-devel
MrCooper has quit [Remote host closed the connection]
slattann has joined #dri-devel
MrCooper has joined #dri-devel
mlankhorst has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
shfil has joined #dri-devel
jessica_24 has quit [Quit: Connection closed for inactivity]
lalbornoz has joined #dri-devel
lalbornoz has quit [Remote host closed the connection]
lalbornoz has joined #dri-devel
lalbornoz has quit [Read error: Connection reset by peer]
vivijim has joined #dri-devel
Daaanct12 has joined #dri-devel
xexaxo has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
lalbornoz_ has joined #dri-devel
lalbornoz_ has quit [Read error: Connection reset by peer]
pendingchaos has quit [Quit: No Ping reply in 180 seconds.]
pendingchaos has joined #dri-devel
pendingchaos has quit []
pendingchaos has joined #dri-devel
Company has joined #dri-devel
shfil has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
itoral_ has quit []
dogukan has joined #dri-devel
dogukan has quit []
dogukan has joined #dri-devel
dogukan has quit [Remote host closed the connection]
ppascher has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
<karolherbst>
do we have something useful for users in order to debug dpms related issues?
slattann has quit []
<MrCooper>
karolherbst: what kind of issues?
<karolherbst>
MrCooper: display stays black
<MrCooper>
anything in the display server log / terminal output?
<karolherbst>
nope
<MrCooper>
then I'd probably try enabling DRM debugging output while trying to wake it up
slattann has joined #dri-devel
<karolherbst>
right... but it's a mask and what values are making sense and so on
mattst88 has quit [Remote host closed the connection]
<MrCooper>
can always try 0xff if in doubt :)
<karolherbst>
well
<karolherbst>
there are more bits :)
<karolherbst>
the issue is just drm message spam
dogukan has joined #dri-devel
<karolherbst>
so you really don't want to enable everything
mattst88 has joined #dri-devel
<daniels>
imirkin_: yeah, as alyssa says, those absolutely should not fail at all - it's mildly unsurprising because virgl has shifted from qemu to crosvm for its underlying execution, and zink-timelines is testing a totally new codepath that zmike only just recently landed, so they've had less stress than what came before them
<daniels>
imirkin_: just keep poking the responsible people (gerddie/tomeu/etc for VirGL, zmike/airlied/kusma for Zink) and make sure they can see those test failures and get them either worked around or fixed
thellstrom has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
<zmike>
I saw a zink flake from sroland's MR last night, so that's what I'm looking at today
<idr>
ajax: Me too. It's weird... sometimes it has a 1-pixel vertical stripe of stuck green pixels a couple centimeters from the left, but the rest of the time it's fine.
<idr>
I have the #9 card that can drive it and the 3dlabs card that can drive it.
<idr>
And a passthrough DVI-to-LVDS PCI card that can drive it from any graphics card.
<idr>
I want to get the adapter board to drive it from my O2.
<idr>
I guess there was also an off-brand Geforce card that was only released in Japan that can drive it.
<ajax>
i have the multilink gadget
<ajax>
i don't know if i've ever powered it up though
<mdnavare>
daniels: How does it explicitly select the GPU? Is it the same as what GL apps do or there is a different way, do you have any examples on how it requests a particular GPU?
<Sachiel>
tl;dr: you query available devices, check their features, pick the one you want, create your instance with it, all work is done through that instance from now on
<emersion>
not aware of any way to override the devcie used by libva, apart from using the DRM platform in the code explicitly
<alyssa>
ok, with the memory leak down, next up is figure out why drm-shim fails on here
<alyssa>
I sort of suspect I'm missing a kernel option or something silly.
<imirkin>
the point of drm-shim is that you don't really need much from the kernel
<alyssa>
imirkin: hello from bare metal debian on the m1
<alyssa>
do not expect anything from this kernel :p
<imirkin>
well, LD_PRELOAD support is nice
<imirkin>
but that's about it iirc?
<alyssa>
MEMFD_CREATE, but I have that..
<jekstrand>
You may need /dev/dri/card0 and /dev/dri/renderD128 to exist because I know that drm-shim fakes enough file-system stuff that /dev/dri can be empty.
<alyssa>
jekstrand: I have /dev/dri/card0 from my stubbed out display controller experiment, don't have any render nodes
<imirkin>
seems like it should support a lack of /dev/dri
<jekstrand>
Does look that way.....
<imirkin>
and readdir() will append something if it's not already there
<imirkin>
(i think?)
<alyssa>
it's the mmap that's failing...
<alyssa>
(it claims to initialize a fake /dev/renderD128 as expected)
<mdnavare>
Sachiel: So the Vulkan application itself has to have code for selecting the appropriate device or is there a way to chose a device at launch time?
<jekstrand>
mdnavare: The Vulkan app chooses the device
<jekstrand>
mdnavare: However.... They usually choose the first one and Mesa contains a layer (shipped on most distros) which can re-order the devices and/or trim the device list down to just one to force the app to make a particular choice.
<mdnavare>
jekstrand: So if the choice has to be changed, the code has to be changed? No way to do it from command line at runtime?
<jekstrand>
mdnavare: THat's what the layer is for
<alyssa>
ohhh....
<jekstrand>
mdnavare: MESA_VK_DEVICE_SELECT=list will list devices
<jekstrand>
mdnavare: MESA_VK_DEVICE_SELECT=foo will select a device
<alyssa>
mmap on memfd with offset != 0 seems unhappy
<Sachiel>
llvmpipe is the first one? huh...
<mdnavare>
jekstrand: And how do i invoke a particular app to select one, just call with MESA_VK_DEVICE_SELECT=foo in command line ?
<jekstrand>
mdnavare: Yup
<Sachiel>
is the layer always there or you have to force it?
<jekstrand>
mdnavare: Assuming you have the layer. Do =list to check for that.
<jekstrand>
Sachiel: It's on by default in most distros
<Sachiel>
huh
macromorgan has quit [Remote host closed the connection]
<alyssa>
__builtin_ffs()
<alyssa>
imirkin: yep, it's my kernel
<jekstrand>
alyssa: ?
zackr has joined #dri-devel
<alyssa>
The man page for mmap says that `offset` must be a multiple of the page size as returned by sysconf(_SC_PAGE_SIZE)
<alyssa>
drm-shim allocates 4k pages.
<alyssa>
Spot the bug.
ngcortes has joined #dri-devel
<jekstrand>
Do you have funny page sizes?
<daniels>
lmaoooo
<alyssa>
16k
<alyssa>
(Apple IOMMU is 16k and it's easiest just to make the whole thing 16k.)
<alyssa>
this is going on twitter :-p
<jekstrand>
Fun fun
macromorgan has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
<ccr>
happy happy joy joy
macromorgan has quit [Read error: Connection reset by peer]
macromorgan has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
<mdnavare>
jekstrand: Okay thanks Jason, will try that
<jekstrand>
yw
<mdnavare>
jekstrand: But how does Vulkan get used on the media or compute side?
<jekstrand>
mdnavare: I feel like I need some context for that question
<mdnavare>
jekstrand: Hmm so my initial question in this context was that how can we selectively run any media or compute application on a partiuclar GPU and then daniels said that Vulkan we can but not sure about VAAPI
<jekstrand>
mdnavare: Oh, I've got no clue about vappi
pnowack has quit [Quit: pnowack]
<jekstrand>
mdnavare: And OpenCL is client-selected as well and I don't know what cmdline stuff you can do there either
gpoo has quit [Ping timeout: 480 seconds]
<mdnavare>
jekstrand: So for compute , if Vulkan API is used then yes we can selectively use the GPUs but Open CL we cant, is that the correct understanding?
<jenatali>
Which obviously hasn't merged. Dunno if the other loaders used on Linux have something similar already
<mdnavare>
jenatali: Thanks for this info will look into it as well
<mdnavare>
jekstrand: Have you played around with forcing DG for the Vulkan?
<mdnavare>
and scanout on IG
<jekstrand>
mdnavare: Yup. Works on my DG1+TGL with upstream i915
<jekstrand>
Kayden: Can I get an ACK on the header update in !11888
<mdnavare>
jekstrand: Okay cool, I can try that too then, I have a DG1 + TG1 laptopp as well
<Kayden>
jekstrand: ack!
gpoo has joined #dri-devel
<jekstrand>
Kayden: Thanks! Landing that and the userptr MR.
<jekstrand>
Ryback_: ^^
<Kayden>
mdnavare: Vulkan apps should work even on DII, as the Vulkan WSI code always allocates PRIME buffers in SMEM. GL doesn't today, hence you need the kernel migration patches. But VK should work out of the box
<Kayden>
jekstrand: excellent!
<Ryback_>
jekstrand: yay!
<danvet>
jekstrand, ack
pochu has quit [Ping timeout: 480 seconds]
<alyssa>
just opened an MR fixing drm-shim
<alyssa>
I can confirm it works on my funny 16k kernel, it shoul also fix funny 64k kernels
<karolherbst>
alyssa: yay
<karolherbst>
can we please kill 4k pages :D
<karolherbst>
alyssa: I actually do wonder if we hardcode 4k in other places inside mesa which could cause issues
<karolherbst>
but it seems like it's only an iommu problem?
thellstrom has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: we do seem to hardcode 4k in lots of places....
<karolherbst>
yes
<karolherbst>
I am actually wondering if we should assert on the page size on all mmap wrappers we have
lynxeye has quit [Quit: Leaving.]
<karolherbst>
let me check something
<karolherbst>
actually I only do care about llvmpipe hitting such paths
<alyssa>
yeah ... I don't care about panfrost hitting such paths
<alyssa>
(asahi i do)
mlankhorst has joined #dri-devel
slattann has quit []
<karolherbst>
alyssa: uhh.. I have an evil idea
<karolherbst>
we could add the possibility to override all of this
<karolherbst>
make sysconf(_SC_PAGE_SIZE) return 8k e.g. for testing and let the code wrapping mmap assert on the size to be still correct :D
<karolherbst>
and just add an project option for that
<karolherbst>
I don't know if it's worth it though
<alyssa>
would be nice to have CI for this
<karolherbst>
yeah, that's the idea
<karolherbst>
or just write a preload wrapper for those functions...
<karolherbst>
I guess there are some ways on how to test that stuff
<alyssa>
jekstrand: maybe `xrandr --size=320x256` might help? smaller window means less to sw rasterize
<danvet>
and I cant really merge the kernel side without the igt fixup
<mlankhorst>
airlied: Slightly late drm-misc-next pull request sent. :-)
<mlankhorst>
enjoy!
<tzimmermann>
danvet, a-b by /me
<danvet>
tzimmermann, thx
<tzimmermann>
can i somehow leave a msg in patchwork. i'm not subscribed to the igt ML
<tzimmermann>
?
<danvet>
no
<danvet>
patchwork is a read-only view
<tzimmermann>
no problem
<alyssa>
jekstrand: help the CTS run faster, I mean
<krh>
alyssa: we should all be running 16k pages...
<jekstrand>
alyssa: I don't think so
<jekstrand>
alyssa: It typically runs pretty small windows and you really don't want it clipping
<alyssa>
jekstrand: Aw :(
thellstrom has joined #dri-devel
<alyssa>
karolherbst: Guess who is crashing randomly in the multithreading tests
<alyssa>
Meeeeeeeeeeeeeee
ngcortes has quit [Ping timeout: 480 seconds]
<alyssa>
Oh, this is evil.
<alyssa>
Two different threads are binding the shader CSO in parallel, and they're both triggering compiles
<imirkin>
variants suck :)
<alyssa>
I guess I need a lock?
<imirkin>
alyssa: or flip on the cap which says your shader CSO's aren't portable across contexts
<alyssa>
imirkin: They are portable, it's just fighting over the variant list
<alyssa>
iris has a simple_mtx_t for the variants list, I guess I need to copy that
<alyssa>
zmike: as usual, the answer is either copy code or delete code
<daniels>
krh: tell that to Arm SystemReady
<imirkin>
never "write code" :)
<zmike>
we always knew it would come back to this
<zmike>
though now you may owe jekstrand royalties for leveraging his proprietary Delete The Code methodology
<jekstrand>
zmike: Have you looked at my diffstats recently?
<zmike>
no, too busy copying and pasting code
<jekstrand>
lol
<zmike>
last time I deleted something your payment plan almost bankrupted me
thellstrom has quit [Quit: thellstrom]
thellstrom has joined #dri-devel
<jekstrand>
if (is_cow_mapping(vma->vm_flags)) printk(KERN_INFO "Moooooo");
<alyssa>
jekstrand: loooooooo
<alyssa>
l
<ccr>
milking the puns, eh
ngcortes has joined #dri-devel
<alyssa>
veals bad man
<jekstrand>
Just being a bit cheesy
<ajax>
cud y'all stop
tzimmermann has quit [Quit: Leaving]
<jekstrand>
You got a beef with it?
<ajax>
about to chuck the laptop out the window, yeah
<kisak>
mooooving on...
<alyssa>
Over the Moon - Idina Menzel
pochu has joined #dri-devel
<ajax>
Reverend Horton Heat - Eat Steak
<zmike>
ajax: that's a top pun
thellstrom has quit [Ping timeout: 480 seconds]
<alyssa>
hate to interrupt this but what the heck
* alyssa
is onto her next multithreading crash
<alyssa>
thread A does a glFlush() of a batch, while thread B does a glTexSubImage() of the thing that batch writes, so both threads are trying to flush simultaneously and racing
<alyssa>
I don't see other drivers locking for this..
<alyssa>
oh, I guess fd_batch->simple_lock protects this case
<alyssa>
robclark: ^
dogukan has quit [Quit: Konversation terminated!]
<daniels>
ajax: fair enough, onglet off
sdutt has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
zackr has quit [Remote host closed the connection]
vivekk has joined #dri-devel
tlwoerner has quit [Remote host closed the connection]
mbrost_ has joined #dri-devel
zackr has joined #dri-devel
tlwoerner has joined #dri-devel
alyssa_ has joined #dri-devel
buhman has quit [Ping timeout: 480 seconds]
mauld_ has joined #dri-devel
alyssa has quit [Read error: Connection reset by peer]
vivijim is now known as Guest4012
vivijim has joined #dri-devel
mauld has quit [Read error: Connection reset by peer]
gpoo has quit [Ping timeout: 480 seconds]
Guest4012 has quit [Read error: Connection reset by peer]
vivek has quit [Ping timeout: 480 seconds]
buhman has joined #dri-devel
gpoo has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
sdutt has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
alyssa_ is now known as alyssa
alatiera has quit [Quit: Ping timeout (120 seconds)]
ngcortes has quit [Ping timeout: 480 seconds]
alatiera has joined #dri-devel
alatiera is now known as Guest4018
Guest4018 has quit []
thelounge92 has joined #dri-devel
gouchi has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
heat has quit [Remote host closed the connection]
<alyssa>
a box of mutexes turn my brain to macaroni
<HdkR>
Sounsd like my problem with a box of static initializers :D
<alyssa>
HdkR: How do I know where to put the locks?!:p
<HdkR>
Sprinkle them around until everything is recursively locked
<alyssa>
uh oh
<mdnavare>
jekstrand: With the Vulkan API using Mesa layers to choseGPU, does it use the DRI PRIME parsing internally or it uses a different mechansim to select the GPU
<mdnavare>
?
<jekstrand>
It's totally different from DRI_PRIME
<idr>
glennk: Wha... I've never even heard of that card.
mlankhorst has quit [Ping timeout: 480 seconds]
<jekstrand>
alyssa: The only problem harder than figuring out where to put the locks is figuring out how to take out the bad one without the whole universe exploding. (-:
<alyssa>
jekstrand: :_:
* jekstrand
goes back to staring at dma_resv
<alyssa>
jekstrand: gl
<alyssa>
i mean
<alyssa>
vk
<jekstrand>
What about vk?
<HdkR>
Good Luck -> GL -> VK -> No Luck had
<HdkR>
:D
pcercuei has quit [Quit: dodo]
<alyssa>
how have i already managed to introduce a dead lock
<karolherbst>
alyssa: simple_mtx_assert_locked is key
<alyssa>
karolherbst: eh?
<karolherbst>
this way you can lock on the consumer side of functions without having to worry too much
<karolherbst>
internal locking can make it simple to use functions and stuff, but sometimes the overall thing is too complex and you have to lock externally
<karolherbst>
or just do it because it is simplier
<karolherbst>
then you just verify in the racy code with simple_mtx_assert_locked that the lock was indeed locked
<alyssa>
got it
<alyssa>
ty
<karolherbst>
also.. there is a fun fact about simple_mtx_t.. the unlock functions works also on mtx which aren't locked...
<karolherbst>
not sure if that's intentional or not
<alyssa>
karolherbst: I think I better start with a more basic question -- what are the rules around multithreading in Gallium?
<karolherbst>
uhm....
<karolherbst>
everything goes?
<alyssa>
Previously, I thought it was "anything can access the screen, but only one thread can access the context"
<alyssa>
clearly that is wrong.
<imirkin>
same as the rules of fight club...
<karolherbst>
alyssa: well
<jenatali>
alyssa: That was my understanding
<imirkin>
only one thread per context
<karolherbst>
with GL you have to make a context current
<imirkin>
but multiple threads per screen
<karolherbst>
so you shouldn't have multiple threads on the same context doing stuff
<karolherbst>
anyway.. don't know who to contact with that stuff
<mattst88>
are you in any additional groups that might somehow control gerrit access?
<karolherbst>
mattst88: I am in.. too many to count
<karolherbst>
ehh wait
<mattst88>
I emailed webmaster@khronos.org to get them to rename my gitlab account from mattst881 -> mattst88, FWIW
<karolherbst>
no
<karolherbst>
there is a join button everywhere :D
<mattst88>
just search for 'Leave'
<karolherbst>
I am only in General
<karolherbst>
and OpenCL
<mattst88>
okay, thanks, so it's likely not working group membership that controls this
<alyssa>
I am in General, OpenGL, OpenGL ES, Vulkan-GL-CTS
<karolherbst>
mattst88: our gitlab groups are also equal
karolherbst has quit [Remote host closed the connection]
sdutt has joined #dri-devel
karolherbst has joined #dri-devel
<karolherbst>
heh.. why did I just lost my connection? nvm
CME has quit []
CME has joined #dri-devel
<karolherbst>
mattst88: anyway.. I guess your rename messed it up
<karolherbst>
and your old name is in some stupid list they modify with scripts or so
<mattst88>
karolherbst: no, it wasn't working beforehand either
<karolherbst>
ahh
<Sachiel>
maybe when the rename happens you'll get the old access you had while at Intel
<mattst88>
I just emailed webservices@khronosgroup.org so hopefully they can help
<karolherbst>
probably something stupid, like having a number in your account name
<mattst88>
Sachiel: heh, no, they renamed my old account to mattst88_intel :)
jkrzyszt has quit [Ping timeout: 480 seconds]
jkrzyszt has joined #dri-devel
<mattst88>
well, maybe it is somehow related. almost instant reply:
<mattst88>
> Oops. I need to update that as well. Will do it first thing in the morning
<alyssa>
Hnnngh
<alyssa>
why is multithreading so hard
<alyssa>
it just makes my brain melt
<alyssa>
maybe that's my cue to call it a day
<HdkR>
Threads were a mistake, lets go back to only single core machines :D
<dcbaker>
because we tend to only think about one thing at a time?
<Sachiel>
no no, keep the multi core machines, but run one instance of MS-DOS on each
<imirkin>
ahhh the comforts of 16-bit real mode
<HdkR>
The horrors of 16-bit real mode
<imirkin>
dude wtvr. you don't like something, just modify the global interrupt descriptor table. that'll fix ya right up
<imirkin>
just don't ... you know ... clear it and then wait for a keypress :)
<imirkin>
definitely never did that.
<karolherbst>
alyssa: I can talk about my experiences with it with nouveau :)
<karolherbst>
VM just sacrifized performance to account for stupid devs, remove it and just have perfect code, duh ¯\_(ツ)_/¯
<alyssa>
....ralloc isn't thread safe is it
<karolherbst>
of course not
<imirkin>
if you have to ask
<imirkin>
then you already know the answer
<alyssa>
cry emoji
<karolherbst>
alyssa: just use the context as the context?
<karolherbst>
dunno :D
<karolherbst>
would be a stupid idea actullay
<karolherbst>
*actually
<alyssa>
karolherbst: sure, but using the screen is unsafe unless you lock the whole screen
<alyssa>
what the helgrind
<karolherbst>
yeah..
<karolherbst>
you don't have to put everything into a huge ralloc context
<karolherbst>
shaders can be their own
<karolherbst>
as they get explicitly destroyed anyway
ngcortes_ has joined #dri-devel
vivijim is now known as Guest4036
vivijim has joined #dri-devel
<alyssa>
in this case my use of ralloc was just lazy, using calloc/free directly should fix
<daniels>
karolherbst: we're a Contributor member but not Adopter - adoption is under SPI since it's Mesa
<karolherbst>
alyssa: ahh
pzanoni` has joined #dri-devel
<daniels>
alyssa: mattst88 is right - webmaster@khronos.org is the one to sort your access levels, feel free to cc me
<karolherbst>
daniels: sure.. but you can access that repo while alyssa can't :)
<daniels>
yeah
<daniels>
hence emailing Jon :P
jewins1 has joined #dri-devel
ramaling_ has joined #dri-devel
<karolherbst>
why is it that late already
<daniels>
karolherbst: you usually keep west coast time tbf
<karolherbst>
:D
<alyssa>
Oh hey, it passes now! that was the bug *smacks self*
<karolherbst>
it's not that bad
<alyssa>
well. probably more bugs underneath the surface :p
Guest4036 has quit [Ping timeout: 480 seconds]
mattrope has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
mattrope has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
ramaling has quit [Ping timeout: 480 seconds]
pzanoni has quit [Ping timeout: 480 seconds]
pzanoni` is now known as pzanoni
<daniels>
alyssa: nah, surely you've fixed all of them by now!
iive has quit []
<alyssa>
daniels: I like your attitude better
ngcortes_ has quit []
ngcortes_ has joined #dri-devel
<Sachiel>
if you don't pick up the rocks they hide under, no one needs to know the bugs even exist
<alyssa>
rsrc->track.users is racy ... might replace with an atomic ...
<karolherbst>
alyssa: we have c11 now :)
<karolherbst>
so.. we can use _Atomic
<alyssa>
it's a bit set in a u32. would need to add some util code to make the interface nice.
<karolherbst>
in case you feel lazy using those atomic helpers
<karolherbst>
alyssa: why?
<karolherbst>
mark the field as _Atomic
<alyssa>
uhhhh
<karolherbst>
well.. it won't fix racy state
<karolherbst>
but...
<karolherbst>
so this is the issue with atomics: if you read and write the value later it's still as racy as before :D
<alyssa>
nyeh
<karolherbst>
but if you just flip a bit and don't depend on it earlier, you can just mark the field as _Atomic and be happt
<karolherbst>
*happy
<alyssa>
nod
<alyssa>
I wonder if we could get CI coverage of dEQP-EGL.functional.sharing.gles2.multithread.*
<karolherbst>
:D
<karolherbst>
have fun
<HdkR>
I still want to know a use for atomic negate :P
<alyssa>
it looks like freedreno does
<karolherbst>
HdkR: silly hardware?
<HdkR>
Silly hardware
<karolherbst>
you assume that a negate is a one op operation :p
<HdkR>
It can be if you can sub with a zero register :D
<alyssa>
DEQP_VER egl...
<karolherbst>
HdkR: :D
<imirkin>
HdkR: that assume you have an atomic sub
ngcortes_ has quit []
ngcortes_ has joined #dri-devel
<HdkR>
That too
ngcortes_ has quit [Remote host closed the connection]
<HdkR>
That can just be emulated with an atomic add. Just follow the trail ;)
<karolherbst>
sooo
<karolherbst>
context reset try 2
<glennk>
have to wait for them to surface first before you can follow the trail
<karolherbst>
HdkR: just loop with an atomic_inc/dec ¯\_(ツ)_/¯
<HdkR>
oof
<karolherbst>
HdkR: you'd think it's a lot of iterations, but be smart and check for > 0x80000000 so you can just abuse overflows and go the other directions
idr has quit [Quit: Leaving]
minecrell has quit [Quit: Ping timeout (120 seconds)]
minecrell has joined #dri-devel
<HdkR>
karolherbst: I think I'll just use a CAS loop :P
<karolherbst>
HdkR: what if you don't have CAS?
<HdkR>
load exclusive, store exclusive
<HdkR>
ARM exclusive monitor is great like that
<karolherbst>
HdkR: sure, but think of a GPU which doens't have those locked ld/st semantics :D
<HdkR>
Don't emulate atomic neg on those :D
demarchi has quit [Ping timeout: 480 seconds]
tomba has quit [Ping timeout: 480 seconds]
T_UNIX has quit [Ping timeout: 480 seconds]
ella-0[m] has quit [Ping timeout: 480 seconds]
Dylanger has quit [Ping timeout: 480 seconds]
Newbyte has quit [Ping timeout: 480 seconds]
xerpi[m] has quit [Ping timeout: 480 seconds]
undvasistas[m] has quit [Ping timeout: 480 seconds]
pmoreau has quit [Ping timeout: 480 seconds]
MatrixTravelerbot[m] has quit [Ping timeout: 480 seconds]
user1tt[m] has quit [Ping timeout: 480 seconds]
Eighth_Doctor has quit [Ping timeout: 480 seconds]
tintou has quit [Ping timeout: 480 seconds]
Tooniis[m] has quit [Ping timeout: 480 seconds]
Sumera[m] has quit [Ping timeout: 480 seconds]
dcbaker has quit [Ping timeout: 480 seconds]
chema has quit [Ping timeout: 480 seconds]
RAOFhehis[m] has quit [Ping timeout: 480 seconds]
cwfitzgerald[m] has quit [Ping timeout: 480 seconds]
go4godvin has quit [Ping timeout: 480 seconds]
_alice has quit [Ping timeout: 480 seconds]
exit70[m] has quit [Ping timeout: 480 seconds]
gnustomp[m] has quit [Ping timeout: 480 seconds]
reactormonk[m] has quit [Ping timeout: 480 seconds]
zzoon[m] has quit [Ping timeout: 480 seconds]
egalli has quit [Ping timeout: 480 seconds]
LaughingMan[m] has quit [Ping timeout: 480 seconds]
jekstrand[m] has quit [Ping timeout: 480 seconds]
YaLTeR[m] has quit [Ping timeout: 480 seconds]
SamJames[m] has quit [Ping timeout: 480 seconds]
apinheiro[m] has quit [Ping timeout: 480 seconds]
Anson[m] has quit [Ping timeout: 480 seconds]
neobrain[m] has quit [Ping timeout: 480 seconds]
cmarcelo has quit [Ping timeout: 480 seconds]
atulu[m] has quit [Ping timeout: 480 seconds]
danylo has quit [Ping timeout: 480 seconds]
MrR[m] has quit [Ping timeout: 480 seconds]
nielsdg has quit [Ping timeout: 480 seconds]
robertmader[m] has quit [Ping timeout: 480 seconds]
kusma has quit [Ping timeout: 480 seconds]
jasuarez has quit [Ping timeout: 480 seconds]
jenatali has quit [Ping timeout: 480 seconds]
DrNick has quit [Ping timeout: 480 seconds]
icecream95 has quit [Ping timeout: 480 seconds]
Venemo has quit [Ping timeout: 480 seconds]
Strit[m] has quit [Ping timeout: 480 seconds]
Guest3466 has quit [Ping timeout: 480 seconds]
ServerStatsDiscoverertraveler4 has quit [Ping timeout: 480 seconds]