slow rx 5600 xt fps

Wed May 20 01:19:42 UTC 2020

s/Monitor0/MonitorA

(the Monitor0 and Monitor1 are actually Monitor4 (for the laptop) and
Montor0 (for the hdmi output), atleast i think that was the numbers.)
they were autogenerated Monitor identifiers by xorg, so i dont
remember the exact numbers, but either way, for some reason the
radeon's DisplayPort-1-2 was "using" the same monitor as modesetting's
eDP1

On Tue, May 19, 2020 at 8:16 PM Javad Karabi <karabijavad at gmail.com> wrote:
>
> thanks for the answers alex.
>
> so, i went ahead and got a displayport cable to see if that changes
> anything. and now, when i run monitor only, and the monitor connected
> to the card, it has no issues like before! so i am thinking that
> somethings up with either the hdmi cable, or some hdmi related setting
> in my system? who knows, but im just gonna roll with only using
> displayport cables now.
> the previous hdmi cable was actually pretty long, because i was
> extending it with an hdmi extension cable, so maybe the signal was
> really bad or something :/
>
> but yea, i guess the only real issue now is maybe something simple
> related to some sysfs entry about enabling some powermode, voltage,
> clock frequency, or something, so that glxgears will give me more than
> 300 fps. but atleast now i can use a single monitor configuration with
> the monitor displayported up to the card.
>
> also, one other thing i think you might be interested in, that was
> happening before.
>
> so, previously, with laptop -tb3-> egpu-hdmi> monitor, there was a
> funny thing happening which i never could figure out.
> when i would look at the X logs, i would see that "modesetting" (for
> the intel integrated graphics) was reporting that MonitorA was used
> with "eDP-1",  which is correct and what i expected.
> when i scrolled further down, i then saw that "HDMI-A-1-2" was being
> used for another MonitorB, which also is what i expected (albeit i
> have no idea why its saying A-1-2)
> but amdgpu was _also_ saying that DisplayPort-1-2 (a port on the
> radeon card) was being used for MonitorA, which is the same Monitor
> that the modesetting driver had claimed to be using with eDP-1!
>
> so the point is that amdgpu was "using" Monitor0 with DisplayPort-1-2,
> although that is what modesetting was using for eDP-1.
>
> anyway, thats a little aside, i doubt it was related to the terrible
> hdmi experience i was getting, since its about display port and stuff,
> but i thought id let you know about that.
>
> if you think that is a possible issue, im more than happy to plug the
> hdmi setup back in and create an issue on gitlab with the logs and
> everything
>
> On Tue, May 19, 2020 at 4:42 PM Alex Deucher <alexdeucher at gmail.com> wrote:
> >
> > On Tue, May 19, 2020 at 5:22 PM Javad Karabi <karabijavad at gmail.com> wrote:
> > >
> > > lol youre quick!
> > >
> > > "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"
> > >
> > > whoa, i figured linux would be ahead of windows when it comes to
> > > things like that. but peer-to-peer dma is something that is only
> > > recently possible on linux, but has been possible on windows? what
> > > changed recently that allows for peer to peer dma in linux?
> > >
> >
> > A few things that made this more complicated on Linux:
> > 1. Linux uses IOMMUs more extensively than windows so you can't just
> > pass around physical bus addresses.
> > 2. Linux supports lots of strange architectures that have a lot of
> > limitations with respect to peer to peer transactions
> >
> > It just took years to get all the necessary bits in place in Linux and
> > make everyone happy.
> >
> > > also, in the context of a game running opengl on some gpu, is the
> > > "peer-to-peer" dma transfer something like: the game draw's to some
> > > memory it has allocated, then a DMA transfer gets that and moves it
> > > into the graphics card output?
> >
> > Peer to peer DMA just lets devices access another devices local memory
> > directly.  So if you have a buffer in vram on one device, you can
> > share that directly with another device rather than having to copy it
> > to system memory first.  For example, if you have two GPUs, you can
> > have one of them copy it's content directly to a buffer in the other
> > GPU's vram rather than having to go through system memory first.
> >
> > >
> > > also, i know it can be super annoying trying to debug an issue like
> > > this, with someone like me who has all types of differences from a
> > > normal setup (e.g. using it via egpu, using a kernel with custom
> > > configs and stuff) so as a token of my appreciation i donated 50$ to
> > > the red cross' corona virus outbreak charity thing, on behalf of
> > > amd-gfx.
> >
> > Thanks,
> >
> > Alex
> >
> > >
> > > On Tue, May 19, 2020 at 4:13 PM Alex Deucher <alexdeucher at gmail.com> wrote:
> > > >
> > > > On Tue, May 19, 2020 at 3:44 PM Javad Karabi <karabijavad at gmail.com> 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 at gmail.com> 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 at gmail.com> wrote:
> > > > > > >
> > > > > > > On Tue, May 19, 2020 at 2:59 PM Javad Karabi <karabijavad at gmail.com> 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