Announcement

Collapse
No announcement yet.

Ryzen 3 2200G Video Memory Size Testing On Linux

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    It is interesting results. If it's true that some games adjust quality settings based on VRAM size, then that could explain differences in performance to some degree. Otherwise it seems logical to conclude that most games will perform relatively the same. Whether VRAM is allocated in the BIOS or not, the driver is going to alocate whatever RAM is needed anyway.

    Comment


    • #12
      bridgman / agd5f If vram reporting can be an issue, and using vram from memory is fine even if only 64mb are carved (which apparently is not), then why not just fake the amount of vram like intel does (with a bounded user selectable configuration)?

      Regarding the swapping, shouldn't apus be using a zero-copy mechanism, seeing it's basically the same pool? This obviously for non hypervisor shared devices.

      Also, can explain a bit more the memory differences between linux and windows and if possible where those changes are nedeed (kernel, amdgpu, etc)?

      Thanks


      Comment


      • #13
        Thanks for the test Michael

        These on Windows should test OpenGL games that run mulithread profiles, i would expect some shit there too Any ID game like for example Doom 3, where profile only works with 512 MB VRAM on High or 1GB for Ultra AFAIR. Set buffer to 64 MB in BIOS and profile won't work or better to say High/Ultry would still work but you won't see boost from profile anymore.

        Gaming up to medium won't show too much an issue. Also clear GPU bound cases won't much if at all also, but many CPU boundware will

        He, he and these mobile Ryzen APUs auto to 256 MB while on Desktop APU auto is 1 GB



        And i guess that can't be changed on laptops? But tells the story about scenario i guess this is sort of lower power trade of too, since most boosts happens on or prefer higher carve so this will intentionaly also save some power.

        Whatever most will leave it at Auto anyway, basically "fire it to 2GB if you can" if you want perf (and to raise compatability) is an best advice regardless of OS, if you wanna avoid some these (non) issues Otherwise it is just an option, so set it to whatever you want (as it might works just fine enough for your workload/scenario) but beware setting it too much low will break some apps and/or some perf.
        Last edited by dungeon; 19 February 2018, 08:13 PM.

        Comment


        • #14
          Originally posted by fahrenheit View Post
          bridgman / agd5f If vram reporting can be an issue, and using vram from memory is fine even if only 64mb are carved (which apparently is not), then why not just fake the amount of vram like intel does (with a bounded user selectable configuration)?
          I'm not sure I understand what you are asking here.

          Originally posted by fahrenheit View Post
          [USER="8184"]
          Regarding the swapping, shouldn't apus be using a zero-copy mechanism, seeing it's basically the same pool? This obviously for non hypervisor shared devices.
          They are separate pools. "vram" is a contiguous chunk of memory reserved by the bios at boot. system memory is normally accessed via GPU page tables so that the non-contiguous pages look contiguous to the GPU. The "vram" memory is actually contiguous. The GPU does not have to go through page tables to access it, at least when using the system (kernel driver) context in the GPU. As such the latency is lower which is important for certain blocks like display. Historically our display hw required contiguous memory. Also, depending on whether the system memory is cached on the CPU, the GPU may need to do a cache snooped or non-cache snooped access. Those two paths, at least on older asics, had different performance characteristics. The last generation of APUs (Carrizo/Bristol and Stoney) gained the ability for the display hardware to scan out from non-contiguous pages (i.e., GPU addresses that go through the GPU page tables). We only recently enabled this on Linux for those asics. Support for Raven for this feature is not complete yet. So if you want to display a buffer it has to been in "vram" right now for raven (and dGPUs). Other blocks (e.g., gfx and compute) have always been able to use either pool.


          Originally posted by fahrenheit View Post
          [USER="8184"]
          Also, can explain a bit more the memory differences between linux and windows and if possible where those changes are nedeed (kernel, amdgpu, etc)?
          Fundamentally there aren't really any. The windows driver still has separate pools for "vram" and system ram as well. That said, the OS provides the memory manager and scheduler on windows for all GPUs while in Linux it's up to the individual drivers. The only difference is that I think windows has enabled display scan out from system memory for raven, while we have not yet on Linux.

          Comment


          • #15
            Originally posted by agd5f View Post
            I'm not sure I understand what you are asking here.
            Maybe better to explain it with example, what he asks for Set 64 MB UMA in you BIOS and then if you can run this unity game for example:

            http://store.steampowered.com/app/31...d_New_n_Tasty/

            It is really an Oddworld , since without some mechanism to force faking or adjusting more memory for an APU in this 64MB scenario game (or better to say engine) gives you utter lowest textures and that does not look fine

            At least in this example "faking" should work, with auto it starts fine but with that low set just gave you BS

            Now, AFAIU he won't this faking by design and by default (which is a bit too much) everwhere.
            Last edited by dungeon; 19 February 2018, 09:18 PM.

            Comment


            • #16
              We do allow setting the size of (what I think you are calling fake) VRAM though, don't we ?
              Test signature

              Comment


              • #17
                But is this really just reported by device driver (a'ka fake) video ram size but otherwise available for OS to give away, or actually preallocated from system memory pool (no longer available for applications via malloc).

                Comment


                • #18
                  Originally posted by bridgman View Post
                  We do allow setting the size of (what I think you are calling fake) VRAM though, don't we ?
                  Yeah, BIOS also allow setting sizes. But thing is, it does not work on so much low - some apps getting broken See this:

                  On 64MB in BIOS:


                  with 256MB became normal:


                  So seems app require 256MB minimum to render fine (while engine allows less, so it goes down to crap), so there should be a way to fake these 256 (or at least up to auto or something safe like that) on a system with 64 default.
                  Last edited by dungeon; 19 February 2018, 11:59 PM.

                  Comment


                  • #19
                    Not sure what you mean by "fake". If you tell the app it has a certain amount of VRAM it will try to use it, and if the advertised amount is not backed by memory then Bad Things will happen. Why not just advertise enough memory for the app to work correctly ?

                    If your concern is about not permanently segregating off 256MB of system memory from the OS then I guess there are some GFX9-only options using recoverable page faults, but I'm not sure it's worth it if we are only talking about making an extra 192MB of memory to the OS when running non-game apps which tend to be the least memory intensive anyways.
                    Test signature

                    Comment


                    • #20
                      Originally posted by bridgman View Post
                      Not sure what you mean by "fake". If you tell the app it has a certain amount of VRAM it will try to use it, and if the advertised amount is not backed by memory then Bad Things will happen.
                      But that is why i said to be safe "allow faking it up to Auto" as Auto all will have, isn't it? Desktop Ryzen APU have 1 GB auto, Kaveri too, Ryzen mobile APU have 256 MB auto, some other earler like Kabini have 512 MB auto... so i don't think you would run into an issue if you will allow faking it up to that

                      If your concern is about not permanently segregating off 256MB of system memory from the OS then I guess there are some GFX9-only options using recoverable page faults, but I'm not sure it's worth it if we are only talking about making an extra 192MB of memory to the OS when running non-game apps which tend to be the least memory intensive anyways.
                      Mine concern is that i think of those who would like to set it as low as possible, as this is idea here and issues are like with this example . Now, of course if you recommends to fire up all Ryzen APUs to 2 GB then i agree anyways
                      Last edited by dungeon; 20 February 2018, 12:57 AM.

                      Comment

                      Working...
                      X