<zmike>
yes, I too am surprised I have not seen an EEE comment until now
benjamin1 has quit [Ping timeout: 480 seconds]
<jenatali>
At least on GitLab
<airlied>
would it be bad if I added ...Ewoks?
<jenatali>
Do it
illwieckz has quit [Ping timeout: 480 seconds]
<zmike>
🐔
<alyssa>
jenatali: EEEEEEE
<alyssa>
look how excited I am about you contributing it's making me squeal
<alyssa>
EEEE
<alyssa>
:P
benjamin1 has joined #dri-devel
illwieckz has joined #dri-devel
<tarceri>
Anyone able to run this piglit test on the close nvidia driver for me? https://pastebin.com/r73KTYge I think the hdd is dead in the laptop I normally use for testing
<zmike>
I can get it tomorrow if nobody gets it before me
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
bmodem has joined #dri-devel
benjamin1 has joined #dri-devel
nehsou^ has quit [Remote host closed the connection]
benjamin1 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
thaytan has quit [Ping timeout: 480 seconds]
thaytan has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
kzd has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
benjamin1 has joined #dri-devel
<cmarcelo>
airlied: for NV_compute_shader_derivatives there are a couple of tests in crucible.
tm512 has quit [Quit: Just relax and enjoy this pleasant adventure.]
benjamin1 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
Kayden has joined #dri-devel
fab has joined #dri-devel
aravind has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
fab has quit [Quit: fab]
tursulin has joined #dri-devel
evadot has quit [Quit: leaving]
evadot has joined #dri-devel
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
fab has joined #dri-devel
fab has quit [Quit: fab]
apinheiro has joined #dri-devel
jfalempe_ is now known as jfalempe
lordheavy has quit [Quit: Konversation terminated!]
benjamin1 has joined #dri-devel
<mripard>
javierm: It's not really the same thing DPI is to send the pixels, SPI to control it
<mripard>
macromorgan: wants to operate the controller using SPI to send both
<mripard>
so it requires a massive undertaking, because then you don't need to connect to a CRTC, etc. You are the CRTC (and plane, and so on)
<mripard>
the controller setup is completely different too
<mripard>
so I don't think it's worth it to handle both cases in the same driver, we wouldn't be able to share much (if at all)
benjamin1 has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: because cross context stuff is weird
<karolherbst>
maybe something in st/mesa doesn't do some weirdo implicit flush
<karolherbst>
the programming model of gl doesn't really allow any kind of sanity here, so it's all implicit, and I guess if another context needs a resource we have to flush stuff out or _something_ didn't take a good look at those flakes, but .... something something
<javierm>
mripard: thanks for the explanation. I thought that it was just a different transport just like some drivers support both SPI and I2C
<mripard>
yeah, those controllers are usually fairly flexible, and can indeed be controlled by I2C or SPI, but also take their pixels directly from these buses
<mripard>
the driver to handle the latter is panel-mipi-dbi
thellstrom has quit [Ping timeout: 480 seconds]
Ahuj has joined #dri-devel
<javierm>
mripard: right, I know that there are some generic drivers dor mipi-dbi and mipi-dsi for controllers that don't have a custom init sequence (or that the init is handled by firmware?)
<mripard>
it's not the same answer for both cases :)
<mripard>
I don't think we assume anywhere that the firmware will init a panel
<javierm>
I've to admit that I'm not that familiar with dbi and dsi. But if you think that is not worth to share then a new tiny driver makes sense
<mripard>
especially since we like to power it up and down on demand
<mripard>
DBI is just a fancy MIPI word for sending data over SPI
<javierm>
mripard: because when I upstreamed the drivers/gpu/drm/panel/panel-himax-hx8394.c for the PinePhonePro, I was told that couldn't use the MIPI-DSI generic driver because it needed a custom init seq
<javierm>
so I wondered how panels that use that use drivers/gpu/drm/drm_mipi_dsi.c handle their init seq
<javierm>
mripard: how different is mipi-dbi with 4-wire SPI ? I wonder if the handling of D/C pin that macromorgan mentioned is just dbi ?
<mripard>
Those controllers are likely to need some kind of panel-specific initialization (which is usually quite obscure, and can't be made generic because it also depends on the panel tied to the controller). This is handled by the linux firmware interface and we will just request a firmware that contains the init sequence and send that to the controller
<javierm>
mripard: got it. That was my guess indeed, and for controllers that don't have a linux driver, then you need to do those mipi_dsi_dcs_write_seq() calls
<mripard>
DSI can handle pixels and control sequences over the bus, so then you have two cases: either the DSI panel doesn't require any initialization (instead of the dumb stuff everyone does like a reset GPIO or a regulator), in which case we should use panel-mipi-dsi
<mripard>
or it requires some kind of init sequence, in which case we have a panel-specific driver for it
<mripard>
which explains the answer you got for the Pinephone Pro I guess?
benjamin1 has joined #dri-devel
<mripard>
for the DC pin, I didn't read the whole discussion, let me have a look
<mripard>
ah right, I remember
<mripard>
it has an extra pin, or it can use an extra bit
<mripard>
I used it in 9 bits per word and ignored that pin entirely
<javierm>
mripard: yes, that's what I suggested macromorgan to do as well
<javierm>
so mipi-dbi is just the 3-wire SPI (that has a 1-bit D/C before the 8-bit payload)
<mripard>
not all SPI controllers can do that though, so I used a spi-gpio controller last time I used it
<mripard>
MIPI-DBI is 4 wire SPI iirc
<mripard>
that controller wanted to do something fancy, but that has nothing to do with the spec afaik
<mripard>
spi-gpio might be too slow if you're sending pixels with it too though
<javierm>
mripard: you said that mipi-dbi is 4-wire SPI, but you meant 3-wire right ?
<javierm>
4-wire is with the D/C as an external pin and 3-wire is when is encoded in the payload
<mripard>
Clock, MISO, MOSI, CS ?
benjamin1 has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
djbw has quit [Read error: Connection reset by peer]
vliaskov has joined #dri-devel
benjamin1 has joined #dri-devel
<javierm>
mripard: usually in the datasheets for these panels only clock, MOSI and CS are considered since you just write to the peripheral, not read from it
benjamin1 has quit [Ping timeout: 480 seconds]
<javierm>
that's why is called 3-wire SPI protocol I think
<mripard>
sure, but you were asking for MIPI-DBI
<mripard>
whether the devices follow the spec is another story :)
<javierm>
mripard: right, but in panel lingo (at least in the datasheets I read) 3-wire is what I mentioned and 4-wire is with the additional D/C (data/command) external pin
<javierm>
mripard: so I wondered whether MIPI-DBI was the "3-wire protocol" that sends 9-bit SPI messages with the D/C bit encoded before the 8-bit payload
<javierm>
if that's the case, then I think that macromorgan can just use your driver ?
cmichael has joined #dri-devel
<mripard>
no, MIPI-DBI is plain old SPI
<mripard>
and no, he can't, because my driver is made for that controller taking its pixels from an RGB bus
<javierm>
mripard: I see
<mripard>
he needs to use panel-mipi-dbi
Haaninjo has joined #dri-devel
<javierm>
Ok
<mripard>
and just ignore that D/C pin, but use an extra bit per word
<javierm>
mripard: yup, which is the "3-wire protocol" I mentioned. But now I understand my confusion, you do that manually in your driver
<javierm>
that u16 txbuf = ((prefix & 1) << 8) | data
<javierm>
so is "3-wire protocol" over mipi-dbi
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
gildekel has quit [Quit: Connection closed for inactivity]
lemonzest has quit [Quit: WeeChat 3.6]
lemonzest has joined #dri-devel
benjamin1 has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
benjamin1 has quit [Ping timeout: 480 seconds]
ngcortes has quit [Ping timeout: 480 seconds]
sgruszka has joined #dri-devel
benjamin1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
andrey-k- has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
andrey-k- has quit []
clever has quit [Ping timeout: 480 seconds]
clever has joined #dri-devel
benjamin1 has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
<alyssa>
karolherbst: That test seems to glFinish() before each context switch. So should be fine. "should".
<karolherbst>
yeah..... "should"
sgruszka has quit [Ping timeout: 480 seconds]
<karolherbst>
alyssa: what I noticed while figuring out multithreading for nouveau is, that a lot of state tracking assumptions just don't hold anymore if you have a second context involved. But that also depends on how hardware vs context state is tracked.
<pq>
I wonder if Weston should glFinish() before exiting, too, to make sure no job is still running and upsetting ASan...
<pq>
No, that's not it.
<pq>
Huh. Making sure that swrast_dri.so is never unloaded *fixes* all ASan reported leaks.
<karolherbst>
can't have leaks if you never delete references
<karolherbst>
probably some screen cleanup not happening properly or something?
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<karolherbst>
pq: we also have some static init methods around, like the glsl stuff
<karolherbst>
maybe some unref on it is missing?
<karolherbst>
kinda depends on what's leaked here
benjamin1 has joined #dri-devel
<pq>
It's a bit hard to see, because getting a good stack trace depends on not unloading...
Shibe has quit [Quit: Ping timeout: 265.2533444 seconds]
Shibe has joined #dri-devel
<karolherbst>
mhhhh
<karolherbst>
I think there was a solution for this..
<pq>
building Mesa with ASan does something differently, but previously swrast always deadlocked inside ASan's own code. Maybe I need to try again, since I was actually able to run swrast with weston+ASan without deadlocking and no idea why.
<karolherbst>
pq: _but_ what valgrind calls "reachable" is probably what's leaking here
<karolherbst>
ohhh
<karolherbst>
valgrind can report that stuff if you use valgrind
<javierm>
tzimmermann: hope that the motivation for the split makes more sense now after my explanation of how we manage the kernel package config options
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
dolphin has quit [Quit: Coyote finally caught me]
benjamin1 has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
Company has joined #dri-devel
benjamin1 has quit [Ping timeout: 480 seconds]
<zmike>
tarceri: pass
<tarceri>
zmike: though it would thanks for testing
<tarceri>
seems we had a compile test for this kind of thing it mesa but it only passed because everything get optimised away.
kts has joined #dri-devel
illwieckz has quit [Ping timeout: 480 seconds]
camus has quit [Remote host closed the connection]
<alyssa>
jenatali: nir_opt_preamble, I want to (more or less) remat phis, which is only safe if I can remat the if-statement, which I can figure out based on the nir_if->condition
<karolherbst>
yeah.. I'll figure it out
<jenatali>
alyssa: It's not just one if condition though, you'd need to be able to remat all values leading up to the branches that the phi depends on
<alyssa>
that.. should be fine, I think
<alyssa>
phi can be remat <===> if-condition and all of the phi's sources can be remat
<jenatali>
e.g. if (a) { if (b) { %5 = 1; } else { %6 = 2; } } else { % 7 = 3; } could have a phi selecting any of those, so you'd need to be able to capture a and b
<alyssa>
right, if `b` can't be remat, then %5 can't either
<jenatali>
Right
<alyssa>
so `phi %5` at the end won't be remat even if a can be remat
<alyssa>
(Actually, it's more complicated than that. If %5 can be speculated, we can pull it out of the if when rematerializing so it wouldn't matter if b can be remat.)
<alyssa>
opt_preamble is a funny pass.
<alyssa>
I'm.. mostly sure what I'm doing is kosher, i just need to get at the if from the phi
<alyssa>
I guess nir_cf_node_prev(phi->instr->block)
<jenatali>
Should be right, yeah
<karolherbst>
jenatali: ... it's a 32 bit NULL pointer :')
<jenatali>
Weird
<karolherbst>
ehh wait.. maybe it's the return type being messed up actually
<karolherbst>
I suspect if llvm turned the event pointer to be 64 bit, then we kinda have to deal with that...
<karolherbst>
I'll try to figure out if it's a llvm or translator change
<jenatali>
I'd expect that the SPIR-V translator should still chase it to an event type, not a pointer to event
<karolherbst>
ohh true, but an event is opaque
<jenatali>
Right, so it should be passed by value, i.e. showing up in the function signature as a value type, and when vtn parses the decl it should put an int in the signature
<karolherbst>
why? an event isn't an int
<jenatali>
And then it's unused by the libclc implementation of the function so it'll all get DCE'd
<jenatali>
An event doesn't do anything in nir or in libclc, so we can pick whatever we want to represent it
<jenatali>
I tried to add a nir type for it and gfxstrand suggested to do it this way instead :P
<karolherbst>
right..
<karolherbst>
so the signature in the libclc spirv is: %6312 = OpTypeFunction %_ptr_Function_uchar %_ptr_Workgroup_uchar %_ptr_CrossWorkgroup_uchar %ulong %ulong %_ptr_Function_uchar
<jenatali>
Looks like the SPIRV-LLVM-Translator maybe changed the parsing from taking it by value to making it a byte*
<karolherbst>
mhh...
<alyssa>
jenatali: seems to work in the case I wanted it to
<karolherbst>
in llvm-15 it was `%Event = OpTypeEvent`
<karolherbst>
so they turned that into a pointer now
<jenatali>
Yeah
<karolherbst>
whoever it was
<alyssa>
which incidentally means entire CTS cases just get optimized away to absolutely nothing other than `gl_FragColor = <uniform>` and the whole case is in the preamble
<jenatali>
That makes sense, it was passed as a pointer-to-event in the LLVM IR probably and now the pointer loses its type info so the translator can't chase it anymore
<jenatali>
Fun... anyway should be easy enough to just make the event pointer-sized instead of always 32-bit
<karolherbst>
yeah...
<karolherbst>
just wondering how to properly deal with it...
<karolherbst>
however.. I wonder
<karolherbst>
maybe we have to enable opaque pointers now
apinheiro has quit [Quit: Leaving]
<jenatali>
As long as the translator can deal with it, that sounds fine
<karolherbst>
other bugs
<karolherbst>
:D
<Lynne>
how can I get the GFX version from an anv_physical_device?
<cmarcelo>
Lynne: there's an info field. dev->info.ver or dev->info.verx10
<cmarcelo>
verx10 give you a more "detailed" number if you need to distinguish between vers.
<Lynne>
thanks!
<karolherbst>
that's.... better I think?
<karolherbst>
uhhhhh...
<karolherbst>
something is horribly broken
<karolherbst>
jenatali: which opaque pointers enabled, I get the event type into the function arg, but now it does... this:
<karolherbst>
Also, "The opaque pointer mode can be disabled using -opaque-pointers=0 in LLVM tools like opt, or -Xclang -no-opaque-pointers in clang."
<airlied>
ah but going.forward disabling isnt an option we csn rely on
<karolherbst>
I know
<karolherbst>
but it's broken
<karolherbst>
the translator is still working through that stuff
<airlied>
ah its likely libclc or translator that need fixing, though maybe some opencl specific psths havent been fixed
<karolherbst>
yeah
<karolherbst>
so opaque types are bonkers
<karolherbst>
and some deref stuff is also broken
<karolherbst>
I'm sure with llvm-17 this will probably all just work