ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
jessica_24 has joined #dri-devel
vivijim has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
cbaylis has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
<idr>
The jolly, red, candy-like button...
<alyssa>
Sachiel: gitlab is foss so... ;P
* Sachiel
sends patch deleting the button
mbrost has joined #dri-devel
Lightkey has quit [Ping timeout: 480 seconds]
muhomor has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
Lightkey has joined #dri-devel
nchery has joined #dri-devel
nchery has quit []
pnowack has quit [Quit: pnowack]
mbrost has quit [Remote host closed the connection]
jewins has quit [Read error: Connection reset by peer]
jewins has joined #dri-devel
mbrost has joined #dri-devel
sdutt has quit [Remote host closed the connection]
sdutt has joined #dri-devel
boistordu has joined #dri-devel
Guest1618 has quit [Remote host closed the connection]
tttteessttt has joined #dri-devel
tttteessttt has quit []
boistordu_ex has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
camus1 has joined #dri-devel
riku has left #dri-devel [#dri-devel]
camus has quit [Ping timeout: 480 seconds]
worldeva has joined #dri-devel
<worldeva>
Hello, is it possible to use a debugger with mesa (...hopefully without recompiling my kernel...)? I'm trying to debug a device lost error ^-^
<dottedmag>
anholt_: Let me see if I understood it: a client obtained a magic value and passes it to server saying "Please allow me to draw", not the server obtained the magic value and passed it to client saying "With this one you can draw"?
pnowack has joined #dri-devel
<dottedmag>
anholt_: So GET_MAGIC didn't create an authorization token, it created a _potential_ token, and AUTH_MAGIC turned it into actual authorization token, am I right?
ppascher has quit [Quit: Gateway shutdown]
lynxeye has joined #dri-devel
pcercuei has joined #dri-devel
<MrCooper>
dottedmag: no it's the latter, server gives client a token with which it can authenticate itself to the kernel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
ppascher has joined #dri-devel
<dottedmag>
MrCooper: All right, I was confused by DRI client/server. DRI client is in X server, DRI server is kernel, right?
<MrCooper>
I was referring to X server/client
<dottedmag>
Yes, and Emma was referring to DRI client/server.
<MrCooper>
never heard that separate terminology used before
<dottedmag>
OK. I think I got the picture. Thank you!
<MrCooper>
reading what Emma wrote again, I do suspect I got it wrong :(
<MrCooper>
sounds like the client generates a token and passes that to the X server, which then tells the kernel "this token is authenticated for rendering"
<dottedmag>
That's how I read it too.
<dottedmag>
But anyway, it's all just to satisfy my curiosity. It was fun to waddle through DRM ioctls and see what they did.
<MrCooper>
cool, sorry for the confusion
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<pq>
reading the wl_drm Wayland extension spec in Mesa might actually give a clear answer. :-)
xexaxo_ has joined #dri-devel
xexaxo has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
<danvet>
airlied, I guess due to the nouveau issue would be good to backmerge -rc3 and then push that at least into drm-misc-next?
<danvet>
mlankhorst, ^^ I think drm-misc-next is your turn?
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
lemonzest has quit [Quit: Quitting]
<mripard>
daniels: it looks like there's a commit hook that fails on the drm-misc server: remote: hooks/post-receive.d/01-github: line 1: /run/github-mirror/named-pipe: Permission denied
<mripard>
s/server/repo/
<daniels>
mripard: oh thanks for letting me know
<mripard>
daniels: it seems to be fixed now, thanks :)
<daniels>
np!
NiksDev has joined #dri-devel
<dottedmag>
pq: Thanks, now it makes sense.
mlankhorst has quit [Ping timeout: 480 seconds]
mlankhorst has joined #dri-devel
<mlankhorst>
danvet: already had a first pull req?
<mlankhorst>
but yeah, second will be incoming in a bit, after that I'll probably forward
muhomor_ has joined #dri-devel
muhomor has quit [Ping timeout: 480 seconds]
flacks_ has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
flacks has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
flacks has joined #dri-devel
<mlankhorst>
airlied: ^ one more drm-misc-next pull for you, if you want
flacks_ has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
MrCooper has quit [Quit: Leaving]
MrCooper has joined #dri-devel
muhomor_ has quit [Remote host closed the connection]
muhomor has joined #dri-devel
rsalvaterra_ has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
xp4ns3 has joined #dri-devel
xp4ns3 has left #dri-devel [Konversation terminated!]
tzimmermann has joined #dri-devel
<danvet>
tzimmermann, drat I'm just about to push another drm-misc-fixes patch
rsalvaterra_ has quit []
<tzimmermann>
danvet, i just sent out the PR
<danvet>
yeah just spotted
rsalvaterra has joined #dri-devel
<danvet>
it's not critical, but I guess means a merge to get -rc3 in
<danvet>
so we're not stuck on -rc1 forever
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
iive has joined #dri-devel
alatiera1 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
alatiera has joined #dri-devel
alatiera is now known as Guest1760
alatiera1 has quit [Ping timeout: 480 seconds]
Guest1760 is now known as alatiera
Company has joined #dri-devel
itoral has quit []
alatiera4 has joined #dri-devel
alatiera has quit [Ping timeout: 480 seconds]
alatiera has joined #dri-devel
alatiera is now known as Guest1763
alyssa has left #dri-devel [#dri-devel]
alatiera4 has quit [Ping timeout: 480 seconds]
Guest1763 is now known as alatiera
ickle has quit [Read error: Connection reset by peer]
<cafuffu>
hi. how does an application using libdrm recover from a GPU hang? my intel GPU is reset correctly if it hangs, but i don't see how i can get notified of that in userspace in order to recover
<imirkin_>
i believe intel drivers do an abort() when they detect a GPU hang.
<pq>
cafuffu, what else are you using than libdrm? How do you render?
<cafuffu>
imirkin_: what do you mean? the application causing the hang is not aborted, nor any other
<imirkin_>
cafuffu: if you're using intel mesa drivers, it is
<zmike>
I'm not sure that's accurate 🤔
<cafuffu>
pq: the whole story is i'm trying to debug wlroots as the whole compositor (any compositor based on wlroots, and also weston) hangs when my app (which has a bug in a shader) causes the gpu hang
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<cafuffu>
ah interesting
<pq>
When an atomic commit turns a CRTC off, is it ok if the completion event is sent with zero timestamp?
<pq>
That is what I see happening, and I wonder if I need to work around it in userspace.
iive has quit []
heat has joined #dri-devel
<pq>
amdgpu send zero, intel sends a proper timestamp
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<pcercuei>
find a middle ground, send with timestamp/2 ;)
<pq>
oh right, like "going down!"
agx has joined #dri-devel
<MrCooper>
pq: out of curiosity, what do you want to use that timestamp for?
<pq>
right now it triggers an assert
<pq>
since it's a crtc-off timestamp, I guess shouldn't be used for much
heat_ has joined #dri-devel
<MrCooper>
I mean, otherwise the timestamp corresponds to the end of vertical blank, which never happens when the CRTC is off
agx has quit []
agx has joined #dri-devel
<pq>
the CRTC *was* on and this commit turns it off. So the timestamp is the time when the CRTC stop sending a video signal.
<MrCooper>
at least I doubt it's well defined what the timestamp is supposed to mean in this case
<pq>
I don't mind which way it is, I just want drivers to agree. :-)
agx has quit []
<pq>
or UAPI to tell me that it's ok to give various different answers and I should ignore them all
agx has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
urja has quit [Read error: Connection reset by peer]
<danvet>
pq, amdgpu giving you zero is an achievement tbf
<danvet>
I'm not even sure how they managed to pull that off
urja has joined #dri-devel
<pq>
haha, FWIW, this is with 5.10 kernel from Debian
<danvet>
since the usual functions should either give you a vblank ts or if that's not there, the current time
<danvet>
so you really should have always /something/ in there
<danvet>
it's maybe a confusion with the drm_vblank.c ts code, but since i915 gets one that's less likely
nchery has joined #dri-devel
<pq>
danvet, do you think it would be a good idea for userspace to ignore all timestamps that ever result from turning a CRTC off?
<pq>
it's not like the timestamp is useful for anything I can imagine
<danvet>
pq, the event should be useful for buffer reuse
<danvet>
pq, atomic amdgpu or amdgpu without atomic support?
<pq>
the event is, the timestamp less so
sdutt has quit []
sdutt has joined #dri-devel
<pq>
atomic
<danvet>
pq, they hand roll it and fucked it up
<pq>
What do you recommend I do? Scream or fix Weston?
<danvet>
scream
<danvet>
amdgpu patch should be cc: stable and done
<danvet>
they use the raw send_event helper
<danvet>
which shuts up the warning about "you forgot to send out the event"
<danvet>
but ofc we can't check whether they fill out all the fields correctly, which they don't
<danvet>
they should use drm_crtc_send_vblank_event() instead
<danvet>
igt maybe would catch this, dunno
<danvet>
pq, maybe tune down your weston check to a "your kernel driver is broken" warning
<danvet>
hwentlan, ^^
<pq>
okay, so I need to get the latest kernel built so I can check the problem still exists and to be able to test a patch later...
<danvet>
pq, I read the latest kernel source code
<danvet>
the problem definitely still exists :-)
<pq>
ookay, but I suppose I still need to be able to test a patch :-)
<danvet>
get amdgpu folks to run some igt?
<danvet>
like if you find an igt that goes boom
<danvet>
kms_flip has tests with crtcon/off (both active and dpms) and ts
<danvet>
there's hopefully one in there that will holler
Surkow has quit [Remote host closed the connection]
<pq>
alright
Surkow|laptop has joined #dri-devel
<MrCooper>
danvet: still not sure what the timestamp should correspond to when turning off a CRTC though
Duke`` has joined #dri-devel
mattrope has joined #dri-devel
<emersion>
hm
<emersion>
it doesn't seem like there's a way to turn off *any* CRTC when passing the PAGE_FLIP_EVENT flag to atomic commits
<emersion>
my use-case is the following: inside a single atomic commit, turn off all CRTCs except one, and request a page flip event for that CRTC
<hwentlan>
yeah, would be good to catch this with an IGT test if there is none or to let me know which one breaks and we'll get it fixed
<emersion>
(cc danvet)
Bennett has joined #dri-devel
mbrost_ has joined #dri-devel
mbrost has quit [Remote host closed the connection]
cafuffu has quit [Remote host closed the connection]
nchery has quit [Ping timeout: 480 seconds]
nchery has joined #dri-devel
alyssa has joined #dri-devel
<alyssa>
Valhall needs to insert "move immediate" instructions in some cases, and ideally the same instruction is reused. Having a hard time deciding between inserting moves all over the place and then running backend CSE, versus just reusing moves in the lowering pass.
<alyssa>
The former approach seems like less work (especially since I already have local bifrost CSE, and if I ever want to do global CSE i only have one place to update)
<alyssa>
it also seems way less efficient but... that probably doesn't matter a smidgeon?
<alyssa>
Especially since this is an edge case, usually we can optimize to a uniform instead of an instruction, this is just if we run out of push uniform space
<alyssa>
So.. CSE it is.
<alyssa>
Thanks for help y'all ❤️
<Sachiel>
quack
<HdkR>
wark wark wark
<alyssa>
🐸
* ccr
wobbles in a peculiar manner.
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
<karolherbst>
any opinions on how to manage shaders inside VRAM? Atm in nouveau we have a screen global bo with all the shaders, but in regards to multithreading you can desync and I am wondering if drivers generally store shaders per context or per screen
ngcortes has joined #dri-devel
<bnieuwenhuizen>
BO per shader and rely on suballocation to clean that up and never move after allocation so mostly no desync
gouchi has joined #dri-devel
<mareko>
each shader is just another BO
<mareko>
so per screen
<mareko>
also per screen with util_live_shader_cache
<karolherbst>
mhhh
<karolherbst>
yeah.. sadly we can't do that :/
<karolherbst>
we have a bo per hw context essentially
<karolherbst>
and reference shaders by offsets
<karolherbst>
and if we change it we have to sync with a WFI
<mareko>
so you just need a suballocator per context that is thread-safe
<karolherbst>
the problem isn't the CPU side
<karolherbst>
even placing isn't
<karolherbst>
the problem starts when the bo is too small and we need to allocate a bigger one
<karolherbst>
and throw everything out
<karolherbst>
anyway.. there is problably just some referencing issue I didn't fix
<karolherbst>
was mostly curious how other drivers deal with that
mlankhorst has quit [Ping timeout: 480 seconds]
<danvet>
robclark, btw afaiui drm/scheduler uses cb directly to handle dependencies, so only optimizing dma_fence_wait might still leave you open to big perf issues
<danvet>
if this is indeed a trouble you have
<danvet>
maybe just not somewhere you've measured yet (it would be more latency in pushing jobs to the gpu instead of waiting for their completion)
<danvet>
robclark, I expect the difference will boil down to the parameters passed to try_to_wake_up
<robclark>
yeah, it uses cb's.. although the only place we end up waiting on external fence is out-fence from atomic comit
<danvet>
and nothing else should matter here
camus has joined #dri-devel
<karolherbst>
actually.. pre volta we have a context global code segmant, volta and newer don't :/
camus1 has quit [Ping timeout: 480 seconds]
Peste_Bubonica has joined #dri-devel
gouchi has quit [Remote host closed the connection]
K`den has joined #dri-devel
Kayden has quit [Read error: Connection reset by peer]
K`den is now known as Kayden
frieder has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
ajax_ has joined #dri-devel
ajax_ is now known as ajax
mlankhorst has joined #dri-devel
* zmike
spots a wild ajax
<jekstrand>
What's up with piglit CI?
<jekstrand>
It's taking forever to run anything
<zmike>
define "piglit ci"
<jekstrand>
And by forever, I mean I've had the tab open for hours and it's still "Checking pipeline status"
<jekstrand>
zmike: We've got some sort of pipelines for piglit
<alyssa>
jekstrand: I can't decide if (('b2f32', ('b2b1', a)), ('b2f32', a)) is valid.
<jekstrand>
alyssa: It is
<alyssa>
In that case MR incoming
<alyssa>
:-p
<jekstrand>
alyssa: Is a 1-bit?
<alyssa>
a is 32-bit
<jekstrand>
Still, as long as you can handle 32-bit bools in your backend, that's valid
<alyssa>
which is why it's sketchy, backend that didn't opt into 32-bit bools is now getting 32-bit bools
<jekstrand>
alyssa: But it shouldn't get a b2b1(a@32) unless it already supports 32-bit bools
<alyssa>
Nope, b2b1 and b2b32 are always supported even if you're 1-bit only
<jekstrand>
Right....
<jekstrand>
Ugh, yeah, that could be tricky. Expect fallout.
<alyssa>
(To support bools in SSBOs)
<jekstrand>
Uniforms and shared memory, actually.
<jekstrand>
SSBOs always use u2b1
<alyssa>
did I forget another pass in the standalone compiler because I'm getting b2b1 for my SSBO
<jekstrand>
Only GL uniforms and shared have the guarantee that whoever wrote it knows what they're doing it.
<jekstrand>
Maybe I did it wron?
<jekstrand>
Yup, I flubbed it.
<alyssa>
i helped! :-p
<alyssa>
Booleans are hard.
<alyssa>
Ironically.
<jekstrand>
Wait, no. The code we have should be fine.
<alyssa>
bifrost has way too many boolean modes.
<alyssa>
(And they all kind of suck.)
<jekstrand>
As long as you're using nir_lower_explicit_io, we get it right
<jekstrand>
Are you using oldschool nir_lower_io?
nchery has quit [Ping timeout: 480 seconds]
<alyssa>
Like I said my standalone compiler is cargoculted.
<jekstrand>
:)
<alyssa>
so I have no clue
<jekstrand>
Anyway, your stand-alone compiler is wrong so you shouldn't write such an optimization. :P
<alyssa>
It still applies to shared memory and uniforms though? :_p
<alyssa>
Alternatively I could do some of these optimizations on backend IR but .. meh
<alyssa>
so spoiled to opt_algebraic
<jekstrand>
I'm not sure it actually does apply to uniforms in gallium....
<jekstrand>
Because they look like a UBO and we have to i2b for those
<alyssa>
jekstrand: Right, the poiny still stands. I'd like to optimize (('b2f32', ('i2b1', a)) to the hardware instruction doing "x != 0 ? 1.0 : 0.0"
<jekstrand>
I think we may use b2b in i965 because we can specify 0/~0 for false/true
<alyssa>
right now we translate literally to two instructions, doing "(x != 0 ? 1 : 0) != 0 ? 1.0 : 0.0" which is silly
<jekstrand>
alyssa: Do you use 32-bit booleans?
<alyssa>
Um
<alyssa>
Hardware natively does 16-bit and 32-bit booleans encoded as either 0/1, 0/~0, or 0/1.0f ..
<jekstrand>
Right
<alyssa>
Doing 32-bit always wastes registers and prevents vectorization of 16-bit compares.
<jekstrand>
In IBC, I did 16-bit booleans for most things.
<alyssa>
Doing 16-bit always requires extra moves in random places because the CSEL instruction doesn't take a swizzle (?!)
<alyssa>
It's not clear that someone actually thought this through.
<jekstrand>
Yeah, I hear you
<jekstrand>
Ours are horrible
<jekstrand>
comparisons produce a bool of whatever bit-size is being compared
<jekstrand>
For 64-bit things, only the bottom 32 bits are usable. The top is garbage.
<alyssa>
That sounds similarish
<alyssa>
and yes horrible to model
<jekstrand>
So it's a world of MOVs no matter what you do.
<alyssa>
Yeah
<jekstrand>
Honestly, if I bothered caring about 16-bit, I might be up for a 16-or-32-bit-bool pass
<jekstrand>
in NIR
<alyssa>
lower_to_bitsize iirc?
<jekstrand>
rather than trying to sort it out in the back-end.
<jekstrand>
lower_to_bitsize isn't quite right
<anholt_>
v3d had really nice way of getting 0x00010001 for 32-bit bool true.
<anholt_>
this was not super useful
<alyssa>
lol
<jekstrand>
We'd need new nir_op_ilt16 and friends. Looks like we already have those....
<jekstrand>
anholt_: Wow, that's terrible. Only slightly better than SNB and earlier's 1-bit bool where that one bit is the bottom bit in a 32-bit value, the rest of which is garbage.
<anholt_>
(32b compares set both the half-float compare flags, and there's an instr to get the compare flags)
<alyssa>
Apple makes this real nice.
<alyssa>
Anything can be 16 or 32 bit, free conversions, no restrictions
<alyssa>
Just use 16-bit bools 100% of the time
<alyssa>
the Just Works™ vendor
<airlied>
probably allowed a c0mpiler engineer to read the hw spec before tapeout
<anarsoul>
alyssa: it's just 1st gen
<anarsoul>
wait for it :)
<alyssa>
anarsoul: no?
<anarsoul>
it's not a 1st gen?
<alyssa>
no
<anarsoul>
oh, OK
<alyssa>
Apple GPUs have been in iPhones for ~5 years
<anarsoul>
alyssa: are you sure that it's the same as in M1?
<alyssa>
and the GPU in the M1 is functionally identical to that in the iPhone in the A14
<anarsoul>
OK, then. Well done, Apple :)
<airlied>
woah some amz game is bricking evga 3090 gpus
<airlied>
thats impressive
<alyssa>
jekstrand: I guess part of it is that bifrost has a big impedance mismatch with NIR around comparisons
<alyssa>
The hardware gives two sets of instructions: comparisons (return any format of boolean), and four-source csel (fused compare+bcsel)
rasterman has quit [Quit: Gettin' stinky!]
<alyssa>
the Arm compiler rarely stores booleans in registers at all, since it can usually fuse the operation generating the boolean with whatever consumes it
<jekstrand>
alyssa: Right. NIR doesn't have a fused csel.
<jekstrand>
Incidentally, Intel has a CSEL which is similar.
<jekstrand>
It's only 3src, though. It only compares to 0.
<alyssa>
There's no good way to extend NIR to massage the input, but there's also no easy backend opt pass to fuse things optimally. (And I guess the hardware designers gifted us with an NP complete isel problem here.)
<daniels>
jekstrand: you had CI disabled in your Piglit fork for ... some reason
<jekstrand>
daniels: Uh... Old fork, I guess.
<anholt_>
alyssa: I've always had csel greedily merge in an SSA comparison from the backend. It's not too bad.
nchery has joined #dri-devel
<alyssa>
anholt_: CSEL+comparison isn't too bad, CSEL+comparison vs comparison+conversion and with extra conversions sprinkled in is a harder question
<zmike>
anholt_: btw super 👍 on the deqp-runner change, I'll likely switch over the zink jobs right away
<anholt_>
I've got sp, lp, i915 done, working on virgl now
<zmike>
ooo
<anholt_>
figure the more I convert to use it, the more I'll find rough edges before I cut a release.
<alyssa>
`FCMP.f32.gt.f1 x, y` is functionally equivalent to `CSEL.f32.gt x, y, 1.0f, 0.0f` but the latter is slower in some circumstances, etc
<alyssa>
There's no globally optimal solution for this ISA..
<alyssa>
Anyway. Er. that's my cue to start thinking about literally anything else instead ^^
<jekstrand>
daniels: Shows you how much I work on piglit. (-:
bcarvalho has quit [Quit: Leaving]
Duke`` has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
<airlied>
zmike: wierd the 4444 fail in gles2 disappeared with a VK-GL-CTS update
<airlied>
I never looked into why
<zmike>
airlied: huh
<zmike>
that is weird
<zmike>
or was the test just put on a skiplist somehow?
<airlied>
the VK 4444 tests got introduced in that jump so maybe some fallout
<airlied>
some of the es2 tests got new thresholds applied
<airlied>
probably made what we were doing more tolerant
<airlied>
I wonder if the VK tests then have the same as the old GLES tolerances
<zmike>
could be? I didn't get into it at all
<airlied>
I might bump the 4444 fix into your MR and fix the polygon offset problem for now
<zmike>
go for it
iive has joined #dri-devel
lynxeye has quit []
camus1 has joined #dri-devel
gouchi has quit [Remote host closed the connection]
camus has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
vivijim has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
Lucretia has quit []
Lucretia has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
mbrost has quit [Ping timeout: 480 seconds]
iive has quit []
mbrost has joined #dri-devel
rasterman has joined #dri-devel
heat_ has quit [Read error: Connection reset by peer]
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
ngcortes has quit [Remote host closed the connection]
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Quit: Leaving]
* karolherbst
looks at threading
<karolherbst>
:(
<karolherbst>
sometimes I hoped I would have state oblivious to the fact what threading vs parallelism is :)
<alyssa>
icecream95: pointed out in #panfrost that I have an MR using Python f-strings in a build script
<alyssa>
Those were added in Python 3.6, released Christmas 2016. Debian stable has 3.7
<alyssa>
So I think it's fine. Then again we still have Python2 support kicking last I checked so.. er..
<karolherbst>
does mesa even support python2?
<alyssa>
Maybe not
<alyssa>
!3674 never got merged...
<karolherbst>
huh
<icecream95>
The docs (install.rst) mention 3.5 as the oldest supported version, though Panfrost is already silently broken there
<imirkin_>
alyssa: what are f-strings?
<alyssa>
icecream95: Panfrost is also silently broken on 3.6,3.7, 3.8, 3.9 .... 😉
<karolherbst>
alyssa: sounds like python is broken
<alyssa>
imirkin_: f'strings with code {1 + 1} in them'
<imirkin_>
ah
<imirkin_>
i haven't really kept up with python
<karolherbst>
duh... why am I am fixing a bug, running into a new one and never knowing I actually fixed a bug and just running into new ones :)
<karolherbst>
s/and//
<imirkin_>
karolherbst: that's basically how i've always felt
<imirkin_>
life is one long bug :)
<karolherbst>
yeah, seems like it
<karolherbst>
why am I am even trying :P
<karolherbst>
so apparently my mt fixes for nouveau were all perfect and everything, unless we resize text space :)
<karolherbst>
and I actually fixed it, the kernel is just unhappy if I keep referencing dead bos :(
<karolherbst>
which is weird, because I thought there are actually refcounted
<karolherbst>
oh well
<imirkin_>
maybe nouveau will work by the end of this little exercise
<karolherbst>
:D
<karolherbst>
well it does work quite fine already though
<karolherbst>
well
<karolherbst>
sometimes
<imirkin_>
hehe
<karolherbst>
actually.. the bug I am hitting doesn't happen on volta+ because.... I forgot we don't need to offset shaders anymore :)
<karolherbst>
and I was testing with like turing
<karolherbst>
at least I didn't try to reproduce with turing and spend 5 hours debugging why it wouldn't crash :)
cbaylis has quit [Ping timeout: 480 seconds]
tursulin has quit [Read error: Connection reset by peer]
<karolherbst>
well even if I don't manage to fix nouveau with that, I have now a better understanding on how the driver works :D