ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
iive has quit []
nchery has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
airlied has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
`join_subline has quit [Read error: Connection reset by peer]
`join_subline has joined #dri-devel
airlied has joined #dri-devel
lromwoo^ has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
ppascher has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
khfeng has joined #dri-devel
hch12907 has joined #dri-devel
airlied has quit [Remote host closed the connection]
bmodem has joined #dri-devel
lromwoo^ has quit [Ping timeout: 480 seconds]
<robclark>
rather not block shrinker (ie. not at least until you know there isn't lower hanging fruit in the system).. otoh at some point it becomes worthwhile to block, if you are calling shrinker as a result of trying to pin yet more bo's for queing the n+1'th submit/execbuf. I guess in some sense it would be useful to know whether we are in shrinker as result of our own memory allocation (in which case blocking==good) vs someone
<robclark>
ickle: btw, have you considered using whether shrink_control::gfp_mask has GFP_NOWAIT bit set as a signal that it is worth it for shrinker to block on active bo's to become idle? i915 doesn't seem to do that but I'm kinda thinking about it re: igt gem_shrinker tangent I mentioned in <CAJs_Fx6Nc337LPNh=p2GT2d2yDTdLWH934o4Cof3urDGhUJB6A@mail.gmail.com>.. one one hand, in early stages of memory pressure you probably would really
<robclark>
else's..
lromwoo^ has joined #dri-devel
airlied has joined #dri-devel
heat has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
Duke`` has joined #dri-devel
YuGiOhJCJ has joined #dri-devel
urja has quit [Ping timeout: 480 seconds]
lromwoo^ has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
lromwoo^ has quit [Ping timeout: 480 seconds]
ppascher has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #dri-devel
lemonzest has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
hch12907 has joined #dri-devel
sdutt has quit [Read error: Connection reset by peer]
pendingchaos has quit [Read error: Connection reset by peer]
lromwoo^ has quit [Ping timeout: 480 seconds]
mvlad has joined #dri-devel
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
macromorgan is now known as Guest121
macromorgan has joined #dri-devel
Guest121 has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #dri-devel
frieder has joined #dri-devel
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
jkrzyszt has joined #dri-devel
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
frieder has quit [Remote host closed the connection]
frieder has joined #dri-devel
otokawa_ has joined #dri-devel
lromwoo^ has quit [Ping timeout: 480 seconds]
danvet has joined #dri-devel
dreda has quit [Ping timeout: 480 seconds]
urja has joined #dri-devel
tursulin has joined #dri-devel
hch12907 has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
OftenTimeConsuming has quit [Remote host closed the connection]
bmodem has joined #dri-devel
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
OftenTimeConsuming has quit [Remote host closed the connection]
OftenTimeConsuming has joined #dri-devel
lynxeye has joined #dri-devel
mi6x3m has joined #dri-devel
<mi6x3m>
hey, i need some info as to what is going on. I start something with MESA_LOADER_DRIVER_OVERRIDE=swrast then i get this output https://pastebin.com/mSMSQ9jG but LLVM is used normally
pcercuei has joined #dri-devel
icecream95 has quit [Ping timeout: 480 seconds]
aravind has joined #dri-devel
saurabhg has joined #dri-devel
saurabhg has quit []
saurabhg has joined #dri-devel
bmodem has quit [Ping timeout: 480 seconds]
saurabhg has quit [Remote host closed the connection]
saurabhg has joined #dri-devel
real_name has joined #dri-devel
hch12907 has joined #dri-devel
saurabhg has quit [Remote host closed the connection]
saurabhg has joined #dri-devel
apinheiro has joined #dri-devel
whald has joined #dri-devel
rasterman has joined #dri-devel
mclasen has joined #dri-devel
bmodem has joined #dri-devel
rkanwal has joined #dri-devel
illwieckz has quit [Remote host closed the connection]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
real_name has quit []
ahajda__ has joined #dri-devel
pendingchaos has joined #dri-devel
saurabhg has quit [Ping timeout: 480 seconds]
<mlankhorst>
demarchi: Sorry, haven't done much gem work much lately, I'd inspect which fence is being installed I guess
hch12907 has quit [Ping timeout: 480 seconds]
illwieckz has joined #dri-devel
lemonzest has quit [Remote host closed the connection]
hch12907 has joined #dri-devel
lemonzest has joined #dri-devel
saurabhg has joined #dri-devel
alanc has quit [Remote host closed the connection]
<emersion>
also what does the driver do when user-space uses "no data"?
<emersion>
i suppose it doesn't set the IT flag?
<emersion>
it sounds to me like it would be better for compositor to unconditionally set the content type to "graphics" by default, when a more precise type isn't available
khfeng has quit [Ping timeout: 480 seconds]
bmodem has quit [Ping timeout: 480 seconds]
APic has quit []
<krh>
do we have minimum python3 version in mesa?
tjmercier has quit [Remote host closed the connection]
<demarchi>
mlankhorst: yeah... talked to Nirmoy after that message... we are indeed passing an array. He's working on a patch to fix that
minecrell has quit [Read error: Connection reset by peer]
<jekstrand>
pepp: Do you have time to test !4037 and make sure custom-queue blits still work?
minecrell has joined #dri-devel
jkrzyszt has quit [Ping timeout: 480 seconds]
APic has joined #dri-devel
bmodem has joined #dri-devel
<pepp>
jekstrand: I'll try tomorrow (today's attempts failed because my built kernel wouldn't boot)
<jekstrand>
pepp: Ok, thanks! As long as you're moving them forward, the kernel patches should be pretty easy to rebase. But they are based on big rework from Christian König at AMD so you can't port it back very far.
<vsyrjala>
emersion: i think the behaviour in the itc==0 case is undefined. but maybe someone likes what it does on their specific display, so i'd be a little hesitant to not inclue it in the protocol
<emersion>
vsyrjala: that makes sense. but do you think setting "graphics" by default would be a good behavior for compositors?
sravn has quit []
<vsyrjala>
yeah, sounds like a reasonable default for ui stuff. wonder if we should even make that the default in the kernel...
bmodem has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #dri-devel
<emersion>
that would be nice
technopoirot has joined #dri-devel
rgallaispou has left #dri-devel [#dri-devel]
whald has quit [Remote host closed the connection]
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
mi6x3m has quit [Remote host closed the connection]
kts has joined #dri-devel
iive has joined #dri-devel
alyssa has joined #dri-devel
lromwoo^ has quit [Ping timeout: 480 seconds]
lromwoo^ has joined #dri-devel
frieder has quit [Remote host closed the connection]
oneforall2 has quit [Read error: No route to host]
rasterman has quit [Remote host closed the connection]
rasterman has joined #dri-devel
mvlad has quit [Remote host closed the connection]
<jekstrand>
alyssa: No, that's per-driver. In the Gen8+ Intel drivers, we actually stick the constant blob at the end of the shader binary, bake the address into the shader, and use nir_load_global for it.
<jekstrand>
No UBO binding required. :)
<HdkR>
Sounds like a good reason to have a PC relative load in your GPU ISA :D
<alyssa>
jekstrand: Heh, it's an option!
<alyssa>
HdkR: Bifrost has it but I refuse to wire it uP ;p
<alyssa>
Valhall doesn't, AFAIK
<HdkR>
boo
lemonzest has quit [Quit: WeeChat 3.5]
lromwoo^ has quit [Ping timeout: 480 seconds]
<jekstrand>
On Intel, we have nir_intrinsic_load_reloc_const_intel
* alyssa
wonders what the fastest way to do it on AGX is
<jekstrand>
It emits a MOV dst <IMM> but with some extra metadata in brw_stage_prog_data telling us where it lives in the compiled binary so we can patch the actual immediate value later. Then we do the patching right before we upload it.
rkanwal has quit [Quit: rkanwal]
<alyssa>
Pretty cursed tbh
<jekstrand>
It is a bit cursed, yes, but it's also pretty awesome.
<alyssa>
Heh
<alyssa>
I wonder if we could make that work ...
<jekstrand>
How easy it is depends on your instruction encoding. On Intel, we can ensure that the immediate is a 32-bit thing that's nicely aligned.
<alyssa>
Mm
<alyssa>
Sounds pretty impossible on Bifrost for example
<jekstrand>
IIRC, it requires us to initially emit it with a constant value that we know will cause instruction compaction to give up.
<alyssa>
Cursed
<jekstrand>
Cursed but useful
<alyssa>
There's no obvious 'best' way on Valhall
<alyssa>
WTH
Duke`` has quit [Ping timeout: 480 seconds]
Haaninjo has quit [Quit: Ex-Chat]
lromwoo^ has joined #dri-devel
danvet has quit [Ping timeout: 480 seconds]
`join_subline has quit [Ping timeout: 480 seconds]
`join_subline has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
ahajda__ has quit []
pcercuei has quit [Quit: dodo]
icecream95 has joined #dri-devel
<graphitemaster>
I reading the entire email thread started last year about moving from implicit sync to explicit sync everywhere during my vacation because of a phronix article - that whole thing needs a summary, but also is there any updates on that project, like a newer thread, I'd like to follow it.
<graphitemaster>
Was quite a journey reading through all of those, but it seems the conversation went cold
<bnieuwenhuizen>
no idea about that part of the puzzle
tursulin has quit [Remote host closed the connection]
tursulin has joined #dri-devel
JohnnyonF has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
<graphitemaster>
The gist of it seems to be that everyone wants to do explicit sync but it's a nightmare making it all work with the existing drm sync primitives and wsi / compositors
<graphitemaster>
But having explicit sync would effectively solve most of the userspace stability issues when it comes to preemption
<graphitemaster>
And make timeline semaphores in Vulkan actually work the way they're supposed to work
<bnieuwenhuizen>
explicit vs. implicit sync and preemption are kinda orthogonal actually
<graphitemaster>
Well it has to do with the whole deadlock/timeout scenario specifically, letting user-space spin on something every frame rather than tearing shit down works much better from a robustness standpoint when it comes to long running compute kernels
<bnieuwenhuizen>
the problem is that dma_fence (whether it be explicit or implicit) has semantics which are too strong due to being a blocker for memory stuff
<graphitemaster>
right, there was a suggestion of drawing some artificial lines between dma_fence use at the wsi layer and non-wsi layer where distinctions can be made and encoded so weaken the semantics of it where it's necessary
tursulin has quit [Remote host closed the connection]
<graphitemaster>
I really liked that suggestion.
<graphitemaster>
Rather than adding yet another sync type
tursulin has joined #dri-devel
morphis has quit [Ping timeout: 480 seconds]
<graphitemaster>
Move more of the work into the compositor mainly when it comes to unresponsive stuff too, that feels very appropriate to me. Less in kernel space the better, the more applications using APIs like Vulkan where the whole robustness argument is moot and can just hammer frames without anyone in their way the better I think as well.
morphis has joined #dri-devel
<graphitemaster>
Let the compositor just render garbage when tearing down an incomplete swap
<graphitemaster>
It'll eventually be repainted
<graphitemaster>
Lots of really neat suggestions in there.