ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
Akari has quit [Quit: segmentation fault (core dumped)]
tango_ has quit [Server closed connection]
tango_ has joined #dri-devel
Lucretia has quit [Server closed connection]
Leopold_ has joined #dri-devel
Lucretia has joined #dri-devel
inverted has joined #dri-devel
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
i-garrison has quit [Ping timeout: 480 seconds]
TheSwordOfMyBone has quit [Server closed connection]
TheSwordOfMyBone has joined #dri-devel
yuq825 has joined #dri-devel
jbarnes has quit [Server closed connection]
jbarnes has joined #dri-devel
demarchi has quit [Server closed connection]
demarchi has joined #dri-devel
i-garrison has joined #dri-devel
SolarAquarion has quit [Server closed connection]
mslusarz has quit [Server closed connection]
mslusarz has joined #dri-devel
Lightsword has quit [Server closed connection]
Lightsword has joined #dri-devel
natto has quit [Server closed connection]
natto has joined #dri-devel
lina has quit [Server closed connection]
lina has joined #dri-devel
SolarAquarion has joined #dri-devel
tarceri has quit [Server closed connection]
tarceri has joined #dri-devel
haagch has quit [Server closed connection]
haagch has joined #dri-devel
ishitatsuyuki has quit [Server closed connection]
ishitatsuyuki has joined #dri-devel
graphitemaster has quit [Server closed connection]
graphitemaster has joined #dri-devel
phire has quit [Server closed connection]
phire has joined #dri-devel
cef has quit [Server closed connection]
cyrozap has quit [Server closed connection]
cyrozap has joined #dri-devel
cef has joined #dri-devel
APic has quit [Server closed connection]
APic has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
tales-aparecida has quit [Server closed connection]
tales-aparecida has joined #dri-devel
leandrohrb has quit [Server closed connection]
leandrohrb has joined #dri-devel
heat has joined #dri-devel
sauce has quit [Server closed connection]
sauce has joined #dri-devel
eletrotupi has quit [Server closed connection]
eletrotupi has joined #dri-devel
i-garrison has quit [Ping timeout: 480 seconds]
lemonzest has joined #dri-devel
Rayyan has quit [Server closed connection]
Rayyan has joined #dri-devel
Leopold_ has quit []
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ifreund has quit [Server closed connection]
ifreund has joined #dri-devel
mlankhorst has quit [Server closed connection]
mlankhorst has joined #dri-devel
robertfoss has quit [Server closed connection]
robertfoss has joined #dri-devel
Guest2420 has quit [Server closed connection]
sumoon has joined #dri-devel
kennylevinsen has quit [Server closed connection]
kennylevinsen has joined #dri-devel
Leopold has joined #dri-devel
Leopold has quit []
Leopold has joined #dri-devel
kchibisov has quit [Server closed connection]
kchibisov has joined #dri-devel
rpigott has quit [Server closed connection]
rpigott has joined #dri-devel
Leopold has quit []
mhenning has quit [Quit: mhenning]
vyivel has quit [Server closed connection]
vyivel has joined #dri-devel
bl4ckb0ne has quit [Server closed connection]
bl4ckb0ne has joined #dri-devel
pinchartl has quit [Server closed connection]
pinchartl has joined #dri-devel
Leopold_ has joined #dri-devel
bmodem has joined #dri-devel
yang3 has quit [Server closed connection]
yang3 has joined #dri-devel
thaytan has joined #dri-devel
milek7_ has quit [Server closed connection]
milek7 has joined #dri-devel
tonyk has quit [Server closed connection]
tonyk has joined #dri-devel
chadv has quit [Server closed connection]
chadv has joined #dri-devel
chadv is now known as Guest171
melissawen has quit [Server closed connection]
siqueira has quit [Server closed connection]
melissawen has joined #dri-devel
kisak has quit [Server closed connection]
kisak has joined #dri-devel
ajax has quit [Server closed connection]
ajax has joined #dri-devel
siqueira has joined #dri-devel
hakzsam has quit [Server closed connection]
hakzsam has joined #dri-devel
aleasto has quit [Server closed connection]
aleasto has joined #dri-devel
xypron has quit [Server closed connection]
xypron has joined #dri-devel
ZeZu has quit [Server closed connection]
ZeZu has joined #dri-devel
jessica_24 has quit [Server closed connection]
kj has quit [Server closed connection]
jessica_24 has joined #dri-devel
kj has joined #dri-devel
lemes has quit [Server closed connection]
lemes has joined #dri-devel
mupuf has quit [Server closed connection]
mupuf has joined #dri-devel
krh has quit [Server closed connection]
krh has joined #dri-devel
MTCoster has quit [Server closed connection]
MTCoster has joined #dri-devel
olv_ has quit [Server closed connection]
olv_ has joined #dri-devel
bmodem1 has joined #dri-devel
HdkR has quit [Server closed connection]
HdkR has joined #dri-devel
robclark has quit [Server closed connection]
robclark has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
q66 has quit [Server closed connection]
q66 has joined #dri-devel
Shibe has quit [Server closed connection]
Shibe has joined #dri-devel
mattrope has quit [Server closed connection]
mairacanal has quit [Server closed connection]
mattrope has joined #dri-devel
mairacanal has joined #dri-devel
rcf has quit [Server closed connection]
rcf has joined #dri-devel
bmodem has joined #dri-devel
jani has quit [Server closed connection]
jani has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
CounterPillow has quit [Server closed connection]
CounterPillow has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
Leopold_ has quit [Remote host closed the connection]
aravind has joined #dri-devel
lileo has quit [Server closed connection]
lileo has joined #dri-devel
rcn-ee__ has quit [Server closed connection]
rcn-ee__ has joined #dri-devel
zzag has quit [Server closed connection]
zzag has joined #dri-devel
ernstp___ has quit [Server closed connection]
ernstp___ has joined #dri-devel
Leopold_ has joined #dri-devel
cwabbott has quit [Server closed connection]
cwabbott has joined #dri-devel
glisse has quit [Server closed connection]
glisse has joined #dri-devel
mareko has quit [Server closed connection]
mareko has joined #dri-devel
bmodem has joined #dri-devel
airlied has quit [Server closed connection]
airlied has joined #dri-devel
jekstrand has quit [Server closed connection]
jekstrand has joined #dri-devel
Lyude has quit [Server closed connection]
bmodem1 has joined #dri-devel
Lyude has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
heat has quit [Remote host closed the connection]
lstrano_ has quit [Server closed connection]
heat has joined #dri-devel
lstrano_ has joined #dri-devel
Ryback_ has quit [Server closed connection]
rsripada has quit [Server closed connection]
rsripada has joined #dri-devel
quantum5 has quit [Server closed connection]
quantum5 has joined #dri-devel
bmodem has joined #dri-devel
nchery has quit [Ping timeout: 480 seconds]
bmodem1 has quit [Ping timeout: 480 seconds]
codingkoopa9 has quit [Server closed connection]
codingkoopa9 has joined #dri-devel
aknautiy has quit [Server closed connection]
aknautiy has joined #dri-devel
soreau has quit [Server closed connection]
soreau has joined #dri-devel
Daanct12 has joined #dri-devel
Kayden has quit [Server closed connection]
Kayden has joined #dri-devel
andrey-konovalov has quit [Server closed connection]
bmodem1 has joined #dri-devel
andrey-konovalov has joined #dri-devel
sumits has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
evadot_ has quit [Server closed connection]
evadot has joined #dri-devel
bcheng has quit [Server closed connection]
bcheng has joined #dri-devel
cphealy has quit [Server closed connection]
cphealy has joined #dri-devel
Daanct12 has quit [Remote host closed the connection]
macromorgan has quit [Server closed connection]
kode54 has quit [Server closed connection]
macromorgan has joined #dri-devel
kode54 has joined #dri-devel
DragoonAethis has quit [Server closed connection]
DragoonAethis has joined #dri-devel
clever has quit [Server closed connection]
clever has joined #dri-devel
samuelig has quit [Server closed connection]
samuelig has joined #dri-devel
samuelig is now known as Guest198
Duke`` has joined #dri-devel
i-garrison has joined #dri-devel
unerlige has quit [Server closed connection]
i-garrison has quit []
unerlige has joined #dri-devel
i-garrison has joined #dri-devel
jljusten has quit [Server closed connection]
jljusten has joined #dri-devel
paulk has quit [Ping timeout: 480 seconds]
fab has joined #dri-devel
karolherbst has quit [Server closed connection]
karolherbst has joined #dri-devel
vsyrjala has quit [Server closed connection]
Duke`` has quit [Ping timeout: 480 seconds]
vsyrjala has joined #dri-devel
itoral has joined #dri-devel
deathmist has quit [Server closed connection]
deathmist has joined #dri-devel
danvet has joined #dri-devel
Thymo_ has quit [Server closed connection]
Thymo has joined #dri-devel
bluebugs has quit [Server closed connection]
bluebugs has joined #dri-devel
rsalvaterra has quit [Server closed connection]
rsalvaterra has joined #dri-devel
mwalle has quit [Server closed connection]
mwalle has joined #dri-devel
Akari has joined #dri-devel
Company has quit [Quit: Leaving]
sh_zam has quit [Server closed connection]
abhinav__ has quit [Server closed connection]
abhinav__ has joined #dri-devel
sh_zam has joined #dri-devel
exit70 has quit [Server closed connection]
kurufu has quit [Server closed connection]
kurufu has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
exit70 has joined #dri-devel
nchery has joined #dri-devel
fab has quit [Quit: fab]
narmstrong has quit [Server closed connection]
narmstrong has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
camus has joined #dri-devel
Leopold_ has quit [Ping timeout: 480 seconds]
naseer_ has quit [Server closed connection]
naseer_ has joined #dri-devel
lplc has joined #dri-devel
kts has joined #dri-devel
ramacassis[m] has quit [Server closed connection]
ramacassis[m] has joined #dri-devel
hfink has quit [Server closed connection]
hfink has joined #dri-devel
frieder has joined #dri-devel
Guest198 is now known as samuelig
x512[m] has quit [Server closed connection]
x512[m] has joined #dri-devel
bwidawsk has quit [Server closed connection]
bwidawsk has joined #dri-devel
norris has quit [Server closed connection]
norris has joined #dri-devel
vliaskov has joined #dri-devel
Leopold_ has joined #dri-devel
shankaru has quit [Server closed connection]
dri-logger has quit [Server closed connection]
dri-logger has joined #dri-devel
shankaru has joined #dri-devel
tursulin has joined #dri-devel
jfalempe has joined #dri-devel
fab has joined #dri-devel
Mangix has quit [Remote host closed the connection]
Mangix has joined #dri-devel
dcz_ has joined #dri-devel
SanchayanMaity has quit [Server closed connection]
SanchayanMaity has joined #dri-devel
lplc has quit []
lplc has joined #dri-devel
tchar has quit [Server closed connection]
tchar has joined #dri-devel
JohnnyonFlame has joined #dri-devel
kxkamil has quit [Server closed connection]
kxkamil has joined #dri-devel
JTL has quit [Server closed connection]
JTL has joined #dri-devel
bmodem has joined #dri-devel
bmodem1 has quit [Ping timeout: 480 seconds]
<MrCooper> DavidHeidelberg[m]: while glxgears isn't a general purpose benchmark, it's perfectly valid for comparing Mesa builds on the same setup, and a 70% performance drop indicates a serious regression somewhere
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
oneforall2 has quit [Server closed connection]
jkrzyszt has joined #dri-devel
oneforall2 has joined #dri-devel
orbea has quit [Server closed connection]
orbea has joined #dri-devel
swalker__ has joined #dri-devel
<DavidHeidelberg[m]> MrCooper: I would add on same setup and build options and compiler optimizations? Question is if it's relevant to any real application/ use 17000 fps -> 6000 fps isn't probably comparable to anything running in real life :)
Leopold_ has quit []
<MrCooper> still, it indicates some bottleneck suddenly got 3x narrower
<MrCooper> which could affect real world apps as well
swalker_ has joined #dri-devel
Leopold_ has joined #dri-devel
swalker_ is now known as Guest216
Leopold_ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
flibitijibibo has quit [Server closed connection]
swalker__ has quit [Ping timeout: 480 seconds]
flibitijibibo has joined #dri-devel
Leopold_ has joined #dri-devel
MajorBiscuit has joined #dri-devel
linusw has quit [Server closed connection]
linusw has joined #dri-devel
bmodem has quit []
Peuc has quit [Server closed connection]
Peuc has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
lynxeye has joined #dri-devel
Guest90 is now known as DemiMarie
warpme____ has quit [Server closed connection]
warpme____ has joined #dri-devel
bmodem has joined #dri-devel
mackerelian9 has quit [Read error: Connection reset by peer]
mackerelian9 has joined #dri-devel
reductum has quit [Server closed connection]
reductum has joined #dri-devel
rasterman has joined #dri-devel
thellstrom has joined #dri-devel
thellstrom has quit [Ping timeout: 480 seconds]
apinheiro has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<emersion> is there a way to check that an arbitrary FD is a DMA-BUF?
<emersion> ideally not tied to a FS
Ryback_ has joined #dri-devel
<emersion> replying to my own question: DMA_BUF_IOCTL_SYNC with invalid flags, e.g. 0
martijnbraam has quit [Server closed connection]
martijnbraam has joined #dri-devel
pcercuei has joined #dri-devel
digetx has quit [Ping timeout: 480 seconds]
dviola has joined #dri-devel
ralf1307[theythem][m] has quit [Server closed connection]
ralf1307[theythem][m] has joined #dri-devel
JohnnyonF has joined #dri-devel
rgallaispou has joined #dri-devel
viciouss[m] has quit [Server closed connection]
viciouss[m] has joined #dri-devel
<apinheiro> dj-death, hi,
<apinheiro> I was about to ping jason about https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9952, but I realized that as that is mostly done
<apinheiro> probably it depends more on you
<apinheiro> do you have any plan to try to do those changes on anv?
<apinheiro> just saying as we are using the ycbcr framework as the base for v3dv
<apinheiro> we are also on the review process of our patches, but the framework part works for us
<apinheiro> so in the end anv doesn't plan to move to the framework, I guess that we could just try to get the framework out of that MR
JohnnyonFlame has quit [Ping timeout: 480 seconds]
kts has quit [Quit: Leaving]
Weiss-Fder[m] has quit [Server closed connection]
Weiss-Fder[m] has joined #dri-devel
elongbug has joined #dri-devel
kts has joined #dri-devel
heat has joined #dri-devel
nielsdg has quit [Server closed connection]
Leopold_ has quit [Remote host closed the connection]
nielsdg has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
Leopold_ has joined #dri-devel
<MrCooper> emersion: seems a bit risky though, what if that maps to a destructive ioctl for a non-dma-buf fd?
tzimmermann has joined #dri-devel
hasebastian[m] has quit [Server closed connection]
hasebastian[m] has joined #dri-devel
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
junaid has joined #dri-devel
<DavidHeidelberg[m]> Btw. would anyone had objection against renaming x86 to x86_64 or alternatively amd64? I personally tend to associate x86 with i386..686 and as alias x86_32, it's for sure not usual name for 64-bit
<Mis012[m]> I don't think I've ever seen it used to mean 64bit
<eric_engestrom> same, x86 without additional specifier means 32bits
<eric_engestrom> I would vote against amd64 though, x86_64 is much easier to distinguish visually from arm64
<DavidHeidelberg[m]> eric_engestrom: amd/arm yeah, it's pain to read, 100% agree on that :)
junaid has quit [Remote host closed the connection]
<Mis012[m]> amd did make some arm64 SoCs, sadly can't find any evidence of them existing in the wild...
<Mis012[m]> PSP is arm, but the x86 SoCs don't have unified address space so meh
<HdkR> Mis012[m]: Opteron A1100 dev boards made it out but K12 never
<Mis012[m]> HdkR: dev boards are even more removed from the BOM cost of a literal PCB than non-dev boards... :P
<Mis012[m]> HdkR: I found a quite nicely priced Juno on ebay, but it's still a lot of money for a toy
<HdkR> Also almost anything new on the market would be a better choice than a Juno or A1100
<Mis012[m]> but it's so hard to find something at a reasonable price...
<HdkR> M1 Mac Mini can be found on sale quite frequently
<Mis012[m]> that's already claimed for having fun with
<Mis012[m]> also no docs
<Mis012[m]> HdkR: can't AMD just use arm64 for PSP and use unified address space like a sane SoC
<HdkR> Sanity? Where's the fun in that?
<Mis012[m]> also how do they justify wasting die space on PCI glue for native amba phy
<dj-death> apinheiro: I can try now
<Mis012[m]> HdkR: the fun in that is that you can then run Linux on the aarch64 core cluster and use standard mmio drivers to access peripherals, instead of having to go through bloody apertures which would probably necessitate ugly patches to any driver you wish to use
<Mis012[m]> sounds like better kind of fun
<apinheiro> dj-death, ok, thanks. At least what we would like to know is about your plans on those patches
mvlad has joined #dri-devel
<apinheiro> so we could adapt if needed (although obviously, for us it would be easier and just great if just that MR got merged)
<apinheiro> dj-death, fwiw, as I mentioned on my last comment on that MR, we have a rebased + rb/ack version of those patches on the v3dv MR
pixelcluster has quit [Quit: Goodbye!]
pixelcluster has joined #dri-devel
<dj-death> apinheiro: you rebase includes anv patches?
yuq825 has quit [Ping timeout: 480 seconds]
<apinheiro> dj-death, yes
<apinheiro> it included all the patches on the original Jason MR
<apinheiro> it was complex to just pick some of them, so I just picked all
<pcercuei> Working on a DMABUF importer right now. Does my importer first have to wait for write-access dma_fences to signal? Or is there a guarantee of some sort that when I add a read-access dma_fence, there are no write-access fences in parallel?
<apinheiro> fwiw, it was complex to just pick some of them, as most of the initial anv patches were cleanups of the ycbcr stuff before moving it to vulkan common
<apinheiro> so it was not possible to just pick the last commit that make the move
<apinheiro> btw, s/included/includes
<LordKalma> Morning! Now that's a working day, I'll repeat my cry for help! :)
<LordKalma> My problem is that I can't put anything on the LCD panel. The backlight is turning on, but I can't display anything... No console, no kmscube.. This is the driver I wrote: https://github.com/ruilvo/panel-jinglitai-jlt4013a . I added lots of debug messages so I could see them in the boot log. This is the buildroot:
<LordKalma> I'm working on this radio that runs linux ("hacking" it). The important part is that it has an LCD panel for which there were no FOSS drivers for. I took the original firmware and re-wrote the driver (the manufacturer wouldn't share the Linux kernel code, even though they were obliged to, you know how it is).
<LordKalma> It also shows some error messages when I try to run `kmscube` on L308. Please look at lines 256-266, 272-276, and 309. Many of those messages are `printk` calls in my code (that I added to try and debug this).
<LordKalma> (I also sent an email about this) :)
rgallaispou has quit []
itoral has quit []
jkhsjdhjs has quit [Ping timeout: 480 seconds]
jkhsjdhjs has joined #dri-devel
kts_ has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
digetx has joined #dri-devel
Akari has quit [Ping timeout: 480 seconds]
kts_ has quit []
<mripard> LordKalma: can you boot with drm.debug=0x1f and ignore_loglevel on the kernel command line?
<mripard> your command line is weird too, it seems like there's a \n after the fbcon argument
<mripard> and video=VGA:480x800 isn't going to be used anyway, it's not a valid connector name and your panel isn't a VGA output
jkhsjdhjs has quit [Quit: Error: Leaving not permitted]
<LordKalma> mripard, it was copied from the vendor's boot.cmd. will do that :)
<Mis012[m]> where is your dts
<LordKalma> we discovered the vendor literally has 1 programmer who is doing everything from STM32 firmware to the Qt app
kts has joined #dri-devel
<LordKalma> it's in the builtdoot, let me link it to you
<LordKalma> the people from #linux-sunxi helped me a **lot** with the DTS
<LordKalma> and then I made some small fixes
jkhsjdhjs has joined #dri-devel
<mripard> Mis012: it looks like the DRM driver loads fine though, so the DTS is probably fine
<LordKalma> I disassembled the dtb and compared it with vendor's
<LordKalma> looks the same
<LordKalma> in fact, I fixed until it looked the same
<mripard> LordKalma: it's not a great argument :)
<mripard> most vendor DTS are broken beyond repair
<LordKalma> hahaha fair enough
<Mis012[m]> ↑
<LordKalma> but it does look mostly "stock"
<Mis012[m]> that's not a good thing...
<Mis012[m]> if you mean your dts looks like the vendor's dts
<LordKalma> I mean the DTS from the vendor is pretty much an olimex a33 + the panel
<LordKalma> the R16 and the A33 are the same CPU basically
<LordKalma> (basically and literally)
eyearesee has quit [Server closed connection]
camus has quit [Remote host closed the connection]
eyearesee has joined #dri-devel
camus has joined #dri-devel
robertfoss[m] has quit [Server closed connection]
robertfoss[m] has joined #dri-devel
<LordKalma> mripard, I'll follow up on your suggestion. Build does take a while, 'll keep in touch
<mripard> those should just require a environment variable change in u-boot, not a new build
<Mis012[m]> uhm hm...
<Mis012[m]> should probably just use tinyDRM and PRIME?
<Mis012[m]> don't think the SoC has some hw pipe between the framebuffer and the SPI controller
FireBurn has quit [Quit: Konversation terminated!]
<LordKalma> yeah, it does seem simple stuff
<LordKalma> maybe even patching simple_panel would do, not sure
<LordKalma> if you wanna look at some photos, this user did take some
rgallaispou has joined #dri-devel
<LordKalma> this is the SoC and the panel connects there in the centre
<LordKalma> (and I did manage to get the datasheet for the panel from the manufacturer)
zehortigoza has joined #dri-devel
<mripard> Mis012: those kind of constructs are usually for panels controlled through SPI, but getting their pixels through a proper display interface
<LordKalma> that is the case here
<LordKalma> DPI+SPI
<LordKalma> `drm_panel_init(&ctx->panel, dev, &jlt4013afuncs, DRM_MODE_CONNECTOR_DPI);` :)
<Mis012[m]> hm, right
<Mis012[m]> I've seen similar stuff with purely spi panels before on downstream...
<Mis012[m]> is there shader cache support on adreno?
frieder has quit [Ping timeout: 480 seconds]
<emersion> MrCooper: hm i thought IOCTLs codes couldn't overlap?
<emersion> ie, each IOCTL has its own namespace?
<emersion> the dma-buf IOCTL base is not even listed here
<mripard> seems to be working properly
<mripard> do you see anything on the display?
<LordKalma> only the backlight is on
<LordKalma> otherwise all black
<mripard> there's a couple of possible causes then: a reset or enable GPIO that isn't in its proper state, the timings that are off
<LordKalma> "# cat /dev/urandom > /dev/fb0
<LordKalma> cat: write error: No space left on device"
<LordKalma> but the screen is still black
<Mis012[m]> kmscube*
frieder has joined #dri-devel
<mripard> but it all depends on your design, so I'm not sure we can do a lot to help you at that point
<LordKalma> haha if only I designed this :)
<LordKalma> the vendor seems to be using kernel 5.8
<LordKalma> did anything change in the meanwhile?
<LordKalma> significant for this, I mean
<LordKalma> I'll re-check the GPIOs and look again at the clock values and etc
rgallaispou has quit [Read error: Connection reset by peer]
yuq825 has joined #dri-devel
kts has quit [Quit: Leaving]
<DavidHeidelberg[m]> eric_engestrom: I have MR ready, Acks counts, because I guess it'll be breaking often; https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20037
<DavidHeidelberg[m]> x86 -> x86_64; i386 -> x86_32 (because it's no longer i386); arm to arm64 (because it's a aarch64 runner, not armv7)
frieder has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
yuq825 has quit []
jkrzyszt has joined #dri-devel
gawin has joined #dri-devel
rasterman has quit [Read error: Connection reset by peer]
<gawin> DavidHeidelberg[m]: is it already possible to use 32bit wine app with 64 mesa?
<DavidHeidelberg[m]> gawin: I'm not the right person to ask, but I suppose not, since the app uses 32-bit libs, so Mesa has to be cross-compiled
frieder has joined #dri-devel
jfalempe_ has joined #dri-devel
jfalempe has quit [Remote host closed the connection]
rasterman has joined #dri-devel
<eric_engestrom> gawin: DavidHeidelberg[m] is right, you need to have the libs of the same bitness
<eric_engestrom> DavidHeidelberg[m]: looking now
<DavidHeidelberg[m]> it'll be probably a bit controversial :D
<MrCooper> I thought this was no longer the case with current Wine 7.0.y, due to the PE-ification / WoW64 work
<MrCooper> or at least close to no longer being the case
<gawin> oh yes, I was thinking about this
<gawin> maybe I'm gonna avoid recompiling mesa on j1800
<eric_engestrom> ah, I wasn't aware of that; I stand corrected
<gawin> hm, I see that people are mentioning penalty, so multilib isn't probably going anywhere
<DavidHeidelberg[m]> MrCooper: what I seen it's not default yet. At least 7.0 packages requires debian sub-arch i386
<DavidHeidelberg[m]> there is ongoing work, but that's all
<MrCooper> Debian packaging is pretty far behind upstream
<MrCooper> even wine-development packages are currently 7.11, released upstream half a year ago
<MrCooper> according to the Phoronix peanut gallery, the PE-ification is complete with current upstream releases, but I'm not sure if that means 32-bit libs are no longer needed yet
aravind has quit [Ping timeout: 480 seconds]
<Mis012[m]> why not instead develop something for mixing native linux libraries for different arches
<Mis012[m]> ideally with qemu-user support as well
ahajda has joined #dri-devel
macromorgan has quit [Read error: Connection reset by peer]
Company has joined #dri-devel
rgallaispou has joined #dri-devel
macromorgan has joined #dri-devel
fab has quit [Quit: fab]
EricCurtin[m] has quit [Server closed connection]
EricCurtin[m] has joined #dri-devel
macromorgan has quit [Ping timeout: 480 seconds]
Haaninjo has joined #dri-devel
macromorgan has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
macromorgan has quit [Remote host closed the connection]
macromorgan has joined #dri-devel
macromorgan is now known as Guest243
macromorgan has joined #dri-devel
macromorgan is now known as Guest244
macromorgan has joined #dri-devel
Guest243 has quit [Ping timeout: 480 seconds]
Guest244 has quit [Ping timeout: 480 seconds]
bgs has joined #dri-devel
fab has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
Leopold_ has quit [Remote host closed the connection]
tzimmermann has quit [Quit: Leaving]
Leopold_ has joined #dri-devel
Duke`` has joined #dri-devel
frieder has quit [Remote host closed the connection]
rgallaispou has quit []
rgallaispou has joined #dri-devel
<dj-death> there are a few shader-db MRs adding shaders
<dj-death> nobody is giving rb/ack on them
<dj-death> should we just merge them?
<dj-death> it's only opensource stuff afaict
rgallaispou has quit []
yshui` has quit [Server closed connection]
yshui` has joined #dri-devel
rgallaispou has joined #dri-devel
kts has joined #dri-devel
tursulin has quit [Ping timeout: 480 seconds]
rgallaispou has quit []
<MayeulC> Venemo: should I submit a MR with a rebased (and cleaned-up commit message) patch to re-enable sparse support on FIJI? That would be this one: https://gitlab.freedesktop.org/MayeulC/mesa/-/commit/e8a154dadbc10845f09b4444379a9cfdbd663895
<MayeulC> (RE https://gitlab.freedesktop.org/mesa/mesa/-/issues/4136), unless you'd like to test it first.
<eric_engestrom> dj-death: yeah, any MR that's just adding opensource shaders can be merged straight away IMO
<eric_engestrom> we could really use a CI on the shaderdb repo to check whether all drivers can compile everything so far, so that when there's an MR adding shaders we can tell whether this breaks on any drivers
Eighth_Doctor has quit [Server closed connection]
Eighth_Doctor has joined #dri-devel
Anson[m] has quit [Server closed connection]
Anson[m] has joined #dri-devel
AlexisHernndezGuzmn[m] has quit [Server closed connection]
<eric_engestrom> the drivers that have enough drm-shim to do this should be easy to wire up (putting that on my to-do list), but iirc radv for instance can't do that
AlexisHernndezGuzmn[m] has joined #dri-devel
gallo[m] has quit [Server closed connection]
gallo[m] has joined #dri-devel
ids1024[m] has quit [Server closed connection]
ids1024[m] has joined #dri-devel
kunal10710[m] has quit [Server closed connection]
kunal10710[m] has joined #dri-devel
kunal_10185[m] has quit [Server closed connection]
kunal_10185[m] has joined #dri-devel
Mershl[m] has quit [Server closed connection]
Mershl[m] has joined #dri-devel
nyorain[m] has quit [Server closed connection]
nyorain[m] has joined #dri-devel
onox[m] has quit [Server closed connection]
onox[m] has joined #dri-devel
jhli has joined #dri-devel
Guest216 has quit [Remote host closed the connection]
<apinheiro> > nobody is giving rb/ack on them
<apinheiro> dj-death, what eric said
<apinheiro> but let me take a look to at least give an ack (we were on a similar situation when we submitted changes of shader-db for v3dv)
mhenning has joined #dri-devel
ybogdano has joined #dri-devel
<apinheiro> > we could really use a CI on the shaderdb repo to check whether all drivers can compile everything so far, so that when there's an MR adding shaders we can tell whether this breaks on any drivers
<apinheiro> breaks what? if the new shaders added breaks?
<apinheiro> I mean that it can be really common adding new shaders that doesn't compile on some specific driver
<apinheiro> but I don't see how that could break existing shaders
<apinheiro> so not fully sure of what do you mean
<gawin> it may be worth to divide shaders by APIs. (also some games are offering multiple code paths)
ybogdano has quit [Read error: Connection reset by peer]
<tomeu> karolherbst: would you happen to have any ideas on this problem I'm finding when trying to use rusticl on CI on arm64: https://gitlab.freedesktop.org/tomeu/mesa/-/jobs/32593540#L3253
<tomeu> looks like in that job, the bindings for vargs are being generated as passing the struct itself by value
ybogdano has joined #dri-devel
<tomeu> and fails due to FFI
<tomeu> in the existing x86 jobs and also locally, with bindgen 0.59.2 as well, those args are generated as references
<tomeu> args: *mut __va_list_tag,
<karolherbst> strange
<karolherbst> because I did build it on arm64 already
<tomeu> I'm at a loss on why the same version of bindgen would show this difference in behavior
<tomeu> hmm, can you check what version of bindgen you used?
<tomeu> maybe there was that divergence in behavior between arches at some point
<karolherbst> could also be a llvm-13 thing
<tomeu> oh, interesting
kts_ has joined #dri-devel
<karolherbst> bindgen 0.59.2
<karolherbst> rustc 1.64.0 (Fedora 1.64.0-1.fc36)
kts_ has quit [Remote host closed the connection]
<karolherbst> llvm-14.0.5
<karolherbst> let me check if main still builds though
<Venemo> MayeulC: sorry I'm still tied down with the previous issue i've been investigating, haven't had time to look at Fiji yet
<MayeulC> Venemo: Okay, I was wondering if submitting a MR before the next release was a good idea, but I prefer to have an extra ACK
kts has quit [Ping timeout: 480 seconds]
<Venemo> MayeulC: you can submit a MR any time. but I would prefer not to merge it yet until I test it too. I am sorry my thing is taking so long.
<eric_engestrom> apinheiro: I was thinking about the fact we run shaderdb on a bunch of drivers in $mesa/.gitlab-ci/run-shader-db.sh; if we can see when we add shaders that they break some driver, it's better IMO rather than waiting for next time we bump something in mesa that triggers a rebuild and fetches the latest shader-db
bmodem1 has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
bmodem has quit [Ping timeout: 480 seconds]
bmodem1 has quit [Ping timeout: 480 seconds]
karolherbst_ has joined #dri-devel
<anholt> gallo: are you planning on working on the skqp-runner MR soon?
karolherbst has quit [Ping timeout: 480 seconds]
* jenatali wonders if I could get shader-db working on d3d12...
<jenatali> I could probably build a wddm shim
Akari has joined #dri-devel
srslypascal is now known as Guest262
srslypascal has joined #dri-devel
Guest262 has quit [Ping timeout: 480 seconds]
<karolherbst_> tomeu: soo.. I see the same thing, but it's a warning for me
karolherbst_ is now known as karolherbst
<karolherbst> tomeu: maybe we want to figure out how to disable generating bindings for them or something... mhh
<karolherbst> but yeah.. I don't see that on x86
<tomeu> karolherbst: ok, tomorrow will keep looking, I didn't see this when I built mesa for rusticl+etnaviv on the device
<tomeu> the llvm version is a good hint on what look at
<karolherbst> I doubt it, because it looks like a warning vs error thing here
<karolherbst> tomeu: the "-D warning" is probably the reason it fails to compile
lynxeye has quit [Quit: Leaving.]
rasterman has quit [Quit: Gettin' stinky!]
<apinheiro> eric_engestrom, ah ok, didn't know that some drivers were already using shader-db on the mesa CI
<apinheiro> I understand now what you mean
<apinheiro> thanks
gawin has quit [Ping timeout: 480 seconds]
zackr has joined #dri-devel
<zackr> mlankhorst, mripard: after rc7 (as in right now) should i still use drm-misc-fixes for fixes (i'm ok with the fix hitting the next release, instead of trying to force one more rc) or should i use something else? i don't want to cause havoc for a non-critical fix
Leopold_ has quit []
heat_ has joined #dri-devel
heat has quit [Read error: Connection reset by peer]
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
lygstate has joined #dri-devel
Leopold_ has joined #dri-devel
Leopold_ has quit [Remote host closed the connection]
<lygstate> :mareko Please take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20042 first before working on https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20027 to avoid redundant work
junaid has joined #dri-devel
heat_ has quit [Remote host closed the connection]
heat_ has joined #dri-devel
<Lynne> airlied: good news, your vulkan decoding code still works!
<Lynne> for I-frames at least, so far
rmckeever has joined #dri-devel
lygstate has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
elongbug has quit [Remote host closed the connection]
elongbug has joined #dri-devel
<Lynne> P-frames are busted though
<airlied> Lynne: yeah I was trying with the prelim CTS and it was failing
<airlied> Lynne: do you have enough player so I can visually see the fail
<airlied> I'm not 100% today, but maybe later in the week I'll be up for it
rsalvaterra has quit []
rsalvaterra has joined #dri-devel
<Lynne> passes validation layers (false report on layout, just submitted a bug to their repo), let me try it on nvidia
gouchi has joined #dri-devel
<Lynne> hmm, it fails at vkGetPhysicalDeviceVideoFormatPropertiesKHR with VK_ERROR_IMAGE_USAGE_NOT_SUPPORTED_KHR
apinheiro has quit [Ping timeout: 480 seconds]
<airlied> Lynne: do you handle the separate DPB/DST stuff?
<airlied> I need to switch on CORRECT_DPB_HANDLING in the radv driver
<airlied> I was going to do it once I got CTS to pass
<Lynne> no, not yet, just resurrected the code, your hack/workaround is still there
<Lynne> aww, permanent VK_ERR_DEVICE_LOST
yoslin_ has joined #dri-devel
junaid has quit [Ping timeout: 480 seconds]
yoslin has quit [Ping timeout: 480 seconds]
<Lynne> airlied: oh, btw, here's your patches, rebased - https://0x0.st/o0m2.tar
<Lynne> that's what I'm using on mesa, last commit needs to be merged into the rest, but /effort
<Ristovski> Is the "anti-aliasing does a slow full clear" with amdgpu still the case? I keep seeing this mentioned in random places but I have been unable to determine what the cause was and whether it has since been addressed/fixed
<Ristovski> example: "MSAA does a very slow full color clear on every frame for AMD cards in OpenGL games"
apinheiro has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
dcz_ has quit [Ping timeout: 480 seconds]
<Ristovski> also hmm, the gallium post processing filters dont seem to do anything
<Ristovski> oh hm, they do nvm
<airlied> Lynne: rebased the branch
rib_____ has quit []
rib has joined #dri-devel
mvlad has quit [Remote host closed the connection]
lemonzest has quit [Quit: WeeChat 3.6]
Haaninjo has quit [Quit: Ex-Chat]
gouchi has quit [Remote host closed the connection]
alyssa has joined #dri-devel
<alyssa> occlusion queries are mean to tilers
* alyssa is pretty sure oq's are broken in panfrots
<alyssa> panfrost
TMM has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
TMM has joined #dri-devel
<airlied> Lynne: pushed one fix I had in that format props area
<Lynne> thanks, it's not more broken at least
<Lynne> still figuring out why it doesn't work on nvidia, it's like it's rejecting the profile but returning the image usage flags are wrong
fab has quit [Quit: fab]
<Lynne> oh, the specs say I have to put dpb+dst bit in the usage if separate_reference bit is set in flags
* airlied forgets the rules there
<airlied> there is DPB/DST vs DPB and DST and there is also something about separate DPB being an array texture
<airlied> Lynne: okay so that flag should only control the arrayness I thought
<airlied> you are meant to just try DPB/DST and fallback to separate if the format supported query fails
<airlied> sorry overloaded separate there
<airlied> fallback to distinct dpb/dst images
ahajda has quit [Ping timeout: 480 seconds]
<Lynne> second paragraph after the bullet points
<Lynne> it reads more like a 90's game manual copy protection check than something with a reason
<airlied> yeah it's one of those everyone's hw does it different, and there's no nice answer
<Lynne> weird, now it fails at trying to allocate memory with a simple DEVICE_LOCAL bit set
<alyssa> Lynne: lol
<Lynne> weird stuff, allocated memory now it's outputting something
<Lynne> no complaints from the validation layer at all, but only outputs green or green+artifacts
<Lynne> I don't think I allocated memory in the correct heap
apinheiro has quit [Quit: Leaving]
<Lynne> for some reason the (mem_reqs.memoryTypeBits & (1 << i)) check fails?
<Lynne> which means that no type supports the required memory?
<airlied> that seems a bit wrong
<airlied> GetImageMemoryRequirements should return some heap
<Lynne> so only one type matches the requirements GetVideoSessionMemoryRequirementsKHR returns, but it's not DEVICE_LOCAL
<Lynne> it's HOST_VISIBLE+COHERENT+CACHED
<airlied> that seems like a strange one to end up with
<airlied> did oyu specify linear somwhere?
<airlied> instead of optimal tiling
<Lynne> no, all optimal
alyssa has quit [Quit: leaving]
<Lynne> but if I request host_visible for all, the next session memory req is only available for device_local
<Lynne> am I supposed to trial and error the properties?
* airlied isn't sure what session reqs have to do with image alloc
<Lynne> me neither, but I think it makes sense to ignore memory properties for memory you never access
<airlied> no you have to pass them back in
<Lynne> for the session memory? where?
<Lynne> VkBindVideoSessionMemoryInfoKHR just takes an index
YuGiOhJCJ has joined #dri-devel
<airlied> those indexes are just the binding, you have to allocate the device memory from the correct heap
<Lynne> yeah, and you figure out the correct heap by the type bits
<airlied> so same as for images
<Lynne> usually client memory alloc functions ask for the properties too, which is what I'm talking about ignoring
<Lynne> for the session memory only
<Lynne> actual images are obviously something else
<airlied> ah yes in that case that is internal
* airlied gets your branch to build
aravind has joined #dri-devel
<airlied> Lynne: got an example ffmpeg line I can run, I lost any notes I had :-P
<Lynne> just updated branch again with the nvidia changes
<Lynne> as for a command line
<Lynne> ./ffmpeg_g -init_hw_device "vulkan=vk:0,debug=1" -hwaccel vulkan -hwaccel_output_format vulkan -i TEST_BDMV.mkv -loglevel debug -filter_hw_device vk -vf hwdownload,format=nv12 -vframes 1 -c:v rawvideo -y OUT.nut
ahajda has joined #dri-devel
<Lynne> replace TEST_BDMV.mkv with whatever file you have on hand, add -an somewhere towards the end if it's got audio you don't want, output is uncompressed .nut which you can play with mpv, or you can use .y4m for something more standard
<Lynne> ignore any complaints about VK_IMAGE_LAYOUT_VIDEO_DECODE_DPB_KHR, it's the validation layer bug I mentioned, it thinks all frames must be in DST, including refs