ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
columbarius has joined #dri-devel
co1umbarius has quit [Ping timeout: 480 seconds]
Kayden has quit [Quit: home]
Danct12 has joined #dri-devel
elongbug has quit [Read error: Connection reset by peer]
RAOF has quit [Remote host closed the connection]
<anholt_> zmike: so, I think I've got some hope for dropping the deqp-runner build in the rootfs -- I can cargo deb them during CI pipelines, and then when I tag a release I do a release build pipeline that makes them permanent artifacts..
RAOF has joined #dri-devel
<anholt_> if I figure out this workflow, it might be interesting to do for deqp.
* airlied throws llvmpipe functions at marge
yuq825 has joined #dri-devel
Kayden has joined #dri-devel
kzd has joined #dri-devel
flynnjiang has quit [Ping timeout: 480 seconds]
flynnjiang has joined #dri-devel
<karolherbst> airlied: I suspect doing the same with radeonsi will be way more interesting
<karolherbst> also in terms of performance
lemonzest has quit [Quit: WeeChat 4.0.4]
lemonzest has joined #dri-devel
<karolherbst> airlied: nice.. the other benchmarks are running with your brnach :3
<karolherbst> not sure it renders correctly :D
<karolherbst> and now we need a proper inliner with heurestics and uhhh...
<airlied> yeah a proper inliner is definitely a thing we would want, but it requires a bit more focus
<airlied> I started on radeonsi, but it didn't work in my first effort
<karolherbst> airlied: huh.. it seems like you can't run luxmark with llvmpipe on aarch64
<karolherbst> something something only floats with fpext
<airlied> I'm surprised luxmark works at all on aarch64
<karolherbst> and apparently it gets int inputs
<karolherbst> it does with asahi :D
<airlied> karolherbst: if it crashes throw me a backtrace
<airlied> do you get 128 or 256 wide vectors?
<karolherbst> the llvm is invalid
<airlied> yeah so that's likely some path that is falling off the x86 paths that just needs fixing u
<airlied> ah looks like 128-bit vectors, I wonder can I reproduce on x86
<kode54> Any word on GuC logging for errors in xe.ko?
<kode54> Would be nice to log these reproducible crashes I have
<kode54> So far they mostly only crash the app
<airlied> karolherbst: looks like missing f16c could caus that
<karolherbst> heh..
<karolherbst> sounds plausible at least
<airlied> though could be a backend bug, there does appear to be a bitcast
<airlied> karolherbst: can you get a GALLIVM_DEBUG=ir run?
<airlied> would need to see the nir
<airlied> does apple have 8-wide vector instructions?
<karolherbst> no idea
yyds has joined #dri-devel
<karolherbst> Features are "fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 frint i8mm bf16 bti ecv" btw
<karolherbst> it seems to be armv8.5-a
<HdkR> 8-wide with what size elements?
<HdkR> 32-bit? You won't get that
<HdkR> Apple only supports 128-bit wide
Daanct12 has joined #dri-devel
<karolherbst> airlied: btw, on an updated luxmark-v3.1 llvmpipe renders correctly even with functions
<airlied> karolherbst: yeah I built illwieckz version here to make sure
<airlied> HdkR: any f16c equiv on aarch64?
<karolherbst> and it's not faster on my system :D
<karolherbst> but kinda equally fast
<airlied> karolherbst: okay 16-bit is busted if you don't have f16c, not sure how best to fix it yet
<karolherbst> mhh
<HdkR> airlied: Yea, Arm64 supports the conversions natively
<airlied> HdkR: on all arm64s? so I should just set the flag always there?
<HdkR> fcvt is the instruction that does half to 32-bit/64-bit
<HdkR> Scalar is always available, vector isn't always available
<HdkR> `fphp` in the featurelist that Karol posted is the vector support
<airlied> karolherbst: https://paste.centos.org/view/raw/897c85de might fix it
<airlied> I can probably let llvm take care of that part of it
<karolherbst> airlied: works
<karolherbst> and llvmpipe is like... 60% faster than on my i7-10850H
<karolherbst> and that's a M2 air...
ANDROID_IOS_user has joined #dri-devel
<karolherbst> did I say 60%? I meant of course 90%
<karolherbst> m2 (passive cooled): 666, i7-10850H (jet fans): 359
<HdkR> Delta Airlines called, they want their plane engines back
<karolherbst> _sadly_ llvmpipe isn't fast enough for the other scenes and it fails at image validation :D
<karolherbst> but anyway...
<airlied> karolherbst: I'm honestly not sure it's a speed thing, but it's hard to tell
<karolherbst> it's a speed thing
<karolherbst> the more samples you get, the closer you get the to reference image
<airlied> yeah on the ohter scenes I only ever get black though
<karolherbst> heh
<karolherbst> I'm not
<karolherbst> they render fine with your function MR
<karolherbst> well
<karolherbst> "fine"
<karolherbst> the hotel one doesn't validate with a 75% mismatch
<karolherbst> Neumann looks fine tho...
<ANDROID_IOS_user> mmmmmm
<airlied> oh cool
<karolherbst> heh
<airlied> so maybe tuning the inliner might get them over the line
<karolherbst> 0.61% difference :D
<karolherbst> but that's not that hard when 60% of the image is a white background
<karolherbst> mhh doubtful
<karolherbst> the CPU is just not fast enough
<karolherbst> the fun part is, they have a C++ version and it's just ultra fast...
<karolherbst> but maybe embree is also just that optimized and their CL raytracer isn't
<karolherbst> the C++ run of the hotel scene shows 35% different pixels :D
<karolherbst> and it's like 10x as fast
idr has quit [Ping timeout: 480 seconds]
<HdkR> They validate the image after time has passed rather than number of samples gathered?
crabbedhaloablut has joined #dri-devel
ANDROID_IOS_user_ has joined #dri-devel
ANDROID_IOS_user has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
<airlied> mripard: just fyi I'll leave fixes pull until next week as it needs an rc1 backmerge
ANDROID_IOS_user__ has joined #dri-devel
kzd has quit [Quit: kzd]
simon-perretta-img_ has joined #dri-devel
ANDROID_IOS_user_ has quit [Ping timeout: 480 seconds]
simon-perretta-img has quit [Ping timeout: 480 seconds]
Daaanct12 has joined #dri-devel
Daanct12 has quit [Ping timeout: 480 seconds]
heat has quit [Ping timeout: 480 seconds]
alkisg_irc has joined #dri-devel
Duke`` has joined #dri-devel
alkisg_irc is now known as alkisg
alkisg has left #dri-devel [#dri-devel]
bmodem has joined #dri-devel
<dcbaker> mareko: ack
jewins has quit [Ping timeout: 480 seconds]
ANDROID_IOS_user__ has quit []
ANDROID_IOS_user__ has joined #dri-devel
fab has joined #dri-devel
tristan has joined #dri-devel
tristan is now known as Guest2204
sima has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
flynnjiang has quit [Read error: Connection reset by peer]
flynnjiang has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<kode54> HdkR: yes
<kode54> you can fail validation due to not enough samples being gathered in the time limit
Guest268 is now known as go4godvin
mszyprow has joined #dri-devel
An0num0us has joined #dri-devel
ANDROID_IOS_user__ has quit [Remote host closed the connection]
<mripard> airlied: ack, sorry, I didn't notice
ANDROID_IOS_user__ has joined #dri-devel
tzimmermann has joined #dri-devel
tzimmermann has quit []
tzimmermann has joined #dri-devel
ANDROID_IOS_user__ has quit [Remote host closed the connection]
sghuge has quit [Remote host closed the connection]
sghuge has joined #dri-devel
<airlied> okay 2 jobs failed to marge not sure what farms died
<kode54> dj-death: I retested the Borderlands GOTY Enhanced issue
<kode54> it reduces significantly, but is still bad, if I use my compositor's fullscreen hotkey to toggle it to a 1080p window
<kode54> it was just as bad on GNOME, so I don't know what's up
<kode54> I can try setting my display modes to 1080p
Guest2204 has quit [Ping timeout: 480 seconds]
<kode54> it reduces even further if I set my xwayland scaling to 100%, then display it in a tiny window in the middle of the screen
<kode54> it's still rendering at 1080p, but it's blitting to a tiny window
Daanct12 has joined #dri-devel
Daaanct12 has quit [Ping timeout: 480 seconds]
donaldrobson has joined #dri-devel
lynxeye has joined #dri-devel
<kode54> okay
<kode54> yeah
<kode54> that's bork
<kode54> why should the upscaling blitter be so slow
apinheiro has joined #dri-devel
tristan has joined #dri-devel
tristan is now known as Guest2213
ANDROID_IOS_user has joined #dri-devel
vliaskov has joined #dri-devel
flynnjiang has quit [Quit: Leaving]
rasterman has joined #dri-devel
JTL has quit []
Guest2213 has quit [Ping timeout: 480 seconds]
JTL has joined #dri-devel
JTL has quit []
JTL has joined #dri-devel
JTL has quit []
tristan has joined #dri-devel
tristan is now known as Guest2217
Ahuj has joined #dri-devel
Guest2217 has quit [Ping timeout: 480 seconds]
elongbug has joined #dri-devel
swalker_ has joined #dri-devel
swalker_ is now known as Guest2219
mszyprow has quit [Read error: Connection reset by peer]
Guest2219 has quit [Ping timeout: 480 seconds]
<jfalempe> tzimmermann, do you have an opinion regarding https://patchwork.freedesktop.org/patch/554504/?series=122897&rev=2 ?
<tzimmermann> well, i have mixed feelings
ANDROID_IOS_user has quit [Ping timeout: 480 seconds]
<jfalempe> you think it's too restrictive or too permissive ? I tried to get the different point of view, and have a clear compromise.
<javierm> jfalempe: I think what you document is a good compromise
<javierm> also, I expect that the optimization of discarding the alpha component when not used/supported is something that most display controllers do by HW
<tzimmermann> it opens the door for all kinds to conversions and 'performance fixes'
<tzimmermann> javierm, you can leave this optimization to userspace
<tzimmermann> it's better done there
<javierm> tzimmermann: yeah, but then you can't have user-space that's not HW agnostic
<tzimmermann> javierm, in which way?
<javierm> tzimmermann: in that you need to configure it to use RGB888 instead of ARGB8888
<javierm> for the specific case that jfalempe is trying to solve in the driver
<jfalempe> tzimmermann, I explained why it's not always the case here: https://lists.freedesktop.org/archives/dri-devel/2023-August/419620.html
<tzimmermann> it *is* HW agnostic. it just needs to support another color format.
<tzimmermann> i'd argue that it's not even clear wether that is an optimization at all. by dripping that X from XRGB, you're reducing bus bandwidth at the expense of processing each transfered pixel individually.
<tzimmermann> so better leave this to userspace, which can generate the correct format in the first place
<tzimmermann> 'dropping'
<jfalempe> when I asked some mesa devs they told me that supporting RGB888 in userspace is very complex. llvm and opengl doesn't like this.
<jfalempe> also doing the convertion in userspace would be slower, because you can't do it on the fly during the transfer.
<tzimmermann> jfalempe, exactly. but that doesn't mean you should use it in the driver
<tzimmermann> it's even worse in the kernel. no sse-like instructions. and for the conversion output, you have to move byte-wise over the ouput array.
<jfalempe> I don't see that at being worse than doing memcpy().
<jfalempe> memcpy() is so slow, the CPU can do thousands of instruction when copying 4 bytes to the mgag200 VRAM.
<tzimmermann> you mean memcpy_toio() ?
<jfalempe> yes
<tzimmermann> but that's because of your fast cpu. the tradeoff could be different on other systems. and if so, you could then drop the X component in userspace and send the RGB888 date to the kernel
<tzimmermann> 'data'
<tzimmermann> i see no upside for running this code in the kernel
<jfalempe> Yes it could be, if you use a very slow CPU with a Matrox, but such thing doesn't exist in practice.
<javierm> tzimmermann: just for compatiblity with XRGB8888
<tzimmermann> you've not seen my g200 test system :p
<javierm> tzimmermann: but you could also say the same about copying an (unused) alpha component, what could be the upside ?
<javierm> I guess avoiding the computation of dropping it?
<tzimmermann> javierm, simplicity
<tzimmermann> yes
<tzimmermann> leave that to userspace
<tzimmermann> and only in-kernel user, fbcon, can handle rgb888
<tzimmermann> i'd even argue to use rgb565 for matrox
tristan has joined #dri-devel
<jfalempe> rgb565 is different, because in this case you lose color information
<jfalempe> and it's really noticeable
tristan is now known as Guest2221
mauld has quit [Ping timeout: 480 seconds]
<jfalempe> so basically the main argument for not doing software color conversion in the kernel is performance. But for you simplicity does also count ? even if that means slower performance with current userspace and less features (lower resolution) ?
mauld has joined #dri-devel
<MrCooper> if performance is an argument, XRGB8888 is faster with jfalempe's patch than without "conversion"
novaisc has quit [Remote host closed the connection]
tales-aparecida has quit [Remote host closed the connection]
mairacanal has quit [Remote host closed the connection]
grillo_0 has quit [Remote host closed the connection]
gcarlos has quit [Remote host closed the connection]
tonyk has quit [Remote host closed the connection]
simon-perretta-img has joined #dri-devel
<Kayden> is it possible to test the d3d12 driver's nir_to_dxil.c code on a linux system?
<Kayden> looks like I broke it while trying to fix freedreno regressions
<Kayden> I suspect the thing I asked for isn't representable in DXIL but I'm not familiar enough to know off-hand why it's breaking
simon-perretta-img_ has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.0.4]
An0num0us has quit [Ping timeout: 480 seconds]
Guest2221 has quit [Ping timeout: 480 seconds]
bmodem has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
glisse has quit [Remote host closed the connection]
glisse has joined #dri-devel
mareko has quit [Remote host closed the connection]
mareko has joined #dri-devel
<pq> javierm, I would expect display controllers to do bulk memory read bursts from whatever memory they are scanning out from, meaning they also read the X channel and ignore it. So no savings in memory bandwidth. Dropping every fourth byte is kinda difficult if you operate on 4-byte or wider words. Or display cachelines.
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
<karolherbst> does virgl operate on DRM renderer nodes?
<karolherbst> or rather, how are virtualized GPUs exposed to the OS for solutions we care about inside mesa
<karolherbst> We kinda need to figure out what CL device matches a GL one and I was wondering if using the renderer node is something we could do here
dri-logg1r has joined #dri-devel
<daniels> Kayden: yeah, if you're building with spirv-to-dxil=true, then you'll build a spirv2dxil executable which does what it says on the box
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
dri-logger has quit [Ping timeout: 480 seconds]
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
<Kayden> daniels: thanks!
<Kayden> found that, ran my piglit test through glslc to get spirv then trying to run it through spirv2dxil
<Kayden> doesn't handle my silly glsl features so I'm trying to hack it to do that, heh
<Kayden> hm, with a lot of hacking, it produced dxil
yyds has quit [Remote host closed the connection]
apinheiro has quit [Quit: Leaving]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
<javierm> pq: I see
Danct12 has quit [Remote host closed the connection]
steve--w has joined #dri-devel
ickle_ has quit [Remote host closed the connection]
Company has joined #dri-devel
<steve--w> hey guys, noob to mesa. trying to build windows, using msys2.
<steve--w> I get :
<steve--w> meson.build:876:2: ERROR: Problem encountered: Python (3.x) mako module >= 0.8.0 required to build mesa.
<steve--w> installed mako using pip
greenjustin_ has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
ickle has joined #dri-devel
bmodem has quit [Excess Flood]
<steve--w> seems don't use msys2, use windows command prompt & native meson/ninja, etc. is the way.
bmodem has joined #dri-devel
kts has joined #dri-devel
mauld has quit [Ping timeout: 480 seconds]
ap51 has joined #dri-devel
mauld has joined #dri-devel
<steve--w> next up :
<steve--w> FAILED: src/compiler/glsl/glsl_lexer.cpp
<steve--w> "C:\Program Files (x86)\GnuWin32\bin\flex.EXE" "-DYY_USE_CONST=" "-D__STDC_VERSION__=199901" "-o" "src/compiler/glsl/glsl_lexer.cpp" "Z:/dev_public/FFmpeg_dev/mesa/src/compiler/glsl/glsl_lexer.ll"
<steve--w> C:\Program Files (x86)\GnuWin32\bin\flex.EXE: unknown flag 'D'. For usage, try
<steve--w> C:\Program Files (x86)\GnuWin32\bin\flex.EXE --help
<zmike> anholt_: oh that'd be great
swizzlefowl has quit [Quit: Connection closed for inactivity]
An0num0us has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
kts_ has joined #dri-devel
alyssa has joined #dri-devel
kts_ has quit []
kts has quit [Ping timeout: 480 seconds]
yuq825 has left #dri-devel [#dri-devel]
bmodem has quit [Ping timeout: 480 seconds]
bmodem has joined #dri-devel
bmodem has quit [Excess Flood]
bmodem has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
novaisc has joined #dri-devel
gcarlos has joined #dri-devel
agd5f_ has quit []
agd5f has joined #dri-devel
<agd5f> sima, if you get a chance. radeonfb regression https://gitlab.freedesktop.org/drm/amd/-/issues/2826
Haaninjo has joined #dri-devel
Danct12 has joined #dri-devel
Danct12 has quit []
vjaquez has quit [Quit: ¡hasta luego!]
fab has quit [Quit: fab]
vjaquez has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
mairacanal has joined #dri-devel
fxkamd has quit []
Ahuj has quit [Ping timeout: 480 seconds]
tonyk has joined #dri-devel
<karolherbst> ../src/compiler/nir/nir_serialize.c:1277:70: runtime error: left shift of 524280 by 13 places cannot be represented in type 'int'
<karolherbst> ../src/compiler/nir/nir_serialize.c:1274:70: runtime error: left shift of 524224 by 45 places cannot be represented in type 'long int'
<karolherbst> mhhhh
<karolherbst> but I guess that's practically fine
<karolherbst> or rather, it's doing what it shall do
Danct12 has joined #dri-devel
ap51 has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
kzd has joined #dri-devel
jdavies has joined #dri-devel
jdavies is now known as Guest2236
<zmike> mareko: need your ack on tc part of https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25121
<steve--w> this apparently : https://github.com/lexxmark/winflexbison/releases - compiled now :)
idr has joined #dri-devel
<steve--w> don't get vaon12_drv_video.dll
kzd has quit [Quit: kzd]
jdavies_ has joined #dri-devel
Guest2236 has quit [Ping timeout: 480 seconds]
fxkamd has joined #dri-devel
mripard has quit [Quit: mripard]
tales-aparecida has joined #dri-devel
kts has joined #dri-devel
<eric_engestrom> tnt: oct 25 will be the branchpoint I think
<tnt> eric_engestrom: thanks.
zf has joined #dri-devel
<idr> So... when I try to send mail to mesa-dev, it gets spam blocked. That seems broken.
DodoGTA has quit [Quit: DodoGTA]
<idr> Hrm... maybe I sent from the wrong address.
DodoGTA has joined #dri-devel
<idr> Yup. PEBKAC
junaid has joined #dri-devel
<cheako> Mesa 23.2.0~rc3-1, arc a770, Starfield seems no good? The #intel-gfx seems abandoned. I understand it could take some time, but I haven't found any recognition acknowledging it.
<karolherbst> cheako: tried filing a bug?
<tnt> Doesn't starfield also render bug out on windows though ?
<HdkR> No need to compare the Windows experience to the Linux experience. The driver stacks are completely different
<cheako> Yeah, I'm not one to stick myself in the middle of a group of ppl who act as individuals.
<karolherbst> ?
<karolherbst> I'm confused
<tnt> HdkR: I was more pointing to the game itself doing bad things :)
<HdkR> Well, Bethesda game, nothing new there :)
<karolherbst> cheako: isn't that for windows?
<cheako> Team A blames Team B and Team B says only Team A can fix it, they don't realize they are both at fault.
<karolherbst> ?
<karolherbst> who is blaming who
<cheako> Right, hence why I'm asking... it's fine if the linux platform is being ignored, just that I and others know it's being ignored.
<karolherbst> if you are running into a bug, I'm sure that people are willing to look into it once it's reported
<karolherbst> cheako: so you filed a bug and it got ignored?
<karolherbst> I honestly don't understand what you are trying to say here and how we can/what we can do to help...
<cheako> It usually doesn't go well when I file bugs.
<cheako> ppl get all defensive.
<karolherbst> I mean.. there is probably a reason to get defensive
<karolherbst> otherwise they wouldn't
<cheako> Yeas, I have autism.
<karolherbst> anyway, I doubt anybody here is doing anything on purpose, just that there is often way more work to do than people have time
<cheako> There are a bunch of things wrong with me, so I prefer chat to email.
<karolherbst> but I wouldn't say intel gpu on linux is abondoned while develoeprs are paid to work on it
<cheako> The chat channel, I posted yesterday and no reply.
<cheako> 14 members and all.
heat has quit [Remote host closed the connection]
<karolherbst> sounds like the wrong channel then
heat has joined #dri-devel
<karolherbst> and I've also didn't see any message of you in the mentioned channel
<karolherbst> maybe something messed up with your client or some other reason your message didn't get through?
<cheako> Libera.Chat is bad.
<karolherbst> anyway, if you try to write in #intel-gfx the IRC server should either respond on why you can't write there... or maybe it doesn't work with your client. Dunno, but in either case, I don't see any message from you there, so I'd say that simply nobody saw your message
An0num0us has joined #dri-devel
<cheako> TRhanks that helps a lot.
<karolherbst> np
<MrCooper> a chat channel isn't an issue tracker anyway
<cheako> I don't like issue trackers, look at the above conversation and ask if it just screams that needed to happen on such a platform?
<cheako> I don't mind marking down in stone the products of such conversations, but to just talk about something it's a poor choice.
<karolherbst> anyway, it seems we have currently one starfield related bug in our issue tracker: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9759
<karolherbst> but that's AMD related
benjaminl has joined #dri-devel
<MrCooper> just don't expect issues to get fixed if they're not reported in the place created for reporting issues
<karolherbst> cheako: did you try it yourself yet? Or do you want to know if it works at all before e.g. buying the game?
<cheako> Yes, I've exhausted the resources google suggested and moved on to asking about it.
<karolherbst> cheako: we have protondb to check how well windows games run on proton/steam: https://www.protondb.com/app/1716740
kzd has joined #dri-devel
<karolherbst> but it doesn't seem like anybody with an Intel GPU tried yet
<karolherbst> or rather.. didn't leave a report
donaldrobson has quit [Ping timeout: 480 seconds]
<karolherbst> cheako: Steam also has the option to refund games and I've done it multiple times with games not working through proton, in case that's an option for you
<karolherbst> but I think availabilty for this depends on the country?
<karolherbst> not sure
<karolherbst> ohh wait
<karolherbst> there is a report
<lumag> robclark, generic question regarding libdrm. Currently modetest lacks attention from libdrm maintainers. There are 13 MRs open against modetest. emersion wrote that he is not really interested in this tool. Do you know if there any way to reinstantiate tests/modetest maintenance within libdrm? I/we can volunteer reviewing and merging/declining these patches. I'm asking because otherwise my only option is to fork it using git filter-repo and maintain
<lumag> it as a separate tool (if that sounds more acceptable from drm maintainers POV).
<karolherbst> cheako: anyway.. seems like the best you can do for now is to wait and see until it gets fixed
<cheako> I noticed there are a few IDs for starfiled, be sure you've the correct one. I can't seem to tell what Id was used on my system.
<gildekel> lumag: I am surprised by this. modetest is a great tool. Would love to see support for it continues. Will help if I can as well!
<lumag> Yep. Marijn[m] also has been pinging me, as this tool is of great use during bringup
<karolherbst> cheako: I suspect the game itself is checking what GPU it sees and just doesn't run on Intel... or something. It's unknown to me what the reason for this problem is, but I'm confident that it will get resolved at some point
<gildekel> we use it daily for dev and debugging on ChromeOS, so it'll be quite tragic to have it drop without replacement. seanpaul_: FYI
heat has quit [Read error: No route to host]
heat has joined #dri-devel
<robclark> lumag: if you want to maintain it, I'm all for that
<seanpaul_> yeah. modetest, while awkward, is pretty useful
<lumag> robclark, then how can we proceed?
<idr> cheako: #intel-3d on OFTC is more likely to be active.
<robclark> lumag: I added you as a "Developer".. looks like libdrm isn't using margebot yet, not sure if there is a good reason for that or if something needs to be done.. but I think "Developer" should probably be enough to merge MRs
<gildekel> kudos for picking up the glove, lumag. Appreciated.
lynxeye has quit [Quit: Leaving.]
<alyssa> robclark: re sample locations, it was my understanding that gl_SamplePositions returns the default positions regardless, not that it was undefined
<alyssa> IDK where I saw that claim originally, though
<alyssa> (yes, this also makes gl_SamplePosition kinda useless.)
<robclark> as best I can tell, the `rgetpos` instruction doesn't even return that when user sample locs are enabled... so it matches the specified (ie. undefined) vk behavior ;-)
<alyssa> fair
<lumag> robclark, seems to work, thank you. Waiting for the MR to be merged
<alyssa> Honestly I'm very surprised that you have ISA level support for it, lol?
<robclark> lumag: cool, thx for volunteering
An0num0us has quit [Ping timeout: 480 seconds]
<alyssa> (As opposed to lowering to gl_SampleID + a uniform + some math)
<robclark> alyssa: yeah, and I could lower it to const lookup for sampleloc case.. but that would be extra shader variant and more draw-time overhead.. and not really thinking that it is worth adding that fraction of drawoverhead overhead
<lumag> gildekel, seanpaul_: I'll review outstanding MRs. Feel free to ping me in future if there is anything pending
<robclark> alyssa: I guess we could do some common lowering since zink has the same issue.. but I'm pretty meh about that combination of features ;-)
<alyssa> robclark: meh?
<robclark> esp when the one single user afaict is a single piglit test
<alyssa> i'm definitely not suggesting a shader variant
<alyssa> I'm more wondering why Qualcomm added in rgetpos in the first place
<robclark> oh.. less draw overhead ;-)
<alyssa> instead of doing a little bit of ALU and maybe some preamble stuff
<robclark> idk, maybe it was supposed to work w/ samplepos
<alyssa> yeah..
<alyssa> FWIW, Mali has the 'interesting' approach where the sample positions ptr is pushed directly into a special register in the shade
<alyssa> so you still recover gl_SamplePosition with math, not a special op
<alyssa> but there's no extra draw overhead, your
<alyssa> you couldn't do anything else with that uniform, etc
<robclark> not sure if dx has anything to say about this.. if vk doesn't care and there is no gles extension then I could see them maybe not testing this
<alyssa> ...Of course I think that's also broken with custom sample locs.
<alyssa> robclark: IDK, I think working with AGX has massively increased my tolerance for shader lowering shenanigans
<alyssa> =)
<alyssa> (Both because Apple does tremendous amounts of lowering to fit Metal onto this wacky hw, and also because I'm implementing APIs that the HW wasn't designed for.)
<robclark> lowering as long as not variant dependent isn't the end of the world.. but this would also mean pushing more const state.. so more draw time overhead.. so I'm sticking with the excuse that it is not worth penalizing other use cases when it is easier to say "yer holding it wrong" if someone tries to use gl_SamplePosition with user sample locs ;-)
<alyssa> mood
<alyssa> Like I said. AGX has massively increased my tolerance for shenanigans
rasterman has quit [Quit: Gettin' stinky!]
<alyssa> (It probably helps that the min-spec CPU I care about is massively faster than what freedreno has to care about, so I'm not nearly as worried about drawoverhead #s.)
<alyssa> robclark: Oh wait, now I'm noticing my entire samplepositions approach is silly tho
<alyssa> if it's supposed to return default positions I may as well just calculate as ALU in shader entirely
<alyssa> since I already have the num_samples
<alyssa> for the monolithic case, that means load_sample_position will constant fold away entirely
<alyssa> for the non-monolithic case, that means a bit more math. but probably not a huge deal
<alyssa> (and if it *is* a problem, I can preload the constants with a bit of linking magic. but I expect it's irrelevant.)
<robclark> it isn't just cpu overhead, at this point our cpu overhead is low enough that even on small cores, drawoverhead is CP limited without FD_MESA_DEBUG=nohw.. and pushing extra state for this one misconceived use-case is dumb
<alyssa> oh, yeah, that's true
<alyssa> ..and now I'm observing that prologs/epilogs totally breaks preambles
<alyssa> Erghhhh
<alyssa> maybe I want function ptrs instead of prologs/epilogs then :|
tzimmermann has quit [Quit: Leaving]
<HdkR> alyssa: Time for real subroutines? :D
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
<alyssa> HdkR: maybe
<alyssa> Actually no, I think if I run nir_opt_preamble on the fragment shader, the resulting preamble will still be valid for the linked pixel shader
<alyssa> It /does/ mean that we can't use preambles for the prologs/epilogs themselves, but that would be the case if they were subroutines too
<alyssa> unfortunately I could see that being a problem for e.g. load_blend_const
<alyssa> unless we just always reserve uniforms for the blend const unconditionally when epilogs are used
<alyssa> not the end of the world if so
illwieckz has quit [Ping timeout: 480 seconds]
rasterman has joined #dri-devel
illwieckz has joined #dri-devel
jewins has joined #dri-devel
<alyssa> strictly could concatenate preambles too but unlikely to be worth it
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
<pzanoni> In a Vulkan Mesa driver, when I need to allocate memory, when am I supposed to use malloc()-family functions vs when am I supposed to use vk_alloc()-family functions? Is there some documentation about it somewhere? What are the trade-offs?
macromorgan has quit [Quit: Leaving]
ceyusa has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
vjaquez has quit [Ping timeout: 480 seconds]
ceyusa is now known as vjaquez
An0num0us has joined #dri-devel
heat has quit [Remote host closed the connection]
heat has joined #dri-devel
grillo_0 has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
heat has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
heat has joined #dri-devel
Jeremy_Rand_Talos__ has joined #dri-devel
vliaskov has quit [Remote host closed the connection]
mbrost has joined #dri-devel
macromorgan has joined #dri-devel
sima has quit [Ping timeout: 480 seconds]
macromorgan has quit []
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
<aleasto-> hi, is there a public api to get the number of planes for a format-modifier combo before allocating a buffer?
junaid has quit [Ping timeout: 480 seconds]
<aleasto-> driver agnostic
junaid has joined #dri-devel
cazzacarna has quit [Quit: leaving]
cazzacarna has joined #dri-devel
<mareko> RGB888 isn't supported by any or most hw, it can only do power-of-two pixel sizes
<airlied> rgb888 in userspace isnt ever going to haopen
<airlied> if the kernel can accel xrgb by converting to packed rgb then that is the only place to do it
Duke`` has quit [Ping timeout: 480 seconds]
<aleasto-> oh great, gbm_device_get_format_modifier_plane_count exists
junaid has quit [Remote host closed the connection]
<alyssa> mareko: bizarrely Mali supports it
<alyssa> and IIRC I benchmarked a small perf improvement from using it over rgbx :\
<alyssa> bizarre decisions
heat_ has joined #dri-devel
heat has quit [Read error: No route to host]
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
Jeremy_Rand_Talos__ has joined #dri-devel
Jeremy_Rand_Talos_ has joined #dri-devel
Jeremy_Rand_Talos__ has quit [Remote host closed the connection]
jdavies_ has quit [Remote host closed the connection]
benjaminl has quit [Ping timeout: 480 seconds]
crabbedhaloablut has quit []
Jeremy_Rand_Talos_ has quit [Remote host closed the connection]
ngcortes has joined #dri-devel
rasterman has joined #dri-devel
An0num0us has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<idr> pzanoni: I don't have a full answer to your question, but... Vulkan provides a mechanism so that the application can control memory allocation. The system memory allocations done by the driver might call out to the application.
<pzanoni> idr: yeah, I'm also aware that CTS plays with things by making allocations fail and verify if programs are behaving as expected, that's why I gravitated more towards the vk_ versions, but I was recently asked to change some code to a version that used plain malloc() and started wondring about when each one was more desired/acceptable
benjaminl has joined #dri-devel
Cyrinux9474 has quit []
Cyrinux9474 has joined #dri-devel
DPA has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
DPA has joined #dri-devel
itsmeluigi has joined #dri-devel
itsmeluigi has quit [Quit: Konversation terminated!]
heat has joined #dri-devel
heat_ has quit [Read error: No route to host]
a-865 has quit [Quit: ChatZilla 0.17 [SeaMonkey 2.53.17/20230727221859]]
<Kayden> hmm. was wondering if a barrier intrinsic with WORKGROUP execution and memory scope, and no memory modes, even does anything useful. But I guess that's exactly what SPIR-V's OpControlBarrier is
elongbug has quit [Read error: Connection reset by peer]
<pendingchaos> you could probably combine it with non-control memory barriers to get what's effectively a combined memory+control barrier
Haaninjo has quit [Quit: Ex-Chat]
<alyssa> Kayden: Isn't that a GLSL barrier()?
<alyssa> Kayden: Oh, I guess the funny thing is having a non-NONE memory scope and no memory modes
<alyssa> Probably opt_barriers should drop the memory scope if there are no modes left?
<Kayden> yeah, it probably should
<Kayden> nir_to_dxil.c is having trouble with that, it seems that barriers need to have some kind of memory mode
<Kayden> I can try and have it set memory_scope = NONE then
<Kayden> should I leave memory semantics at ACQ|REL? seems like we always do that
a-865 has joined #dri-devel
benjamin1 has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
benjaminl has quit [Ping timeout: 480 seconds]
jewins has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
<Kayden> okay, this .gitlab-ci/bin/ci_run_n_monitor.py is pretty handy!
<zmike> amen
<Kayden> detects the wrong pipeline by default (the one in my personal repo, rather than the MR, which doesn't have all the d3d12 jobs), but easy enough to --pipeline-url
<Kayden> got a PKGBUILD for python-filecache too, I guess I should figure out how to put that in AUR
Danct12 has quit [Quit: What if we rewrite the code?]