On Tue, May 19, 2020 at 3:44 PM Javad Karabi <karabijavad@xxxxxxxxx> wrote: > > just a couple more questions: > > - based on what you are aware of, the technical details such as > "shared buffers go through system memory", and all that, do you see > any issues that might exist that i might be missing in my setup? i > cant imagine this being the case because the card works great in > windows, unless the windows driver does something different? > Windows has supported peer to peer DMA for years so it already has a numbers of optimizations that are only now becoming possible on Linux. > - as far as kernel config, is there anything in particular which > _should_ or _should not_ be enabled/disabled? You'll need the GPU drivers for your devices and dma-buf support. > > - does the vendor matter? for instance, this is an xfx card. when it > comes to different vendors, are there interface changes that might > make one vendor work better for linux than another? i dont really > understand the differences in vendors, but i imagine that the vbios > differs between vendors, and as such, the linux compatibility would > maybe change? board vendor shouldn't matter. > > - is the pcie bandwidth possible an issue? the pcie_bw file changes > between values like this: > 18446683600662707640 18446744071581623085 128 > and sometimes i see this: > 4096 0 128 > as you can see, the second value seems significantly lower. is that > possibly an issue? possibly due to aspm? pcie_bw is not implemented for navi yet so you are just seeing uninitialized data. This patch set should clear that up. https://patchwork.freedesktop.org/patch/366262/ Alex > > On Tue, May 19, 2020 at 2:20 PM Javad Karabi <karabijavad@xxxxxxxxx> wrote: > > > > im using Driver "amdgpu" in my xorg conf > > > > how does one verify which gpu is the primary? im assuming my intel > > card is the primary, since i have not done anything to change that. > > > > also, if all shared buffers have to go through system memory, then > > that means an eGPU amdgpu wont work very well in general right? > > because going through system memory for the egpu means going over the > > thunderbolt connection > > > > and what are the shared buffers youre referring to? for example, if an > > application is drawing to a buffer, is that an example of a shared > > buffer that has to go through system memory? if so, thats fine, right? > > because the application's memory is in system memory, so that copy > > wouldnt be an issue. > > > > in general, do you think the "copy buffer across system memory might > > be a hindrance for thunderbolt? im trying to figure out which > > directions to go to debug and im totally lost, so maybe i can do some > > testing that direction? > > > > and for what its worth, when i turn the display "off" via the gnome > > display settings, its the same issue as when the laptop lid is closed, > > so unless the motherboard reads the "closed lid" the same as "display > > off", then im not sure if its thermal issues. > > > > On Tue, May 19, 2020 at 2:14 PM Alex Deucher <alexdeucher@xxxxxxxxx> wrote: > > > > > > On Tue, May 19, 2020 at 2:59 PM Javad Karabi <karabijavad@xxxxxxxxx> wrote: > > > > > > > > given this setup: > > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 -hdmi-> monitor > > > > DRI_PRIME=1 glxgears gears gives me ~300fps > > > > > > > > given this setup: > > > > laptop -thunderbolt-> razer core x -> xfx rx 5600 xt raw 2 > > > > laptop -hdmi-> monitor > > > > > > > > glx gears gives me ~1800fps > > > > > > > > this doesnt make sense to me because i thought that having the monitor > > > > plugged directly into the card should give best performance. > > > > > > > > > > Do you have displays connected to both GPUs? If you are using X which > > > ddx are you using? xf86-video-modesetting or xf86-video-amdgpu? > > > IIRC, xf86-video-amdgpu has some optimizations for prime which are not > > > yet in xf86-video-modesetting. Which GPU is set up as the primary? > > > Note that the GPU which does the rendering is not necessarily the one > > > that the displays are attached to. The render GPU renders to it's > > > render buffer and then that data may end up being copied other GPUs > > > for display. Also, at this point, all shared buffers have to go > > > through system memory (this will be changing eventually now that we > > > support device memory via dma-buf), so there is often an extra copy > > > involved. > > > > > > > theres another really weird issue... > > > > > > > > given setup 1, where the monitor is plugged in to the card: > > > > when i close the laptop lid, my monitor is "active" and whatnot, and i > > > > can "use it" in a sense > > > > > > > > however, heres the weirdness: > > > > the mouse cursor will move along the monitor perfectly smooth and > > > > fine, but all the other updates to the screen are delayed by about 2 > > > > or 3 seconds. > > > > that is to say, its as if the laptop is doing everything (e.g. if i > > > > open a terminal, the terminal will open, but it will take 2 seconds > > > > for me to see it) > > > > > > > > its almost as if all the frames and everything are being drawn, and > > > > the laptop is running fine and everything, but i simply just dont get > > > > to see it on the monitor, except for one time every 2 seconds. > > > > > > > > its hard to articulate, because its so bizarre. its not like, a "low > > > > fps" per se, because the cursor is totally smooth. but its that > > > > _everything else_ is only updated once every couple seconds. > > > > > > This might also be related to which GPU is the primary. It still may > > > be the integrated GPU since that is what is attached to the laptop > > > panel. Also the platform and some drivers may do certain things when > > > the lid is closed. E.g., for thermal reasons, the integrated GPU or > > > CPU may have a more limited TDP because the laptop cannot cool as > > > efficiently. > > > > > > Alex _______________________________________________ amd-gfx mailing list amd-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/amd-gfx
