<javierm>
danvet: that should be safe to land now since the patch to mark the olpc dcon fbdev driver was broken already landed in v5.19-rcX
<javierm>
*as broken
rkanwal has joined #dri-devel
Major_Biscuit has joined #dri-devel
saurabhg has joined #dri-devel
tursulin has joined #dri-devel
Haaninjo has joined #dri-devel
bmodem has joined #dri-devel
bmodem has quit []
pcercuei has joined #dri-devel
<javierm>
tzimmermann: thanks a lot for your thoughts on the drm_mode_config patch. I'm already a happy camper since fixed my issue with the msm driver but I thought that was still worth to prevent it for other drivers
<javierm>
tzimmermann: but not a hill I'm willing to die for :)
<tzimmermann>
javerm, sorry for shooting down the patch
<javierm>
tzimmermann: no worries at all. That's the whole point of our review process
<tzimmermann>
i've ran into problems with incorrect drm_mode_config_reset. i wasn't aware that the init side has issues too
<javierm>
tzimmermann: the problem is when init doesn't happen but the driver does not know about it
<javierm>
drivers blindly call modeset helpers that assume the mode config was already done
<javierm>
but as mentioned that may not be the case due probe failing, bind callback not called, etc
<MrCooper>
phaddad ishitatsuyuki: r600 & radeonsi support different HW generations, there's no choice between them for any given GPU
<MrCooper>
Frogging101: that can happen without compositing
<phaddad>
MrCooper I thought r600 could work on Southern Island (CAPE VERDE) cards
<MrCooper>
nope
<phaddad>
it doesn't matter now though I suppose since both seem to require LLVM
<MrCooper>
completely different shader architectures
<phaddad>
I was worried about byte for byte reproducibility of LLVM libraries, but I think it will be OK looking into it
<MrCooper>
maybe you're thinking of the radeon vs amdgpu kernel drivers?
<phaddad>
well I'm a little confused with that situation
<MrCooper>
you're not alone there :)
<phaddad>
It seems like amdgpu can be used with my card
<phaddad>
however it doesnt seem to work well
<phaddad>
especially looking for the correct firmware
<phaddad>
Is the intention for amdgpu to eventually just replace radeon altogether whether its old or new hw?
<MrCooper>
the last few HW generations have only been supported by amdgpu
<MrCooper>
only SI & CIK generations are supported by both
<phaddad>
I see
<phaddad>
so my card being SI means technically its supported by both
<MrCooper>
yep
<phaddad>
would it be worth trying to get it to work, as in performance benefit being substantial?
<MrCooper>
the main benefit is Vulkan support
<phaddad>
right, well not worth the effort for my situation then :)
<phaddad>
Our games are pure 2D for specific embedded hardware
<phaddad>
Porting our software to vulkan wouldn't be worth it for me right now
<phaddad>
It seems that python is used to build some of the Xorg graphics stack, but its not needed as a runtime dependency though right?
<MrCooper>
right, it's mainly used for meson (the build system used by most graphics stack components now)
nchery has joined #dri-devel
<javierm>
tzimmermann: btw, do you need review of your "drm: Add driver for PowerPC OF displays" series ?
<javierm>
tzimmermann: I think that Geert was reviewing that one ?
<tzimmermann>
javierm, yes that would be helpful
<tzimmermann>
no?
<tzimmermann>
was he?
<tzimmermann>
there was only one comment
<javierm>
tzimmermann: ah, only comments for patches #4 and #6 indeed
<javierm>
tzimmermann: Ok. I'll go through that series today then. I'm a little bit behind on my dri-devel inbox
<tzimmermann>
thank you
<javierm>
yw
JohnnyonFlame has quit [Ping timeout: 480 seconds]
heat has joined #dri-devel
icecream95 has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<phaddad>
This is a little off topic, but am I crazy for going with a full LFS/BLFS build that easily takes up to 3 hours to make a full system as opposed to just using something like debootstrap and build a base debian system that I could possibly customize? The main goals here are to achieve full byte for byte reproducibility of the resulting system image
<phaddad>
and achieve read only mount of an ext2 fs. Ubuntu is a little annoying with initramfs when trying to achieve read only system mounting
lynxeye has joined #dri-devel
jkrzyszt has joined #dri-devel
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
jkrzyszt has quit [Remote host closed the connection]
icecream95 has quit [Ping timeout: 480 seconds]
JohnnyonFlame has joined #dri-devel
pendingchaos_ is now known as pendingchaos
pcercuei has quit [Read error: Connection reset by peer]
pcercuei has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
saurabh_1 has joined #dri-devel
saurabhg has quit [Read error: Connection reset by peer]
dviola has joined #dri-devel
gawin has joined #dri-devel
jkrzyszt has joined #dri-devel
kts has joined #dri-devel
SoulReaper has joined #dri-devel
zzoon2627thholiday[m] has joined #dri-devel
jkrzyszt has quit [Remote host closed the connection]
flto_ has quit []
flto has joined #dri-devel
kts has quit [Ping timeout: 480 seconds]
kts has joined #dri-devel
saurabh_1 has quit [Ping timeout: 480 seconds]
srslypascal has quit [Remote host closed the connection]
srslypascal has joined #dri-devel
karolherbst_ is now known as karolherbst
kts has quit [Ping timeout: 480 seconds]
vliaskov has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
lynxeye has quit [Quit: Leaving.]
jfalempe has quit [Read error: Connection reset by peer]
jfalempe has joined #dri-devel
jfalempe_ has joined #dri-devel
sul has joined #dri-devel
eletrotupi has quit [Remote host closed the connection]
eletrotupi has joined #dri-devel
fahien has quit [Ping timeout: 480 seconds]
fahien has joined #dri-devel
Terman has joined #dri-devel
rkanwal has quit [Quit: rkanwal]
rkanwal has joined #dri-devel
saurabhg has joined #dri-devel
jewins has joined #dri-devel
ickle has joined #dri-devel
mbrost has joined #dri-devel
fxkamd has joined #dri-devel
sdutt has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
mbrost has quit [Ping timeout: 480 seconds]
<karolherbst>
jekstrand: sooo... we do have hw with incomplete support for conversions. I was wondering if we want to have a generic nir lowering pass where you can specify what works (or what doesn't) and the pass splits a convert op into two. e.g. u2u64(a) of a 8 bit value would be split into u2u64(u2u32(a))
<jekstrand>
karolherbst: nir_lower_bit_size will do that
<karolherbst>
ahh
saurabhg has quit [Remote host closed the connection]
<karolherbst>
I also saw some references inside nir_lower_int64
<karolherbst>
jekstrand: huh.. but lower_bit_size is doing something different, no?
<karolherbst>
it just moves the ALU to the supported bit size and converts the values back
<karolherbst>
mhh although for converts that might just work out, but rounding bits might break it
<jekstrand>
karolherbst: Yeah, but if you tell it to lower a u2u64, to 32-bit, it'll turn it into a 32-bit u2u32 with a u2u32 on the src.
<jekstrand>
Intel drivers do this
<karolherbst>
kind of feels like it would break rounding modes honestly
<karolherbst>
but maybe that's fine...
<jekstrand>
Yeah, not sure it handles rounding modes. But most of the rounding mode stuff is in the intrinsic, not `u2u32`.
<karolherbst>
right.. but long term we want to consume the intrinsics anyway
<karolherbst>
and not having to lower rounding modes
<jekstrand>
Sure
<karolherbst>
mhhhh
mbrost has joined #dri-devel
<karolherbst>
thing is.. alu opts won't work on the intrinsics :(
<jekstrand>
And we can deal with that.
<karolherbst>
right...
<jekstrand>
For now, if you're just concerned about u2u64 on 8-bit things, nir_lower_bit_sizes will do that.
<karolherbst>
yeah... we got somebody new on the team and I was thinking if dealing with conversion stuff might be a good start to work on nouveau compiler bits... just trying to figuring out what we think the end result should look like
<danvet>
javierm, for the unexport patch unblocked by dcon marked as broken, feel free to just push it
<danvet>
I'm a bit burried :-)
iive has joined #dri-devel
Company has joined #dri-devel
<jekstrand>
karolherbst: I think step 1 is making `nir_lower_alu_conversion_to_intrinsic` take a callback to say which ones to lower and which ones the driver can handle. Then implement the ones you can do 100% natively. We can figure out how to handle lowering `f2u8_sat(x)` to `fu32_sat(u2u8_sat(x))` later.
sdutt has quit []
sdutt has joined #dri-devel
<javierm>
danvet: sure, it was just fyi :) Already got acks so I'll push it later today
<karolherbst>
jekstrand: okay... but that means all supported conversions will end up as intrinsics and passed like this into the driver, no?
<danvet>
javierm, thx
<karolherbst>
any idea how we want to deal with that? make nir_search be aware of that, or....
<jekstrand>
karolherbst: yes, you'll get them as intrinsics.
<jekstrand>
karolherbst: What does nir_search have to do with it?
<karolherbst>
for nir_opt_algebraic?
<karolherbst>
would disable quite a lot of optimizations if we end up with them as intrinsics instead
<jekstrand>
most of those optimizations don't know what to do with rounding modes anyway
<karolherbst>
yeah, sure.. but if you get your plain u2u as an intrinsic instead
<karolherbst>
and I am sure some of them apply regardless of rounding mode
<karolherbst>
but we might have to decide case by case
<jekstrand>
We don't. In spirv_to_nir, we only emit the intrinsic if it's needed.
<karolherbst>
ahhh
<karolherbst>
guess then we can find until relevant work loads arrive which actually care about opts in this regard and don't care until then
<karolherbst>
s/find/ignore it/
<jekstrand>
At some point, if there's a real problem to be solved (I'm not convinced there is), we can try to expand nir_search to support it or add some new ALU ops for new rounding combinations. But that's something for later and not something I'm going to hand off to an intern or new person.
<daniels>
pretty telling that whilst NIR could be written by an intern, nir_search cannot be worked on by an intern
<karolherbst>
yeah...
<karolherbst>
that's also the bit I wouldn't want an intern to already work at, just tried to figure out how it should look like in the end
<karolherbst>
also, not an intern, just new :)
<karolherbst>
consuming the intrinsics is so much better than dealing with the lowered code, so missed out optimizations might still lead to better code regardless
<jekstrand>
karolherbst: If it involves modifying nir_search.c, there are exactly two people I trust to do and/or review that. :)
<karolherbst>
:D
yoslin has joined #dri-devel
Lucretia has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
Wszdexdrf has joined #dri-devel
saurabhg has joined #dri-devel
Wszdexdrf has quit []
<tursulin>
uh oh amdgpu_vram_mgr.h is conflicting in drm-tip rebuild what do I do with it?
tzimmermann has quit [Quit: Leaving]
Duke`` has joined #dri-devel
fab has joined #dri-devel
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
pcercuei has quit [Remote host closed the connection]
pcercuei has joined #dri-devel
<javierm>
tursulin: that issue has been present for weeks :(
Major_Biscuit has quit [Ping timeout: 480 seconds]
rkanwal has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
kts has joined #dri-devel
JohnnyonFlame has quit [Read error: Connection reset by peer]
kennylevinsen has quit [Remote host closed the connection]
Rayyan has quit [Remote host closed the connection]
ifreund has quit [Remote host closed the connection]
jkrzyszt has joined #dri-devel
kennylevinsen has joined #dri-devel
sumoon has joined #dri-devel
kchibisov has joined #dri-devel
Rayyan has joined #dri-devel
anujp has joined #dri-devel
anujp has quit []
kchibisov has quit [Remote host closed the connection]
Rayyan has quit [Remote host closed the connection]
sumoon has quit [Remote host closed the connection]
kennylevinsen has quit [Remote host closed the connection]
kennylevinsen has joined #dri-devel
kchibisov has joined #dri-devel
Rayyan has joined #dri-devel
sumoon has joined #dri-devel
ifreund has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
<Frogging101>
[04:51:26] <MrCooper> Frogging101: that can happen without compositing
<Frogging101>
Yeah, that's what I've learned.
<Frogging101>
And I'm also now remembering that unredirecting is a thing, so you can run games with compositing enabled without a performance hit. But I also recall that KDE removed the ability to do that because it was broken
<anholt>
sadly it looks like gitlab doesn't have a way to disable @all
kts has quit [Quit: Konversation terminated!]
<Sachiel>
can a username all be created to swallow all those?
zf_ has joined #dri-devel
<emersion>
pretty sure it's reserved
sagar_ has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.5]
agd5f_ has joined #dri-devel
agd5f has quit [Ping timeout: 480 seconds]
gouchi has joined #dri-devel
<JoniSt>
zmike: New subdata merge MR is !17741 btw in case you didn't see it yet
<zmike>
I did not
<JoniSt>
Ah, gitlab must've eaten the CC then
<zmike>
you have to @ to get a cc
gawin has quit [Ping timeout: 480 seconds]
<JoniSt>
Ahhh, oops. Thanks :)
<zmike>
hm so you're doing an initial version and then improving on it after?
<JoniSt>
We could do either that, or just try to improve it before merging. I'm not sure what's better - leaving the merged subdata call in the batch so the driver can execute it normally later or copy the data into a temp allocation so we can invalidate.
<zmike>
well as it is it's still better perf than the existing code
<JoniSt>
Yeah it sure is. It's also pretty simple code
<zmike>
I don't know that we have to reach the most optimal possible outcome on the first try
<JoniSt>
That's true. And the question is whether allocating a new buffer (in the invalidation path) isn't more expensive than simply leaving the subdata call in the batch
<JoniSt>
We can never skip invalidation after all since the buffer will always be busy due to the first subdata call that was added
<zmike>
I think it would be more expensive to leave it as-is since invalidation would allow skipping the final memcpy
<zmike>
the driver will be suballocating buffers, so as long as we clamp to something like 1<<20 as max size (this is the upper bound for most suballocators in mesa I think) then it should be much faster
<JoniSt>
Well we can't hit 1<<20 anyway because of the batch size that limits us
<JoniSt>
We have around 12kB
<zmike>
hm
<zmike>
what hw do you have? if you're on amd you should be able to run the sparse binding cts
<zmike>
which has this exact behavior
<JoniSt>
Navi21, so yes, I'll look into it :)
<zmike>
great
<JoniSt>
If we really wanted to go to town, we could check the size of the call, and only do invalidate+map when it's bigger than TC_MAX_SUBDATA_BYTES, otherwise leave the merged subdata call in the batch
<JoniSt>
That way small buffers still get their subdata calls merged into one, and big buffers get to benefit from unsync mapping
<zmike>
I think there's a lot of options and a lot of variables here
<zmike>
but even just this level of change is likely to have big perf gains for stupid test cases
<JoniSt>
Yup, so maybe really just merge it as it is now and improve later. If we do that, I'd say we can just leave the unused tc_erase_last_valid_call function in there since it'll come in handy later anyway
fxkamd has quit [Remote host closed the connection]
<zmike>
probably not, CI will explode in release builds
fxkamd has joined #dri-devel
<zmike>
but merging now does sound good
<JoniSt>
Ah, got it :)
<JoniSt>
I'll remove it then if you don't mind
<zmike>
👍
<JoniSt>
Should be good to go now :)
gawin has joined #dri-devel
<zmike>
still draft
<JoniSt>
Ah I forgot
srslypascal is now known as Guest6005
srslypascal has joined #dri-devel
<JoniSt>
zmike: maybe "is_mergeable_buffer_subdata" in case something similar gets added to tc_texture_subdata?
<zmike>
sure
<zmike>
and I assume you've tested this?
<JoniSt>
Yeah I ran it through CI like this and tried it locally
<zmike>
I meant with the sparse tests specifically
<zmike>
I'm not sure ci tests those
<JoniSt>
Only CI so far but I'll run them locally too
Guest6005 has quit [Ping timeout: 480 seconds]
<JoniSt>
Still not thaaat familiar with piglit etc :)
<zmike>
you'll learn :)
srslypascal is now known as Guest6006
srslypascal has joined #dri-devel
<JoniSt>
Hmm wait a second, where even is that test?
<JoniSt>
Ah, dEQP probably
<zmike>
you just run it the same as usual with ./glcts
<JoniSt>
That'd assume I've ever worked with that before, I'll try to figure it out :P
<zmike>
ah ok
<zmike>
have you built cts before?
<JoniSt>
Not at all, but I did find the readme
<zmike>
basically you clone the repo, run python external/fetch_sources.py
<zmike>
then do the usual cmake build dance
<JoniSt>
Got it :)
<zmike>
once it's done (tomorrow), you can cd build/external/openglcts/modules
<zmike>
and use glcts to run tests
<JoniSt>
Oh no, it takes *that* long?
<zmike>
well it's not quick
Guest6006 has quit [Ping timeout: 480 seconds]
<JoniSt>
A Threadripper would be nice now
<zmike>
yes
srslypascal has quit [Quit: Leaving]
fab has quit [Quit: fab]
srslypascal has joined #dri-devel
<JoniSt>
Oh man, the CTS has a typo in its CMakeLists currently
<JoniSt>
Well it's compiling now, yay :)
<JoniSt>
Should probably open a bug report
<gawin>
adavy: is it possible to use llvmpipe for vertex shaders with nine?
<ajax>
gawin: the gallium 'draw' module has that for non-vs hardware like i915 and some r300
<gawin>
I was thinking about crocus, there's some nasty bug probably connected to vs
<ajax>
crocus hardware all has hardware vs so... i mean you could do it but fixing the bug would be nicer
Duke`` has quit [Ping timeout: 480 seconds]
<gawin>
I agree, just any approach I've tried to pinpoint the problem resulted in nothing
<gawin>
I'd love to have working renderdoc
<JoniSt>
zmike: Massive perf gains :)
<zmike>
hooray
<JoniSt>
Appears to be even better than the original version (probably because we don't create so many batches)
<JoniSt>
Uuuhh I mean calls in the batch
<zmike>
nice
<zmike>
add that to the commit log
<JoniSt>
Done! :)
<zmike>
nice work
<JoniSt>
Thanks! I'm glad I'm at least somewhat useful here :P
<zmike>
super useful, we're just slow
<JoniSt>
I wouldn't say I'm fast either
<JoniSt>
But hey, maybe I'll soon land my first Mesa commit, yay :)
<zmike>
hoping to get this one in before branchpoint
<zmike>
will see what mareko_'s schedule is like
<JoniSt>
It'd also be pretty great to get !17338 in before the branchpoint because multi-context with TC is just totally broken without it
<zmike>
well that can always go in as a backport so not a big deal
<JoniSt>
True! I just really really want to see this fixed :P
<zmike>
just waiting on mareko_ for perf analysis again
mvlad has quit [Remote host closed the connection]
<JoniSt>
Yeah... Though the question is also whether that 1.3% hit on a synthetic stress test might not simply be worth taking in exchange for not exploding anymore
<zmike>
whoa whoa
<zmike>
you can't talk like that
<zmike>
we save every percent here
<ccr>
every percent is saaacreed .. every percent is goood ..
<JoniSt>
I know how much radeonsi is after every last 0.1% of perf :P
<JoniSt>
Though I also just don't really understand how an atomic that never gets executed at all impacts perf this much...
danvet has quit [Ping timeout: 480 seconds]
<zmike>
btw you should be clicking resolve when you address review comments
<zmike>
unfortunately I don't have the right type of cpu to do this benchmarking or else I'd test it out
<JoniSt>
In 17338? Yeah, I just wasn't sure if mareko was happy with my resolutions there
<JoniSt>
So I left these ones unresolved for the time being
<zmike>
the reviewer can always reopen
<JoniSt>
Alright :)
<zmike>
but otherwise a casual reviewer might do a drive-by and see all the unresolved itesm
<JoniSt>
Gotcha! Then only the perf thread should stay unresolved I'd say.
gouchi has quit [Quit: Quitte]
<zmike>
yep
ybogdano has quit [Ping timeout: 480 seconds]
ybogdano has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
mareko_ is now known as mareko
<mareko>
JoniSt: under very special conditions, a conditional branch never taken can cost 2% of performance if it's there
<mareko>
without state changes, I think we can process 1 draw in ~100 CPU cycles
<airlied>
which is worse, a cond branch or an indirect function call?
<mareko>
no idea
<mareko>
the call most likely
* airlied
wonders if merging draw between gallium and mesa further is a good idea, but it involves that tradeoff
<airlied>
getting rid of dd.h Draw indirect
<mareko>
hold that for a moment
<mareko>
we need different callbacks for select and feecback
<mareko>
an indirect call is great if it removes lots of conditionals like template<> si_draw()
SoulReaper has quit [Remote host closed the connection]
<mareko>
if each driver could benefit from setting different st_draw_vbo, I think we could gain more from the indirect call
<airlied>
so it ends up with a ctx->RenderMode conditional vs ctx->Driver indirect
rkanwal has joined #dri-devel
<mareko>
we have more select variants because there is now hw accel via GS
<airlied>
mareko: ah yes I'd have to update that now
<mareko>
let's keep the indirect call
<mareko>
on a different note, it's super interesting to run a benchmark with a profiler and see performance issues immediately; I just ran a test I had thought we weren't gonna make faster, and saw that it could be made faster rather easily, so I did that
gawin has quit [Ping timeout: 480 seconds]
<airlied>
mareko: if only gpu profiling was as easy to use :-)
<mareko>
GPU profiling is mainly about knowing the architecture, and then it's still mostly guessing anyway
<airlied>
CPU profiling hits that problem, when the first mem load from a struct is where all the time is being spent!
<mareko>
I wish we could profile CPU caches better
<JoniSt>
Hmm, maybe that "unlikely" macro really is all it takes then
gawin has joined #dri-devel
<adavy>
gawin: no
<adavy>
I mean, unless you do it in the driver itself
<adavy>
what kind of issues do you have that make you want to use it ?
<mareko>
unlikely really means never
<mareko>
and sometimes that doesn't help either
<adavy>
gawin: though just for info, d3d9 does have a state to switch between software and hardware vertex shader. The "software" shader is emulated on hardware by wine, nine and dxvk. It basically just allows more constants to be used and a few tweaks
mbrost has quit [Remote host closed the connection]
mbrost has joined #dri-devel
mbrost_ has joined #dri-devel
<JoniSt>
mareko: Well, hitting that atomic is so rare that it really might just be never. The entire test case hit it 5 times while rendering thousands of frames, so the unlikely macro might (hopefully) just do it
mbrost has quit [Read error: Connection reset by peer]
<adavy>
(for example, for your curiosity, apps expect that when you use software shader, since you are running on cpu, you don't need to care about optimized buffer bindings... or locking again right away the vertex buffer and write at the same location. So we have to be clever to make things fast)
<gawin>
pipe dream demo has alternative mode (without textures) and it's visible that something is messing triangles
rkanwal has quit [Quit: rkanwal]
ngcortes has joined #dri-devel
Haaninjo has quit [Quit: Ex-Chat]
gawin has quit [Ping timeout: 480 seconds]
kem has quit [Ping timeout: 480 seconds]
vliaskov has quit [Remote host closed the connection]
rcf has quit [Quit: WeeChat 3.4.1]
rcf has joined #dri-devel
kem has joined #dri-devel
rcf has quit []
rcf has joined #dri-devel
mbrost__ has joined #dri-devel
mbrost_ has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
rcf has quit [Quit: WeeChat 3.4.1]
rcf has joined #dri-devel
pcercuei has quit [Quit: dodo]
soreau has quit [Read error: Connection reset by peer]