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
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
<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.
<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.
<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>
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?
<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
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
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?]