search for: no_shar

...t the same run time now that the submit overhead issue has been fixed. I think this means that we can proceed under the assumption that there are no more serious perf issues with the new API. I'm happy to RB/ACK the next version of the API and implementation patches, as long as it has the new NO_SHARE BO create flag and properly rejects exports of NO_SHARE BOs, even if not all of the dma_resv plumbing is fully baked. ~Faith -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20230730/80238903/attachment....

On 7/25/23 18:43, Danilo Krummrich wrote: > On 7/25/23 18:16, Faith Ekstrand wrote: >> Thanks for the detailed write-up! That would definitely explain it. If >> I remember, I'll try to do a single-threaded run or two. If your >> theory is correct, there should be no real perf difference when >> running single-threaded. Those runs will take a long time, though, so

...../$(BINDIR)/Rblas.dll: blas.o blas2.o cmplxblas.o cmplxblas2.o ../../gnuwin32/dllversion.o @$(ECHO) -------- Building $@ -------- and then passing USE_ATLAS = YES and ATLAS_PATH = C:/R/OPB/whatever in Mkrules.local When I compile OpenBLAS, I have always done so with NO_CBLAS, NO_LAPACK, and NO_SHARED, as the Windows toolchain does not need CBLAS, a shared library, or allow for a separate LAPACK and this has worked, for the most part, since roughly 2013. When building the recent R-devel (a revision slightly before 86534), the compilation stopped when building Rblas with the following error: -...

So far the DRM GPUVA manager offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVA manager represent a basic GPU-VM