Open vsfeedback opened 3 years ago
User Two: I rechecked the original post, there appears to be information gone missing from there (???) that we had posted on this before. There is some extra info still there on the stackexchange post.
We have used other vendor software to track what is going on already - showed the same thing. We even went down to tracking physical power usage of system components and gfx cards. Example of one of other tests we did- https://i.stack.imgur.com/erwsX.png ... "High usage = no profiler attached. When everything drops, the profiler is attached and running (from around 15-38 seconds). Big red arrows = my task. ". You can see windows tasks using less resource at this point too.
We can benchmark and use various methods of showing the same thing forever - again, MS have said they have replicated this issue so they must have had eyes on whatever is goings on. They also have access to things I don't for investigation purposes (like what the debugger is doing/setting/configuring).
You can physically see performance improve when all this takes place. I wouldn't mind if it did use more gpu resource when it takes place, I am more interested in getting my app's performance to improve (in this case helping smooth real time visuals where any jerky output matters)
Feel free to try a test project yourself - e.g. https://1drv.ms/u/s!As6cQRoZ5gU5x8FzXdwcYS1qEFqjdg?e=98o64j - myself and others have all replicated this across multiple hardware configurations.
:/
M.
Hi @ITheP. WPF can't do anything about the performance degradation caused by the GPU profiler. We think this was forwarded here in error. We will send it back to VS for investigation.
@ryalanms As far as i understood, the opposite is the case and perf improves when attaching the profiler.
@batzen @ryalanms Yes absolutely - performance is improving/resource usage is dropping when the profiler is attached. Would have expected the opposite.
This issue has been moved from a ticket on Developer Community.
I have a WPF application which contains lots of real time effects - drawing directly to bitmaps, shader effects, etc. - and it all works great. However, GPU usage is a higher than wanted - there are sometimes performance issues and smoothness issues. During the process of optimising, I tried attaching the Visual Studio profiler. When this is attached, and GPU Usage is selected as one of the profiling tools, when my WPF application runs… the same app, with the same content… GPU usage might be 50%+ less with better/smoother performance.
This is a duplicate of an open problem which I have been waiting for well over a year for MS to address. It has already been acknowledged by MS, and MS had already managed to replicate the issue. Other people have had and reported seeing the same problem. The original ticket has just been closed ?automatically? by MS because it was old, not because anything has been done about it, and says to re-report the issue here if it still happens. This issue possibly affects large numbers of other WPF projects if there are fundamental performance things going on with WPF itself.
You can see the original posting here which includes details, screenshots, examples, tests across different solutions and different h/w, extra information, example projects, etc.etc.etc.
Noting this technology isn't available in later frameworks such as UWP and WinUI.
Also to requote...
"....so we've seen this across multiple WPF apps on multiple .net frameworks - same thing on all. We are questioning if this could be pretty fundamental across a much wider WPF landscape?"
M.
Original Comments
User Two on 8/19/2021, 11:56 AM:
Verify the video card is not simply ramping up its performance. Lock the GPU to max speed, and memory, etc. Video cards loaf as much as possible. Sound familiar? If you monitor the GPU for its performance (to see if maxed, etc.), use software from the card maker and not from MS. The MS stuff just doesn’t work in real life*.
*FH4 running 4K 60 fps shows about 1% in TaskMgr’s GPU.
Feedback Bot on 8/19/2021, 08:08 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
mbasta00 on 8/26/2021, 03:11 AM:
User Two check the original post referenced, we did that and a load more, there’s a mass of information on it. And MS replicated the issue already. But thanks for the suggestion!
User Two on 8/26/2021, 00:50 PM:
That’s a lot (of going obviously around the round places) but still not using the card maker’s utility[*] to see the GPU freq. and its memory freq., and its voltage. The GPU ramping up its performance is the most likely explanation. Using MS tools to see what’s going on at the GPU is a mistake.
Don’t take this the wrong way. Take it as a road map. You do want to get over this right even if it means you spent a year+ chasing a ghost? (J/K, not) If you have used such a tool[], which, exactly, have you? You only ever mention TaskMgr as a way to see the GPU. These card-maker utilties[] are very simple-to-use software programs that are made for users – button pusher types.
[*]Video card makers have special software that controls the GPU on their cards. EVGA, e.g. has good stuff. I’m sure Asus and the others do, too. Use that kind of software to see what’s going at the GPU.
Original Solutions
(no solutions)