Closed Bug 1357744 Opened 8 years ago Closed 4 years ago

No GPUProcessPid and GPIPRocess entries In the Graphics section of about:support in FIrefox 53 stable

Categories

(Core :: Graphics, enhancement, P3)

53 Branch
enhancement

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: rick3162, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [gfx-noted])

(Regarding the GPU process) I updated to FF 53 x64 stable today (win10). According to this article https://www.ghacks.net/2017/04/19/firefox-53-0-release-find-out-what-is-new/ which is based upon bug 1314133 (comment1)) the feature requires that your system has: - Windows 7 SP1 or up. - Multi-process enabled. - non-blacklisted graphics card. So my system has: - windows 10x 64 - e10s is enabled (screenshot: http://i.imgur.com/SD022Tf.jpg) - the "layers.gpu-process.enabled" pref in about:config is true - there are 2 firefox.exe processes at Firefox launch in Task Manager (260). - my GPU is GTX 780 Ti, with latest nVidia drivers: 381.65, 4/6/2017. My GPU doesn't seem to be blacklisted. But, in the Graphics section of about:support (screenshot: http://i.imgur.com/lpELgkM.jpg) there are no GPUProcessPid and GPIPRocess entries. Not even in a clean Firefox profile. Therefore, I wonder whether GPU process is enabled for me or not. PS. For reference, in today's (4/19) FF 55 Nighly x64, the two entries (GPUProcessPid and GPIPRocess) are shown ok (screenshot: http://i.imgur.com/0H1IgXV.jpg) and it's apparent that the GPU process is indeed enabled.
If you navigate to a "normal" page in the browser (e.g., mozilla.org) are you still just seeing two processes in the task manager? We don't show the "kill process" button in the release, but the GPU/compositor process should still exist.
Whiteboard: [gfx-noted]
> If you navigate to a "normal" page in the browser (e.g., mozilla.org) are you still just seeing two processes in the task manager? No. I see 2 processes only when I have an empty tab open. If I navigate to any page such as mozilla.org, then they become 3 (screenshot from a fresh profile: https://i.imgur.com/rWrVntE.jpg ) So, the GPU process is enabled for me. Thank you. So the plan is to add the 'Terminate GPU process' button (i.e. the two entries: GPUProcessPid and GPIPRocess) in Firefox 54, as someone wrote to me in mozillazine forum?
Actually, the current plan is to have those two entries remain in nightly only, and not show up in the beta or release at all. It felt like functionality that we wouldn't want or need in the release builds, especially the "kill" button. I'm happy to reconsider this decision - outside of testing to see if you got the GPU process, is there a workflow where you'd want to know the ID or even kill the process from the browser?
> I'm happy to reconsider this decision - outside of testing to see if you got the GPU process, is there a workflow where you'd want to know the ID or even kill the process from the browser? First of all, I believe that the (lack of) discoverability of this new feature should not be underestimated. Currently, although this new feature is listed first in the FF53 release notes[1] , it's not explained in the linked articles [2][3] how to test whether it's enabled for you, and the only way to check is to watch in task manager that the firefox.exe processes increase 3 from 2, whenever you navigate to any page. I'm sure others like me wondered whether the feature is enabled for them after updating to FF53. I'd like to know the GPU process ID, in order to distinguish it from that of e10s, and not confuse it with being a renamed plugin-container.exe. Also, a 'Terminate GPU process' button would facilitate trying the new feature (comparing it with the previous functionality, and/or helping identify a bug of/caused by the GPU process feature when noticing a problem while browsing), because as I noticed, if you kill the GPU process, it seems to reload the page in the main process again - it doesn't make a new GPU process (i.e. not launch a 3rd firefox.exe again). [1] https://www.mozilla.org/en-US/firefox/53.0/releasenotes/ [2] https://blog.mozilla.org/blog/2017/04/19/first-big-bytes-project-quantum/ [3] https://ashughes.com/?p=426
(In reply to Kostas from comment #4) > > I'm happy to reconsider this decision - outside of testing to see if you got the GPU process, is there a workflow where you'd want to know the ID or even kill the process from the browser? > > First of all, I believe that the (lack of) discoverability of this new > feature should not be underestimated. Perhaps you could expand on why you think this feature should be discoverable at all. In my opinion it is a platform feature that has no user-facing functionality aside from: 1) Seeing three firefox.exe processes in task manager (most users won't seek out nor care about) 2) Fewer browser crashes (most users won't notice this unless they're on a highly unstable system) 3) Enabling further improvements down the line when WebRenderer ships (impacts users well in the future) The feature in Firefox 53 is essentially "fewer graphics related crashes taking down the entire browser" which is not really a "feature" at all -- it's fixing a longstanding bug that's existed since browsers started trying to use the GPU. > Currently, although this new feature is listed first in the FF53 release > notes[1], it's not explained in the linked articles [2][3] how to test whether it's > enabled for you, and the only way to check is to watch in task manager that the firefox.exe > processes increase 3 from 2, whenever you navigate to any page. I believe that the process will be spawned on startup along with the main and content process, and not on page load. I could be wrong on that point though so I'll leave it to David Anderson or Milan to correct me. > I'm sure others like me wondered whether the feature is enabled for them > after updating to FF53. > > I'd like to know the GPU process ID, > in order to distinguish it from that of e10s, > and not confuse it with being a renamed plugin-container.exe. > > Also, a 'Terminate GPU process' button would facilitate trying the new > feature (comparing it with the previous functionality, and/or helping identify a bug > of/caused by the GPU process feature when noticing a problem while browsing), This is not how you A/B test bugs related to GPU Process. The terminate button emulates the process dying and is only useful for testing bugs that occur on process death -- however it should be noted clicking the terminate button uses a slightly different code path than what happens when a process dies for real. If you want to A/B test a bug the most valid way to do that is to test with layers.gpu-process.enabled:true and then again with layers.gpu-process.enabled:false (after restarting of course). > because as I noticed, if you kill the GPU process, it seems to reload the page > in the main process again - it doesn't make a new GPU process > (i.e. not launch a 3rd firefox.exe again). This is by design. We do not support multiple restarts of the GPU Process in Firefox 53. This functionality will come in a future version.
Thanks for your comments Kostas; you have very valid points - we just don't expect people with that much technical involvement, curiosity and understanding to deal with the release, but we expect them a lot sooner - on beta or nightly. So, in a way, both your requests and Anthony's points are valid, just depends on the targeted audience. I think it probably won't hurt to put the compositor process ID (and we should not call it GPU process) in the about:support; it would probably only make 55, as I believe it needs localization, so we can't jump too far ahead. And to clear up the question on restarting the compositor process - in 53 we never did. In nightly we restart a few times before we give up. We'll likely refine that process to be based on frequency, rather than just the number of crashes, but if we allow the compositor process without GPU acceleration, then that logic will change even further.
Dupe of bug 1358138?
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.