Well as long as we don't need to save any content it should be trivial to implement resource management with the existing code. I will take a look why allocating GDS BOs fail at the moment, if it is something trivial we could still fix it. Christian. Am 13.09.2018 um 23:01 schrieb Marek Olšák: > To be fair, since we have only 7 user VMIDs and 8 chunks of GDS, we > can make the 8th GDS chunk global and allocatable and use it based on > a CS flag. It would need more work and a lot of testing though. I > don't think we can do the testing part now because of the complexity > of interactions between per-VMID GDS and global GDS, but it's > certainly something that people could add in the future. > > Marek > > On Thu, Sep 13, 2018 at 3:04 PM, Marek Olšák <maraeo at gmail.com> wrote: >> I was thinking about that too, but it would be too much trouble for >> something we don't need. >> >> Marek >> >> On Thu, Sep 13, 2018 at 2:57 PM, Deucher, Alexander >> <Alexander.Deucher at amd.com> wrote: >>> Why don't we just fix up the current GDS code so it works the same as vram >>> and then we can add a new CS or context flag to ignore the current static >>> allocation for gfx. We can ignore data persistence if it's too much >>> trouble. Assume you always have to init the memory before you use it. >>> That's already the case. >>> >>> >>> Alex > _______________________________________________ > amd-gfx mailing list > amd-gfx at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
