ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
pcercuei has quit [Quit: dodo]
mbrost has joined #dri-devel
<DrNick> ah, so the problem is that power management actually works sometimes and the GPU gets suspended entirely, and then something wakes it up and the wakeup powers on the display? and the display manages to stay powered off only when the GPU never gets suspended in the first place
<airlied> daniels, tomeu : is panfrost lab down? jobs seem t obe timing out
<DrNick> lol the thing that makes display suspension work is when thunderbird gets stuck playing its throbber animation forever
linearcannon has quit [Read error: Connection reset by peer]
<airlied> hmm looks like all the collabara lab is down, the iris jobs are also timing out
linearcannon has joined #dri-devel
thellstrom1 has joined #dri-devel
tursulin has quit [Read error: Connection reset by peer]
thellstrom has quit [Read error: Connection reset by peer]
danvet has quit [Ping timeout: 480 seconds]
robink has quit [Read error: Connection reset by peer]
ngcortes has quit [Remote host closed the connection]
ToastVGA has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
oneforall2 has quit [Quit: Leaving]
oneforall2 has joined #dri-devel
<graphitemaster> No one would happen to know if there are desktop GL implementations that support something like Pixel Local Storage?
<graphitemaster> Or if there's a reasonably way to implement that optimization on desktop other than a massive mega kernel with shared memory.
<graphitemaster> The main requirement is multi-pass reuse of data for bandwidth reasons. I'm surprised PLS did not make it to Desktop actually.
<graphitemaster> Such an easy optimization.
<graphitemaster> That or just give me a draw call / compute dispatch that doesn't flush caches :P
<HdkR> graphitemaster: Atomic image stores to images the size of your framebuffer?
<HdkR> But yes, no desktop GPUs support PLS
<HdkR> You could also do SSBOs I guess
<HdkR> Wouldn't really be that much of an optimization though at that point though :D
cworth has quit [Ping timeout: 480 seconds]
<graphitemaster> Yeah right now I just have like 4-5 passes over 4 GiB worth of voxel data.
<graphitemaster> And I'd like to implement something like "voxel local storage" because all the passes operate on the same neighboring voxels
<graphitemaster> No way to really optimize bandwidth here because there's still no multi-pass shared data store.
<graphitemaster> PLS wouldn't even be enough frankly, but I wish the core idea existed.
<HdkR> Hope the GPU's caching really helps here since walking that entire set at 60FPS is like 240GB/s then
<graphitemaster> Consoles have had really fast pieces of EDRAM to store gbuffers because of the bandwidth costs associated with it and that EDRAM would just stay solid for all the passes, which is basically like pixel local storage but better :P
<graphitemaster> I kind of want that :P
<graphitemaster> Yeah it's not exactly fast :P
<HdkR> If you use images stores for the data you might get lucky on some hardware that has unified texture caches
columbarius has joined #dri-devel
cworth has joined #dri-devel
<graphitemaster> Yeah that's what is currently being used.
co1umbarius has quit [Ping timeout: 480 seconds]
<graphitemaster> 372 GB/s on a laptop 3080 though isn't that bad all things considered
<HdkR> then if you're already hitting the compression that you get from that path as well
<HdkR> hah, you're basically maxing out that memory BW then
<graphitemaster> Also maxing out the poor rasterizer
<graphitemaster> Every tiny voxel is alpha blended :P
mbrost has quit [Ping timeout: 480 seconds]
<graphitemaster> Waiting for my 1 TiB/s GPUs to become the norm in consumer laptops.
mclasen has joined #dri-devel
<HdkR> pfft, in a laptop? That's gonna be a while
<HdkR> Although maybe a GPU vendor will be kind and ship a mobile GPU with two sites of HBM3 :D
<graphitemaster> I'd be happy if it were the norm on desktop GPUs even.
<graphitemaster> I wonder if I could implement something like TBDR for voxels though in compute.
<graphitemaster> It doesn't change the amount of bandwidth but if I could just do all the passes from start to end on chunks of voxels at a time, that should make more effective use of cache presumably
<graphitemaster> I kind of already do that but it's clearly not enough
<HdkR> Were you using nsight tools to see what your bottleneck is? Could guide some decision making
Toast has joined #dri-devel
ToastVGA has quit [Read error: Connection reset by peer]
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
pnowack has quit [Ping timeout: 480 seconds]
<agd5f> imre, unfortunately that fix doesn't seem to work reliably per the gitlab bug
camus1 has joined #dri-devel
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
Net147 has quit []
Net147 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
Toast has quit [Ping timeout: 480 seconds]
ToastVGA has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
<agd5f> imre, airlied: do you know if there is a simple way to check if efifb is bound to the same device as the driver other than open coding the aperture check?
eukara has joined #dri-devel
<airlied> agd5f: shouldn't it be impossible? or is this before takeover?
<airlied> agd5f: but yeah pretty much taking the linear address and intersecting it with the driver controlled addresses is the only real info I think you have
<agd5f> before take over. I'd like a fallback if we can fix this runtime pm issue soon
<agd5f> *can't
<agd5f> just disable runtime pm on the device that was used by efifb rather than disabling runpm unconditionally
<agd5f> was just hoping there was some helper before I copied over a bunch of code from fbmem.c
<airlied> agd5f: just maybe add a helper to fbmem.c if it helps
Company has quit [Quit: Leaving]
pendingchaos_ has joined #dri-devel
pendingchaos has quit [Ping timeout: 480 seconds]
zip100_ has joined #dri-devel
zip100 has quit [Ping timeout: 480 seconds]
lemonzest has quit [Quit: WeeChat 3.3]
ToastVGA has quit [Ping timeout: 480 seconds]
Duke`` has joined #dri-devel
mclasen has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has joined #dri-devel
aravind has joined #dri-devel
jewins has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #dri-devel
mszyprow has joined #dri-devel
JoseExposito has joined #dri-devel
JosExpsito[m] has joined #dri-devel
pnowack has joined #dri-devel
JoseExposito has quit [Quit: JoseExposito]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
camus has joined #dri-devel
YuGiOhJCJ has quit [Remote host closed the connection]
YuGiOhJCJ has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
jhli has quit [Ping timeout: 480 seconds]
<javierm> agd5f: I believe DRM drivers don't use the fbdev aperture reserve infrastructure and so you can't check for aperture overlaps
Lucretia has quit []
tursulin has joined #dri-devel
<MrCooper> DrNick: I suppose mutter shouldn't get the GPU timestamp if it isn't going to draw anything
<MrCooper> YaLTeR[m]: ^
<DrNick> ultimate it is from cogl_onscreen_egl_swap_buffers_with_damage
pcercuei has joined #dri-devel
Haaninjo has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
thellstrom has joined #dri-devel
thellstrom1 has quit [Ping timeout: 480 seconds]
pochu has quit [Quit: Lost terminal]
gouchi has joined #dri-devel
<HdkR> I notice llvmpipe is allocating a 16MB rwxp buffer upfront even when I'm not using llvmpipe (es2_info with freedreno). Seems like an oversight somewhere in LLVMPipe's initialization
<MrCooper> could be the draw module rather than llvmpipe itself
<HdkR> Could be. Looks like the JIT code is actually getting executed as well
<MrCooper> the former can end up using LLVM for JITing vertex processing code with any driver for some exotic GL functionality
<MrCooper> maybe this could be delayed until it's really needed, which will never be the case with most real world apps
<MrCooper> (except for HW with no vertex shaders)
ella-0 has joined #dri-devel
kevinx has joined #dri-devel
<kevinx> daniels: Hi Daniel, gpg and ssh public key has been uploaded to issue, please help to check it again, thank you!
Major_Biscuit has quit []
MajorBiscuit has joined #dri-devel
rasterman has joined #dri-devel
mlankhorst has quit [Remote host closed the connection]
mlankhorst has joined #dri-devel
Major_Biscuit has joined #dri-devel
MajorBiscuit has quit [Ping timeout: 480 seconds]
YaLTeR[m] has left #dri-devel [#dri-devel]
YaLTeR[m] has joined #dri-devel
shankaru has joined #dri-devel
pendingchaos_ is now known as pendingchaos
flacks has quit [Quit: Quitter]
flacks has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
Surkow|laptop has quit [Remote host closed the connection]
Surkow|laptop has joined #dri-devel
camus has quit [Remote host closed the connection]
camus has joined #dri-devel
Company has joined #dri-devel
Dantheman825 has joined #dri-devel
Dantheman825 has left #dri-devel [#dri-devel]
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
mlankhorst has quit [Ping timeout: 480 seconds]
samuelig__ has joined #dri-devel
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
mclasen has joined #dri-devel
ybogdano has quit [Remote host closed the connection]
Lucretia has joined #dri-devel
jewins has joined #dri-devel
thellstrom1 has joined #dri-devel
thellstrom has quit [Remote host closed the connection]
JohnnyonFlame has joined #dri-devel
samuelig__ has quit []
ramaling has quit [Ping timeout: 480 seconds]
kevinx has quit [Quit: Connection closed for inactivity]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
kevinx has joined #dri-devel
shankaru has quit [Quit: Leaving.]
mszyprow has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
iive has joined #dri-devel
mszyprow has joined #dri-devel
aravind has quit [Ping timeout: 480 seconds]
nsneck has joined #dri-devel
pcercuei has quit [Quit: brb]
jhli has joined #dri-devel
moony has quit []
pcercuei has joined #dri-devel
moony has joined #dri-devel
moony has quit []
moony has joined #dri-devel
co1umbarius has joined #dri-devel
columbarius has quit [Ping timeout: 480 seconds]
Danct12 has joined #dri-devel
kevinx has quit [Quit: Connection closed for inactivity]
<agd5f> javierm, it works for checking against firmware framebuffers though
robink has joined #dri-devel
moony has quit []
moony has joined #dri-devel
moony has quit []
moony has joined #dri-devel
<javierm> agd5f: yes, but I think just the FBINFO_MISC_FIRMWARE flag is used for that ?
mszyprow has quit [Ping timeout: 480 seconds]
pnowack has quit [Quit: pnowack]
ybogdano has joined #dri-devel
pnowack has joined #dri-devel
Duke`` has quit []
Duke`` has joined #dri-devel
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ngcortes has joined #dri-devel
JohnnyonFlame has joined #dri-devel
MajorBiscuit has joined #dri-devel
Major_Biscuit has quit [Ping timeout: 480 seconds]
camus has joined #dri-devel
camus1 has quit [Remote host closed the connection]
vargasj has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
Duke`` has quit [Ping timeout: 480 seconds]
<airlied> robclark: is there an msm-next somewhere? or did I get it already and forget :-)
pnowack has quit [Quit: pnowack]
MajorBiscuit has quit [Ping timeout: 480 seconds]
vargasj has quit []
rasterman- has joined #dri-devel
camus1 has joined #dri-devel
camus has quit [Read error: Connection reset by peer]
rasterman- has quit []
rasterman- has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
rasterman- has quit []
rasterman has joined #dri-devel
jhli has quit [Ping timeout: 480 seconds]
JohnnyonFlame has quit [Ping timeout: 480 seconds]
ella-0_ has joined #dri-devel
ella-0 has quit [Remote host closed the connection]
gouchi has quit [Remote host closed the connection]