Which means that the GPU frame time will go up. This isn’t ideal and leads to those stutters, if you suddenly look at 200mb+ of new mesh data, it’ll have to be transferred just in time for the frame. When you look at a DSF that wasn’t visible before, we asynchronously upload it to VRAM and just draw the mesh out of system memory, which means the GPU has to fetch the data from there to draw. To deal with this, X-Plane will simply not upload the non visible DSF meshes to VRAM and instead keeping them in system memory. You can easily blow 3+ Gb on just the mesh data, nothing else. For most users, even those with 8 Gb GPUs, it’s impossible to keep super high resolution meshes together with everything else in VRAM. The underlying problem here is VRAM management and large (U)HD meshes, which have to live somewhere. We have CLI flags to work around these stutters at the expense of additional VRAM, namely -gfx_dsf_in_vram and -gfx_obj_in_vram. Hopefully that’s an easy ask, as right now the download servers appear to be overloaded. We recommend waiting on Big Sur for a few days until we’ve had a chance to test it a bit. There’s been a lot of Apple news this week that’ll have to wait for a separate post. What about multiple GPUs? That’s something we’ll have to look at after we have multicore on the CPU–without it second GPU support doesn’t help. Note that multi-core multi-monitor would still be single GPU, and it would be a win because right now CPU time limits multi-monitor setups. Having a frame that can be farmed out to multiple cores would make multi-monitor less of a performance hit.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |