Hmm, I got the shutdown hang on 16.4.2, so that's actually unrelated. That driver does fix content going black, though. Working driver: Features Compositing Direct3D 11 Asynchronous Pan/Zoom wheel input enabled; touch input enabled WebGL Renderer Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding Yes; D3D11 blacklisted with DLL atidxx32.dll (8.17.10.661); Using D3D9 API Direct2D true DirectWrite true (10.0.10586.0) GPU #1 Active Yes Description AMD Radeon (TM) R9 390 Series Vendor ID 0x1002 Device ID 0x67b1 Driver Version 16.150.2401.0 Driver Date 4-15-2016 Drivers aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Subsys ID 20151462 RAM 4095

AMD R9 390, Windows 10 64-bit, Nightly, AMD Crimson Drivers 16.5.3 After browsing for a few minutes the content window goes black (which effectively renders Firefox unusable). Restarting the browser then fails because of a shutdown hang, which ends up in the crash reporter. I'll post the signature in a followup, but it's a common "shutdown hang in layers" bug. This happened after a Nightly + drivers update. Because of the following, I'm fairly sure it's the drivers: https://www.reddit.com/r/Amd/comments/4ky4tz/amd_stahp_every_driver_after_1642_has_this/

Shutdown hang is here: https://crash-stats.mozilla.com/report/index/0e682e87-993f-4c38-b46b-1cdb92160524

Broken driver: Features Compositing Direct3D 11 Asynchronous Pan/Zoom wheel input enabled; touch input enabled WebGL Renderer Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding Yes; D3D11 blacklisted with DLL atidxx32.dll (8.17.10.671); Using D3D9 API Direct2D true DirectWrite true (10.0.10586.0) GPU #1 Active Yes Description AMD Radeon (TM) R9 390 Series Vendor ID 0x1002 Device ID 0x67b1 Driver Version 16.200.1013.0 Driver Date 5-20-2016 Drivers aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Subsys ID 20151462 RAM 4095

about:support when this happens: failures CP+[GFX1]: [D2D1.1] 1CreateBitmap failure Size(25,28) Code: 0x8899000c format 7 Failure Log (#0) CP+[GFX1]: [D2D1.1] 1CreateBitmap failure Size(25,28) Code: 0x8899000c format 7 (#384) CP+[GFX1]: Failed to create DrawTarget, Type: 7 Size: Size(16,16) (#385) CP+[GFX1]: [D2D1.1] 3CreateBitmap failure Size(16,16) Code: 0x8899000c format 0 (#386) CP+[GFX1]: Failed to create DrawTarget, Type: 7 Size: Size(16,16) (#387) CP+[GFX1]: [D2D1.1] 3CreateBitmap failure Size(16,16) Code: 0x8899000c format 0 (#388) CP+[GFX1]: Failed to create DrawTarget, Type: 7 Size: Size(16,16) (#389) CP+[GFX1]: [D2D1.1] 3CreateBitmap failure Size(16,16) Code: 0x8899000c format 0 (#390) CP+[GFX1]: Failed to create DrawTarget, Type: 7 Size: Size(16,16) (#391) CP+[GFX1]: [D2D1.1] 3CreateBitmap failure Size(16,16) Code: 0x8899000c format 0 (#392) CP+[GFX1]: Failed to create DrawTarget, Type: 7 Size: Size(16,16) (#393) CP+[GFX1-]: Detected rendering device reset on refresh (#394) CP+[GFX1]: [D2D1.1] 3CreateBitmap failure Size(32,32) Code: 0x8899000c format 0 (#395) CP+[GFX1]: Failed to create DrawTarget, Type: 7 Size: Size(32,32) (#396) CP+[GFX1]: Failed to create software bitmap: Size(32,32) Code: 0x8899000c (#397) CP+[GFX1-]: DrawTargetCairo::Snapshot with bad surface 0 (#398) CP+[GFX1-]: Detected rendering device reset on refresh

I have similar problems, as can be seen here: https://bugzilla.mozilla.org/show_bug.cgi?id=1276520 It occurs with every Firefox version from 47 to 49. Crimson 16.6.1 with the fix "Display flickering or corruption may be experienced when playing videos in a web browser" doesn't solve this issue. I can reproduce this on two machines, one with a R9 390, one with an R7 270X. Both machines run Win10 64bit.

My about:support graphics section when this happens: Graphics -------- Features Compositing: Direct3D 11 Asynchronous Pan/Zoom: wheel input enabled WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon (TM) R9 390 Series Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding: No; Direct2D: true DirectWrite: true (10.0.10586.0) GPU #1 Active: Yes Description: AMD Radeon (TM) R9 390 Series Vendor ID: 0x1002 Device ID: 0x67b1 Driver Version: 16.200.1025.0 Driver Date: 6-2-2016 Drivers: aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Subsys ID: 20151462 RAM: 4095 GPU #2 Active: No Description: Intel(R) HD Graphics 3000 Vendor ID: 0x8086 Device ID: 0x0112 Driver Version: 9.17.10.4229 Driver Date: 5-27-2015 Drivers: igdumd64 igd10umd64 igd10umd64 igdumd32 igd10umd32 igd10umd32 Subsys ID: 0000000c RAM: Unknown Diagnostics ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 AzureCanvasAccelerated: 0 AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100 failures: CP+[GFX1]: [D2D1.1] 4CreateBitmap failure Size(320,180) Code: 0x8899000c format 1 Failure Log (#0): CP+[GFX1]: [D2D1.1] 4CreateBitmap failure Size(320,180) Code: 0x8899000c format 1 (#109): CP+[GFX1]: [D2D1.1] 4CreateBitmap failure Size(294,165) Code: 0x8899000c format 1 (#110): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#111): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#112): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#113): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#114): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#115): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#116): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#117): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#118): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#119): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#120): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#121): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#122): CP+[GFX1-]: Detected rendering device reset on refresh: 4 (#123): CP+[GFX1-]: Detected rendering device reset on refresh: 4

(In reply to TMart from comment #5) > Crimson 16.6.1 with the fix "Display flickering or corruption may be > experienced when playing videos in a web browser" doesn't solve this issue. I can confirm that as well. There's also a huge reddit thread on the issue. Given that AMD still hasn't fixed it in several consecutive driver releases, and it's causing user burn for us, can we consider blacklisting the driver?

The shutdown hang was bug 1268559, so removing that from this bug's title.

Is this happening on standalone GPU machines (e.g. only AMD GPU) or on Hybrid Graphics systems (AMD + Intel Integrated) or on both? Comment 6 indicates that it's a Hybrid Graphics system (in which case the rendering would go by default through the integrated (= main display), some extensions and plugins do not work well and cause render artifacts due to not recognizing different render targets. Trying to repro this issue on a standalone system and Hybrid Graphics system...

(In reply to Paul Blinzer from comment #10) > Is this happening on standalone GPU machines (e.g. only AMD GPU) or on > Hybrid Graphics systems (AMD + Intel Integrated) or on both? Comment 6 > indicates that it's a Hybrid Graphics system (in which case the rendering > would go by default through the integrated (= main display), some extensions > and plugins do not work well and cause render artifacts due to not > recognizing different render targets. > > Trying to repro this issue on a standalone system and Hybrid Graphics > system... Seems from Gian-Carlo's description and reference a single-GPU case so assume for now that both scenarios are affected.

I've tested this with both single-GPU (Intel iGPU disabled) and hybrid cases (Intel iGPU enabled, but monitor connected via DP on the AMD card, so not the same configuration as you describe) and the effect is the same.

are there any plugins/extensions active ? I assume this is the plain browser with some indeterminate web content. From the log earlier in the thread it may be a TDR (Timeout and Device Reset) situation where the GPU Is reset because it does not respond back in time. After the reset, it would explain the black render as device context would get lost in the process. Any particular web content forcing this repro would be appreciated, some preliminary testing with popular websites didn't trigger anything yet.

(In reply to Paul Blinzer from comment #13) > are there any plugins/extensions active ? I assume this is the plain browser > with some indeterminate web content. All plugins are behind Ask To Activate and none were active. I got some addons (uBlock, RES, etc) but those shouldn't cause our gfx subsystem to start erroring out. > Any particular web content forcing this repro would be appreciated, some > preliminary testing with popular websites didn't trigger anything yet. I've got a bunch of tabs open on my main profile, Twitter, Gmail, Reddit, Bugzilla, Google Sheets, I can try a fresh profile and see if anything seems to trigger it more easily.

It happens on both hybrid systems and standalone systems. It doesn't matter if my Intel iGPU is active or not. It also happens with a completely fresh profile.

For me the issue has been resolved in Crimson Edition 16.6.1 Hotfix

That's interesting. For me it's gotten even worse with Crimson 16.6.1. Seems to be more of a configuration issue, also because it nearly doesn't affect everyone.

Definitely not fixed here either. It keeps getting reported on external sites too, e.g.: https://www.reddit.com/r/Amd/comments/4nlnnl/facebook_firefox_on_1661_driver_issues/ First impression is that for me Google Sheets seems to trigger it more easily.

(In reply to sAnexeh from comment #16) > For me the issue has been resolved in Crimson Edition 16.6.1 Hotfix Sorry, scrap that. Definitely not fixed yet.

I tried replacing the AMD DLLs Firefox uses with ones from older driver versions. But even though Firefox uses them (confirmed by Process Hacker) you get black screens. Very odd. Really out of ideas here and neither Mozilla nor AMD seem to care.

Jeff, do we have a system in house that matches this configuration, so we can try to reproduce?

Paul, if we manage to find a system to reproduce, we may go to AMD in Markham for a day, and try it with debug drivers, unless you have a better suggestion?

Jeff G - this is the kind of system you have, and the types of problems you're getting, right?

(In reply to Milan Sreckovic [:milan] from comment #23) > Jeff G - this is the kind of system you have, and the types of problems > you're getting, right? Looks like it. I have an AMD R9 390 with up-to-date drivers. I believe I posted the exact driver version in one of the other bugs.

(In reply to Milan Sreckovic [:milan] from comment #22) > Paul, if we manage to find a system to reproduce, we may go to AMD in > Markham for a day, and try it with debug drivers, unless you have a better > suggestion? Bringing would be an option in principle, depending on logistics. We are trying to repro on our side too. From the bug description it looks like a TDR (Timeout and Device Reset) scenario, where the OS issued a device reset for some reason, then the device context is destroyed (this is aligned wit the "Detecting device reset" log info) leading to the black screen render. So the problem is not the black screen render per se, but what led to the TDR. If so, one should also see related OS crash minidumps in the Windows directories of the affected systems. Could someone affected take a look at the directory \Windows\minidump that are related to the occurrence and make these available?

(In reply to TMart from comment #20) > I tried replacing the AMD DLLs Firefox uses with ones from older driver > versions. But even though Firefox uses them (confirmed by Process Hacker) > you get black screens. Very odd. Really out of ideas here and neither > Mozilla nor AMD seem to care. Replacing the user mode driver DLL's with older versions is unlikely to work and can cause issues like black screens in itself as the DLLs do not match the rest of the driver files. So that approach does not prove anything. Reproing it seems to be a challenge on our side so far. Any additional info (e.g. minidump data as suggested in my previous response) may be useful to zero in on this issue. AMD very much cares and so does Mozilla, as seen in the frequency of the response, but if one can't repro the problem then it's hard to get rid of it unfortunately :-(

I can reproduce corruption with this PDF: https://www.th-koeln.de/mam/bilder/studium/beratung/lehramt/in_am_berufskolleg.pdf Set zoom to 200% and let FF scroll down slowly via automatic scrolling (pressing middle mouse button). After some pages, everything will turn black. Not just the content, even the whole window of Firefox can also flicker black. Image of the corruption: http://abload.de/img/corruption2uaa3.png Firefox also notices something is wrong: http://abload.de/img/firefox6dyor.png OS is Win 10 x64 (latest final build), FF 47 x64 final and latest Crimson driver 16.6.1. However, it does happen here also with older drivers like 16.4.1. I tested a Nvidia system (where everything is up to date too) and the issue does not occur there. So, there definitely is some kind of problem in conjuction with AMD. Please fix this bug soon. It is really annoying to know that with some complex website content everything can turn black from one second to another. :(

Btw: I don't think any driver is crashing, I'm not seing anything regarding this in the Windows event system and there are no minidumps to be found either.

This bug is really hard to reproduce. The pdf from walmartguy doesn't crash for me, however Youtube does almost instantly...

(In reply to walmartguy from comment #28) > Btw: I don't think any driver is crashing, I'm not seeing anything regarding > this in the Windows event system and there are no minidumps to be found > either. There goes the hypothesis... Though the "device reset" entries in the logs are suspicious. We'll try the PDF and youtube scenarios.

Thanks. I was having the issue with a different PDF as well, Firefox even crashed shortly after the occurrence of the corruption. I reported the issue via Firefox' internal crash reporter and linked to this bug entry. That particular PDF was a simple bus timetable with small fonts btw, thus I had to make use of the zoom feature. Zoom feature really seems important for reproducing this issue.

I think driver definitely doesn't crash or stall. To check this I played a video in another window with MPC HC and checked with both EVR and madVR as video renderers. Both don't show any framedrops or stutter for the video playback while I'm reproducing the corruption issue in Firefox. So it must be some bug in Firefox or the driver that affects only the GPU rendering result for Firefox.

I don't use zoom but I use 150% Windows scaling because of my 3840x2160p resolution, if that matters.

150% Windows scaling changes the corruption behavior for me, then it sometimes occurs by setting the 200% zoom level, but not during automatic scrolling. Could you give 100% Windows scaling + 1080p display resolution a try with the linked PDF?

No corruption with 1080p and 100% scaling in the pdf. However I couldn't reproduce any corruption today. Even Youtube and heavy mouse wheel scrolling doesn't break things right now.

Now I know why I didn't have any corruption: e10s was deactivated by accessability tools. I force enabled it (Aurora 49) and now the corruption is back. So this seems to be an e10s related bug! I can reproduce the same for Firefox 48 Beta.

My corruption definitely isn't related to e10s, my profile is very default-like and I even tried out an entirely new one.

Ok, it's getting weirder... My status from today: Firefox 48 Beta/49 Aurora without e10s: No corruption at all. Firefox 48 Beta/49 Aurora with e10s: -Corruption in the pdf in 1080p 100% scaling. -Corruption in the pdf in 2160p 100% scaling. -NO Corruption in the pdf in 2160p 150% scaling. -BUT: Instant corruption on Youtube in 2160p 150% scaling.

I'm also having corruption with 49 Developer Edition and e10s enabled: http://abload.de/img/corrt6slb.png It just looks a bit different compared to FF 47 without e10s, but it's still there.

Ok, now I was randomly having this issue by opening a channel on YT (FF 47, no e10s): https://www.youtube.com/user/GameStarDE Can't reproduce it realiably with this site though, but it was there. So annoying...

Google Maps tops it all: https://www.google.de/maps/place/Mitte,+Goethestra%C3%9Fe+1,+52064+Aachen/@50.7642339,6.0784194,17z/data=!3m1!4b1!4m5!3m4!1s0x47c09bd0c1cfd8d5:0xd9c63465a20f847e!8m2!3d50.7642339!4d6.0806081 (it should show Goethestraße 1 in Aachen) When I open this site, hide the left menu panel, reopen it and then open the hamburger menu of that panel, I'm getting crazy flicker corruption in FF which is mostly followed by a crash of Firefox or even the whole Windows system (especially when moving the mouse over the panel's links on the left side)! Windows Event Logging mentions crashed AMD driver, but there are no minidumps or a whole kernel memory crash dump to be found. It crashes with a black screen of death/freeze (why does AMD driver not recover with a TDR??). I also tried giving the GPU more voltage, doesn't help at all, seem's clearly to be driver's fault. -> Firefox is almost unusable with Radeon GPU, this should get very high priority for AMD's driver team. Turning off hardware acceleration isn't really an option as a workaround, graphics intense tasks get extremely slow otherwise and some fonts look very aliased. I'm soo annoyed, can't belive it. Used Nvidia GPUs for years without any issue with Firefox, and a few months AMD are already a total desaster...

Tried both Crimson 16.6.1 and 16.4.1, both show the same problem. Demanding games (Ashes of the Singularity DX12 with Async Compute, Hitman 2016, Cryengine games...) totally run without any issues. It simply must be a driver issue.

Tried out really old driver: Catalyst 15.7.1: same problem. So I reverted back to latest 16.6.1 and tried out older Firefox versions instead. And interestingly: Firefox 36 doesn't show any problems with corruption or crashes. It all started with version 37, I can easily crash this Firefox version with the Google Maps method described above. Also according to about:support, FF 36 on the other hand runs without issues. So something really must have been broken beginning with FF 37.

(In reply to walmartguy from comment #43) > Tried out really old driver: Catalyst 15.7.1: same problem. > So I reverted back to latest 16.6.1 and tried out older Firefox versions > instead. And interestingly: Firefox 36 doesn't show any problems with > corruption or crashes. It all started with version 37, I can easily crash > this Firefox version with the Google Maps method described above. > Also according to about:support, FF 36 on the other hand runs without > issues. So something really must have been broken beginning with FF 37. Thank you for testing, this is a very good data point to focus the investigation. Based on the release notes there doesn't seem to be any (major) change in Firefox's Video/graphics pipeline yet there is a major difference in render here apparently. Anyone from Mozilla could provide a quick rundown of what changes have been introduced there or do I need to walk the code?

It should be possible to narrow down the regression range using mozregression. walmartguy can you try this out http://mozilla.github.io/mozregression/?

One significant difference between 36 and 37 is that we started using D3D11 with surface sharing for WebGL. Google Maps uses WebGL so it would make some sense for the difference to be related to that.

(In reply to walmartguy from comment #41) > Google Maps tops it all: > https://www.google.de/maps/place/Mitte,+Goethestra%C3%9Fe+1,+52064+Aachen/ > @50.7642339,6.0784194,17z/data=!3m1!4b1!4m5!3m4!1s0x47c09bd0c1cfd8d5: > 0xd9c63465a20f847e!8m2!3d50.7642339!4d6.0806081 > (it should show Goethestraße 1 in Aachen) > When I open this site, hide the left menu panel, reopen it and then open the > hamburger menu of that panel, I'm getting crazy flicker corruption in FF > which is mostly followed by a crash of Firefox or even the whole Windows > system (especially when moving the mouse over the panel's links on the left > side)! I can reproduce this issue. Given that you encounter it on pre 16.5.x I'm not sure if it's the same issue that was originally reported in this bug. But maybe the new driver made whatever problem happens there worse and more common. I'll bisect.

There's a range between 36 and 37 where the issue on that page is much worse, causing it to go black almost instantly. https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=67c42c076393&tochange=8850aa0f5332 Best bet is: https://bugzilla.mozilla.org/show_bug.cgi?id=1112780 For reasons already described I'm not sure this is the same thing that this bug was originally filed for. Unfortunately regular browsing also doesn't trigger problems reliable enough to make that easy to bisect.

It's probably not the same issue. I've gone back to Crimson 16.4.2 and don't have any problems with Firefox, Google Maps does nothing to my machine. Crimson 16.5 and I'm back to screen corruption all over the place. But no total crashes like for walmartguy.

>It's probably not the same issue. I agree, digging through the linked bugs in 1112780 shows a specific WebGL fix that also fixes Google Maps, so that problem has long since been fixed. The problems I'm not seeing are only related to AMD driver versions, not Firefox versions. I suppose there isn't an amdregression we can use to narrow down the driver change? :-) > If so, one should also see related OS crash minidumps in the Windows > directories of the affected systems. Could someone affected take a look at > the directory \Windows\minidump that are related to the occurrence and make > these available? There are no minidumps produced when this problem occurs. FWIW scrolling through a Google Sheet seems to produce the bug rather rapidly for me.

As a small additional datapoint, whenever (all) content goes black, some movies do not and continue playing. e.g. all my Firefox tabs were black aside from this movie: https://twitter.com/verge/status/747476489139032065

Thanks for the recent detail, a repro has been achieved finally. The root cause for that is now fixed and will be released in an upcoming driver.

Yo you mean the original issue or the WebGL issue?

(In reply to TMart from comment #53) > Yo you mean the original issue or the WebGL issue? Potentially both, though at the moment the Google Maps repro scenario has been confirmed. But the root cause may affect other scenarios too so the original problem may be addressed too. I will be curious to see if the problem is gone for everyone after the next update.

That doesn't sound too reassuring. I hope everything works out.

(In reply to TMart from comment #55) > That doesn't sound too reassuring. I hope everything works out. We will see. At least one of them would be gone for sure now :-D Given the wide range of symptoms that have been reported here, it is hard to confirm conclusively if everything is addressed.

Thx, Paul! Hope it will save us from more testing. Btw. I just realized that one does not seem to be able to hide one's email adress from the tracker entries, I really don't like that. :(

Crimson 16.6.2 seems to be working much better already, I haven't had a single black screen since its installation.

Same here, all fine so far. I'm surprised because the driver is dated the 21st of June.

My issues are gone. I agree that driver's date is a bit weird.

Happy to hear the problem's solved :-) Not sure where you see the 6/21 date, it should list 6/28 (does on my side when downloading it from support.amd.com)...

(In reply to Paul Blinzer from comment #61) > Happy to hear the problem's solved :-) Not sure where you see the 6/21 date, > it should list 6/28 (does on my side when downloading it from > support.amd.com)... about:support Driver Date 6-21-2016 Which seems to query the info in the Windows registry.

What version of the driver does Firefox about:support show once updated to 16.6.2?

(In reply to Milan Sreckovic [:milan] from comment #63) > What version of the driver does Firefox about:support show once updated to > 16.6.2? GPU #1 Active Yes Description AMD Radeon (TM) R9 390 Series Vendor ID 0x1002 Device ID 0x67b1 Driver Version 16.200.1035.0 Driver Date 6-21-2016 Drivers aticfx64 aticfx64 aticfx64 amdxc64 aticfx32 aticfx32 aticfx32 amdxc32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Subsys ID 20151462 RAM 4095

Still no new corruption for me. I think this ticket cen be closed soon, if no one disagrees. :)

I concur.

It seems like people on the old drivers could still experience this problem. Paul which drivers/cards are affected and should we block them?

Since I tested one year old Catalyst 15.7.1, I think this bug had been in the drivers for a very long time (if not forever), it just wasn't triggered before Firefox 37. So, imho the only driver that is not affected by this bug is the new Crimson 16.6.2. However, maybe older GPU archtictures from before GCN never were affected, I don't know.

The problem is not particularly HW specific but related to some somewhat obscure scenario in the driver resource management on Windows(10) that is triggered through recentFirefox builds. There may be a useful workaround for such issues in general that would allow addressing the problem without entirely switching off acceleration for affected drivers and hardware not supported by the recent drivers anymore. Need to look at options.

Thx for the explanation. Paul, can I reach you via your bugtracker email regarding some other driver stories? It's really important to me.

Since this issue seems fixed and some workaround for previous affected driver versions is in the works and can be tracked by a different ticket, can we close this particular bug ? Or is there a reason to keep it open still?

(In reply to Paul Blinzer from comment #71) > Since this issue seems fixed and some workaround for previous affected > driver versions is in the works and can be tracked by a different ticket, > can we close this particular bug ? Or is there a reason to keep it open > still? Is there already another ticket, or do we still need to create one?

Not quite clear why this bug has been reopened is there a similar repro on newer drivers again?

Right - we haven't actually blocked the old drivers, so this bug would get closed once we do that.