ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
<alyssa> airlied: um, remember Corellium? company virtualizing iPhones, bested Apple in court, did a quick n' dirty M1 Linux port in Jan 2021 as a flex?
<alyssa> their preloader had a magic register write to turn the iboot framebuffer into bgra8 (it boots as rgb10a2 which confuses some linux userspace)
<alyssa> a few months ago I just manually tried setting all the registers on that page to different values
<alyssa> (and dumping values and looking for patterns etc)
<airlied> alyssa: ah nice
<alyssa> found a bunch more format codes, etc
<airlied> just don't write a DCP driver at all then :-P
<alyssa> mostly useless stuff without the context (e.g. I know the format code for "compressed rgba8" but using it crashes the system and needs a reboot, waow!)
<alyssa> so the answer is "trial and error from a magic seed"
<alyssa> The real question is, where did Corellium get that register from?
<alyssa> (The format register. I found the plane address registers independently)
<alyssa> Three possibilities, in descending order of likeliness:
<alyssa> 1. The DCP is new in A14 (~= M1). They've been r/e'ing iPhones for years, so they probably already r/e'd the whole register block and have a virtual model. This reversing could be either MMIO traces or IDA or both.
co1umbarius has joined #dri-devel
<airlied> alyssa: it's possible the boot fw sets up display using that before loading the DCP fw
<airlied> but also possible the same hw is in older non-DCP devices
<alyssa> 2. The Apple cores have lots of firmware, but they want to emulate at the register level, so they have lots of infrastructure to run firmware in emulators and mmiotrace them. So they could've done DCP that way
<alyssa> 3. They could've just decompiled the DCP firmware and poked around until they found what was needed.
columbarius has quit [Ping timeout: 480 seconds]
<alyssa> I give >90% probability to possibility #1 (the reg block is the same as non-DCP devices, the driver was just split in half)
cengiz_io has joined #dri-devel
pendingchaos_ is now known as pendingchaos
<alyssa> airlied: "it's possible the boot fw sets up display using that before loading the DCP fw"
<alyssa> as I understand, the boot fw uses the DCP fw to setup display on the M1
<alyssa> but the DCP has a dumbed down iboot interface so the bootloader doesn't need to speak iokit
Lucretia has quit []
cef is now known as Guest5104
cef has joined #dri-devel
Guest5104 has quit [Ping timeout: 480 seconds]
cef is now known as Guest5105
cef has joined #dri-devel
Guest5105 has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
sdutt has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
boistordu_old has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
slattann has quit []
sdutt has joined #dri-devel
sdutt has quit [Remote host closed the connection]
sdutt has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
sdutt has quit [Remote host closed the connection]
slattann has joined #dri-devel
Duke`` has joined #dri-devel
danvet has joined #dri-devel
sumits has joined #dri-devel
xexaxo_ has quit [Ping timeout: 480 seconds]
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
<tomeu> airlied: do you have any thoughts on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12369 ?
<airlied> tomeu: it's kinda the opposite of how I wanted to take things, since I was hoping to move more stuff to the recording side, but it probably really isn't a problem to not do that,
<airlied> and anything that removes my hand rolled code is probably a good thing
<airlied> could venus use this as well?
<tomeu> airlied: my thinking was that anything that one needs to do for performance can be moved to the first time that the command is executed, and stored in void *driver_data
<airlied> yeah that's probably fine as a solution if needs be
<airlied> tomeu: so there is hardware you can't bake the command stream for without the framebuffer?
<airlied> I though vulkan had been careful to not have that situation with tilers
<airlied> and you would still get enough info by other means
<tomeu> regarding venus, they record commands in the host, not the guest
<tomeu> but probably a similar python script could be used to reduce some hand-written code
<airlied> they must transport the commands from the host to the guest at some point
<tomeu> regarding hw that forces to defer command encoding, I guess that's the reason why the spec says that by not specifying the FB of a secondary command buffer, there could be a performance penalty
<airlied> or are they taking a vm exit on every vk cmd
<airlied> tomeu: ah is this only for the secondary command buffer with no fb case?
<airlied> I'm surprised they left that as non-optional if drivers have to jump through this sort of hoop
<tomeu> at least panfrost and broadcom have those situations
<airlied> seems very unvulkan like
<tomeu> yeah
lemonzest has joined #dri-devel
alanc has quit [Remote host closed the connection]
thellstrom has joined #dri-devel
alanc has joined #dri-devel
<airlied> tomeu: well if it passes CI then a complete deqp-vk run locally I've no issues with moving lvp to it
<tomeu> cool
<tomeu> regarding venus, guess the main problem is that they have a quite compact format for the commands
<tomeu> I'm not sure though how much of a difference this makes in practice
frieder has joined #dri-devel
rasterman has joined #dri-devel
Daanct12 has joined #dri-devel
Danct12 has quit [Ping timeout: 480 seconds]
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
Lucretia has joined #dri-devel
i-garrison has quit []
<MrCooper> airlied: Present might be better overall even with no HW, e.g. at least fake vsync instead of always full throttle
lynxeye has joined #dri-devel
mlankhorst has joined #dri-devel
mlankhorst has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
pnowack has joined #dri-devel
i-garrison has joined #dri-devel
bcarvalho has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
pcercuei has joined #dri-devel
Ahuj has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
shfil has joined #dri-devel
thellstrom has joined #dri-devel
ppascher has quit [Quit: Gateway shutdown]
hch12907_ has quit [Read error: Connection reset by peer]
ppascher has joined #dri-devel
hch12907_ has joined #dri-devel
tursulin has joined #dri-devel
<kusma> airlied: We're probably going to need this stuff for Dozen also, because D3D12 doesn't allow simultaneous use of command-buffers, unlike vulkan...
pochu has joined #dri-devel
pcercuei has quit [Quit: brb]
dolphin has quit [Ping timeout: 480 seconds]
pcercuei has joined #dri-devel
rando25902 is now known as rando25892
dolphin` has joined #dri-devel
dolphin` is now known as dolphin
Daanct12 is now known as Danct12
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
karolherbst_ has joined #dri-devel
karolherbst has quit [Remote host closed the connection]
vivijim has joined #dri-devel
slattann has quit []
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
Company has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Read error: Connection reset by peer]
<emersion> jekstrand: what's the status of this patch? https://lore.kernel.org/dri-devel/20210610210925.642582-1-jason@jlekstrand.net/
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
<emersion> cc danvet too i guess ^
<danvet> bnieuwenhuizen wanted to check out how this would look for radv and then it kinda got nowhere further
<danvet> yet, at least
<emersion> ah, so waiting for some more user-space impls?
Peste_Bubonica has joined #dri-devel
jewins has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
xexaxo_ has joined #dri-devel
tursulin has quit [Quit: Konversation terminated!]
vivijim has quit [Read error: Connection reset by peer]
vivijim has joined #dri-devel
<danvet> emersion, yeah-ish
tursulin has joined #dri-devel
<FLHerne> I have mesa 21.2 and an Ivy Bridge laptop; should crocus be reasonably usable for everyday stuff?
<FLHerne> [Plasma on Wayland with Firefox and the odd OpenGL-based game]
iive has joined #dri-devel
sylware has joined #dri-devel
Sumera[m] is now known as Sumera
sylware has quit []
<Sumera> test
<Sumera> melissawen: about the vblank_put messages, how does something like this sound: https://pastebin.pl/view/5c7c0be3 (just the approach, patch isn't fully right)
<Sumera> I also tried just disabling the vblank_get/put statements in vkms_composer.c (and that seems to avoid the errors) but it's a bit hacky and I can't figure out how to check if vhw is enabled from within vkms_set_composer() .
shfil has quit [Ping timeout: 480 seconds]
xexaxo_ has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
karolherbst_ is now known as karolherbst
sdutt has joined #dri-devel
nchery has joined #dri-devel
<melissawen> Sumera, hmm... why should we include this message?
<melissawen> btw, I just checked your approach and realized that would be better do not set any crc operations when virtual_hw, since this mode does not support crc yet
<melissawen> I mean, in your new "vkms_crtc_vhw_funcs"
<agd5f> what is the preferred method to submit patches to gpuvis?
<dj-death> tarceri: were you expecting tests/spec/glsl-1.30/execution/switch/fs-shadow-variable.shader_test to fail?
<dj-death> tarceri: Failed to compile FS: 0:12(8): error: `var_0' redeclared
<dj-death> tarceri: not sure whether that's maybe an incompatible GL version that would trigger that
shfil has joined #dri-devel
<Sumera> melissawen: ah, sorry, that message was just to see the value
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
i-garrison has quit []
<bnieuwenhuizen> agd5f: seems like a github PR to me?
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
rando25902 has joined #dri-devel
frieder has quit [Remote host closed the connection]
rando25892 has quit [Ping timeout: 480 seconds]
<sravn> FLHerne: Yep, crocus is in a very good shape today so go ahead and use it. If you find anything make sure to report is if there is no open bugs already
<agd5f> bnieuwenhuizen, I emailed mike, but I can try that if I don't hear back
<agd5f> thanks
i-garrison has joined #dri-devel
nchery is now known as Guest5171
nchery has joined #dri-devel
Guest5171 has quit [Ping timeout: 480 seconds]
Ahuj has quit [Ping timeout: 480 seconds]
sdutt has quit []
sdutt has joined #dri-devel
<alyssa> jenatali: ...does 9on12 + vkd3d work as an alternative to dxvk 😋
<jenatali> alyssa: Probably? But I have to imagine it would be much slower and/or less featureful
<alyssa> alas :d
<alyssa> also I guess API != DDI
<jenatali> 9on12 goes for correctness before performance, and has the benefit of the D3D9 runtime doing a lot of the heavy lifting (e.g. fixed-function -> shader conversion, implementing stupid API validation, etc)
<alyssa> ah, sure
<alyssa> 10on12 and 11on12 are still proprietary I guess?
<jenatali> D3D10 and D3D11 are one-and-the-same these days
<alyssa> Oh hey
<alyssa> neato 😄
<jenatali> All of Microsoft's graphics mapping layers are now open-source :)
<alyssa> help i can't run this D3D7 app on this bootleg Windows 9 on Arm image i have running on my old armv7 raspberry pi
<jenatali> FYI 9on12 actually supports all versions of D3D prior to 10, from 3 or 4 thru 9
<jenatali> Including DDraw :)
<alyssa> Incredible
thellstrom has quit [Remote host closed the connection]
camus1 has quit [Remote host closed the connection]
camus has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<milek7> is 9on12 used by windows normally?
<jenatali> Only if there's no native D3D9 driver. This is currently the case on Qualcomm-based devices (Windows on ARM)
<milek7> in my experience old d3d games have trouble running without something like http://dege.freeweb.hu/dgVoodoo2/
<milek7> (by old I mean <9)
<jenatali> Yeah, they should still work, and if they don't, that's something that our team should fix, but to be honest we're only so many people and it's hard to prioritize things like that sometimes
<jenatali> Especially when those kinds of workarounds do exist
slattann has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
jessica_24 has joined #dri-devel
hch12907_ has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
idr has joined #dri-devel
Ahuj has joined #dri-devel
shfil has quit [Remote host closed the connection]
slattann has quit []
slattann has joined #dri-devel
zmike has quit []
zmike has joined #dri-devel
zmike has quit []
zmike has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
hch12907 has joined #dri-devel
NiksDev has joined #dri-devel
tarceri_ has joined #dri-devel
tarceri has quit [Read error: Connection reset by peer]
pnowack has quit [Quit: pnowack]
mbrost has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
mbrost has quit [Read error: Connection reset by peer]
camus has joined #dri-devel
Ahuj has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
hch12907_ has joined #dri-devel
slattann has quit []
hch12907 has quit [Ping timeout: 480 seconds]
slattann has joined #dri-devel
slattann has quit []
mlankhorst has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: Quitting]
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
<alyssa> This smells really funny, since mesa/main refuses to probe on that GPU
<alyssa> Is arch linux arm patching out our check? 🤔
<imirkin> alyssa: dunno about your situation, but i've taken public branches down because they were getting patched in by people
<imirkin> that killed off my multithreading work (and any desire to continue on it)
shfil has joined #dri-devel
<mattst88> presumably the problem wasn't that people were testing your branch. it was that they were... what, exactly?
<airlied> alyssa much more likely that mesa driver is broken in tree
<alyssa> imirkin: Woof woof.
<alyssa> airlied: Yeah, though I'm unsure how this check would break.
<Sachiel> assuming that a branch that has not been merged upstream yet is stable and expecting everything to work flawlessly and instead of providing constructive bug reports just saying things like "MAH GAME IS BROKEN AND IT WORKS ON PROPRIETARY DRIVER. FIX IT"
<alyssa> Sachiel: tbf i feel that way about bug reports to upstream too for any hardware other than mali g52 at this point 😅
<airlied> alyssa: they said two distros also
<alyssa> (and for any api other than gles3.1)
<alyssa> If it wasn't an edge over the proprietary driver I would be inclined not to ship desktop gl at all tbh
<alyssa> the check in question, pretty impossible for that to be buggy
<airlied> the build they linked to has no patches except for vc4 neon
<alyssa> Yeah... very confused.
<alyssa> I'm not closing as wontfix since there's a good chance the driver /is/ in fact broken on armv7 under some circumstnace
<alyssa> but I am very confused what to do with this given the hardware in question is unsupported
<alyssa> i guess i could uprev my armv7 chromebook..
lynxeye has quit [Quit: Leaving.]
<alyssa> their dmesg says their gpu id is 0x600
<robclark> presumably arch has some sort of dbg package to get better backtrace?
<airlied> Sachiel: that statement applies to nouveau in master as equally
<airlied> alyssa: did you add the.check in newer mesa?
<airlied> so now the driver refuses to load when it did before and they get a crash
<alyssa> airlied: no, that's been there for a while...
<alyssa> also the intention is if we bail it defaults to llvmpipe but i digress
<alyssa> In various forms that switch stmt has been intree since 2019
<LaserEyess> 16:36 < robclark> presumably arch has some sort of dbg package to get better backtrace?
<LaserEyess> unfortunately they don't
<LaserEyess> he'd have to recompile mesa himself with debug settings in his PKGBUILD
<LaserEyess> a big pain on arm
<airlied> alyssa: it could be a change in kmsro
<airlied> since it dies in exynos accessing a null ptr
<airlied> so your sw fallback plan is possibly broken
<alyssa> airlied: Hum. grumble.
Duke`` has quit [Ping timeout: 480 seconds]
jhli has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
<alyssa> Does a Fixes tag imply a Cc: stable in kernelspace? or is that just a mesa thing?
gouchi has quit [Remote host closed the connection]
<dcbaker> alyssa: I'm pretty sure Mesa copied that from Linux
<alyssa> dcbaker: 👍
<shfil> hi, I've found this project: https://github.com/kjliew/qemu-3dfx
<shfil> maybe for guys who are handling venus the bindings in windows client gonna be interesting
<shfil> I haven't read much, but looks like part of OpenGL(?) resources is passed into VM with old windows
<shfil> some videos with it are impressive https://www.youtube.com/watch?v=H0IwylEIJ0Q
jkrzyszt has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
rasterman has quit [Quit: Gettin' stinky!]
ngcortes has quit [Remote host closed the connection]
vivijim has quit [Ping timeout: 480 seconds]
pcercuei has quit [Quit: dodo]
iive has quit []
<alyssa> anholt_: Looking at suite support again, now that I need KHR-GLES* in CI,
<alyssa> It only seems to be running the first [[deqp]] block in the toml file?
<alyssa> (That's only running gles2 despite gles2/3/31 all being specified)
<Plagman> admin should probably edit this?
shfil has quit [Ping timeout: 480 seconds]
<alyssa> Hm. Seems to work for other driver CIs but I don't see anything obviously different
vivijim has joined #dri-devel
<alyssa> + deqp-runner junit --testsuite gles2
<alyssa> this is probably a smoking gun
<alyssa> that's inherited from LAVA's `DEQP_VER: gles2`
<alyssa> in .lava-test
<alyssa> although you're setting that explicitly in the freedreno .yml "for render check" so maybe that's all fine
<alyssa> oh, here's the actual smoking gun
<alyssa> + deqp-runner run --deqp /deqp/modules/gles2/deqp-gles2
<alyssa> vs freedreno
<alyssa> + deqp-runner suite --suite //install/deqp-freedreno-a630.toml
heat has joined #dri-devel
<alyssa> oh this is so embarassing
<alyssa> er, no
<alyssa> i mean it's probably embarassing but not what i thought..
tarceri_ has quit [Remote host closed the connection]
<alyssa> so my DEQP_SUITE var isn't propagating
tarceri_ has joined #dri-devel
jhli has quit [Ping timeout: 480 seconds]
Peste_Bubonica has quit [Quit: Leaving]
<alyssa> okay, yeah. rebased on main and it's fine now 🤷