azonenberg changed the topic of #scopehal to: ngscopeclient, libscopehal, and libscopeprotocols development and testing | https://github.com/ngscopeclient/scopehal-apps | Logs: https://libera.irclog.whitequark.org/scopehal
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 245 seconds]
Degi_ is now known as Degi
bvernoux has joined #scopehal
bvernoux has quit [Read error: Connection reset by peer]
<d1b2> <johnsel> @azonenberg https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator might be useful for when you get to the 4G limit handling
<d1b2> <azonenberg> So we already have our own allocator that does similar stuff. there's an extension that i think would be useful for >4GB handling, i cant remember off the top of my head
<d1b2> <azonenberg> but there's a lot of other stuff needed before we think about that
<d1b2> <azonenberg> in terms of being more efficient with memory
<d1b2> <azonenberg> (also, because my biggest GPU only has like 12GB of RAM so >4GB waveforms are not really practical for me to work with atm lol)
<d1b2> <johnsel> Sure, I just thought I'd share it since it's AMD and seems to handle defragmentation a lot better than we currently do
<d1b2> <azonenberg> What's more important is to figure out better handling of waveforms that are older in history, but not being actively displayed
<d1b2> <azonenberg> right now we keep everything in gpu memory
<d1b2> <azonenberg> which has pros and cons, but there's room for flexibility around this