Help the Graphics team track down an interesting WebRender bug(mozillagfx.wordpress.com)
mozillagfx.wordpress.com
Help the Graphics team track down an interesting WebRender bug
https://mozillagfx.wordpress.com/2020/02/18/challenge-snitch-on-the-glitch-help-the-graphics-team-track-down-an-interesting-webrender-bug/
159 comments
Firefox + WebRender works great in Renderdoc, either capturing the D3D11 commands generated by ANGLE or forcing opengl. The D3D11 commands and shaders correlate pretty well with the GL commands emmitted by WebRender anyway. This tool is absolutely fantastic.
Bugs are usually quickly fixed once someone on the graphics team manages to reproduce them (in a renderdoc capture). Unfortunately nobody has managed to reproduce it yet even though the issue has been in the team's radar for a while.
Bugs are usually quickly fixed once someone on the graphics team manages to reproduce them (in a renderdoc capture). Unfortunately nobody has managed to reproduce it yet even though the issue has been in the team's radar for a while.
The problem with using RenderDoc is that it doesn't capture ANGLE GL function usage, only the underlying D3D calls. So you have to correlate the high-level GL API calls with whatever ANGLE is lowering them to yourself.
It would be nice to have a native D3D11 backend (and D3D12, and Metal, and Vulkan) someday, but that day isn't today. gfx-rs, or wgpu-rs, looks promising as an abstraction layer over all of these APIs.
It would be nice to have a native D3D11 backend (and D3D12, and Metal, and Vulkan) someday, but that day isn't today. gfx-rs, or wgpu-rs, looks promising as an abstraction layer over all of these APIs.
Have you spoken to baldurk about this? Since RenderDoc has GL support and it captures with Detours, in theory with some work it should be able to capture at a level above ANGLE. Not sure if that'd be helpful, but I expect maybe.
Alternatively, could you emit markers at or above the Angle level to provide an easier to understand RenderDoc trace?
Alternatively, could you emit markers at or above the Angle level to provide an easier to understand RenderDoc trace?
You can compile ANGLE with ANGLE_ENABLE_DEBUG_TRACE=1 to get a log of all GLES calls to ANGLE's frontend. It's not the same level of detail as RenderDoc, but it's something.
> it doesn't capture ANGLE GL function usage
It's opensource with MIT license. I wouldn't expect too many issues supporting such use case, given RD's support for normal OS-supplied GLES. I would only expect complications if you'll try capturing both layers at the same time, GLES between your app and angle, and D3D between angle and d3d11.dll.
It's opensource with MIT license. I wouldn't expect too many issues supporting such use case, given RD's support for normal OS-supplied GLES. I would only expect complications if you'll try capturing both layers at the same time, GLES between your app and angle, and D3D between angle and d3d11.dll.
RenderDoc does have some issues tracking calls from ANGLE's backend, but workarounds are documented here for some platforms: https://chromium.googlesource.com/angle/angle/+/master/doc/D...
RENDERDOC_HOOK_EGL=1
[deleted]
Makes sense that a delay sensitive bug is hard to repro too. I have definitely seen similar artifacts throughout the years in Chrome too come and go, seems like it's a common problem in browser D3D implementations.
A few years ago a customer reported a bug in my software which only happened with a specific 3D scene, on specific GPUs (my desktop rendered that scene fine), and was only happening rarely. That’s how I have learned about that GPU synchronization issue across graphics APIs which may cause incomplete renders.
I saw the bug on Ubuntu 18 this morning, on FF 72.0.2 on Nvidia 435.21-0ubuntu0.18.04.2. Can't reproduce. Assumed it was because I have 2x 4K screens plus another 1080p one and I often get weird graphics issues with this setup.
I don't know if it's the same bug but I've certainly seen a similar bug (weird glitches in display that disappear when you scroll) on Fedora with AMD graphics (open source amdgpu driver, X), running Firefox nightly. One screen only..
Yep I think you are right and I think I can replicate and I dont think its just windows:)
https://imgur.com/a/fpnWKhm
Another post mentioned 2x4k screens so I thought creating load might delay expected events so I set up gpu to lowest:
"echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level"
Then opened 2 drm and lot of youtube videos with new tabs and keep refreshing reddit, after a minute or two got black boxes
specs here: https://pastebin.com/JXE2HFUu
EDIT: Nope its not it turns out marvel has black theme, sorry misleading comment, move along
https://imgur.com/a/fpnWKhm
Another post mentioned 2x4k screens so I thought creating load might delay expected events so I set up gpu to lowest:
"echo low > /sys/class/drm/card0/device/power_dpm_force_performance_level"
Then opened 2 drm and lot of youtube videos with new tabs and keep refreshing reddit, after a minute or two got black boxes
specs here: https://pastebin.com/JXE2HFUu
EDIT: Nope its not it turns out marvel has black theme, sorry misleading comment, move along
> I dont think its just windows
I have no idea how exactly FF uses GPU. However, all 3D APIs, especially modern ones, are just ways to access the functionality of underlying GPU hardware, which doesn't depend on the OS.
If FF uses Vulkan, the direct equivalent of that query is probably VkFence, but unlike D3D11 VK has other ways too, subpasses and VkSubpassDependency, and maybe something else I forgot.
I have no idea how exactly FF uses GPU. However, all 3D APIs, especially modern ones, are just ways to access the functionality of underlying GPU hardware, which doesn't depend on the OS.
If FF uses Vulkan, the direct equivalent of that query is probably VkFence, but unlike D3D11 VK has other ways too, subpasses and VkSubpassDependency, and maybe something else I forgot.
This is interesting, as Webrender does not use D3D but OpenGL, so the parts of Firefox that use D3D might interact badly with it.
There is work to port Webrender to gfx-rs which abstracts over Vulkan, Metal and modern DirectX but it seems to only live in the fork of the Hungarian Szeged university for now: https://github.com/szeged/webrender/issues/198
Maybe then Firefox can purely use DirectX?
There is work to port Webrender to gfx-rs which abstracts over Vulkan, Metal and modern DirectX but it seems to only live in the fork of the Hungarian Szeged university for now: https://github.com/szeged/webrender/issues/198
Maybe then Firefox can purely use DirectX?
WebRender is actually using D3D through OpenGL on top of ANGLE
i was also wondering about the gfx-rs port. i've been watching that repo for over a year, and it's quite impossible to tell how far along things actually are today.
Latest efforts were focused on optimizations, and we there are still a few things ([1]) we want to try out. Current status can be found at [2].
- [1] https://github.com/szeged/webrender/issues/212
- [2] https://github.com/szeged/webrender/wiki/Optimization-StatusNote that use of code formatting disables these links on HN, as well as making copy paste of them difficult on mobile. Please avoid using code formatting (space-indented blocks) for non-code.
[1] https://github.com/szeged/webrender/issues/212
[2] https://github.com/szeged/webrender/wiki/Optimization-Status
[1] https://github.com/szeged/webrender/issues/212
[2] https://github.com/szeged/webrender/wiki/Optimization-Status
Didn't know that, thanks for the info!
I used to have this problem __ALL__ the time. So I can give some specs to help anyone, because another comment suggests old hardware.
I __only__ experienced the text tearing. It would basically be a slash through the screen, usually two or three where text would just be displaced. A small scroll would fix it.
This has happened to me in both Manjaro and Ubuntu and on two different computers. The Manjaro is a Inspiron with a 1060Qmax. The Ubuntu has a GTK Titan Black (so old).
I have not experienced these glitches in fairly recent memory. So probably last two versions of FF. These computers are my daily drivers and I keep them fairly up to date.
Usually where these glitches would happen is in long form text articles. I don't recall seeing them on Reddit, but more like NYT. Hope this helps.
I __only__ experienced the text tearing. It would basically be a slash through the screen, usually two or three where text would just be displaced. A small scroll would fix it.
This has happened to me in both Manjaro and Ubuntu and on two different computers. The Manjaro is a Inspiron with a 1060Qmax. The Ubuntu has a GTK Titan Black (so old).
I have not experienced these glitches in fairly recent memory. So probably last two versions of FF. These computers are my daily drivers and I keep them fairly up to date.
Usually where these glitches would happen is in long form text articles. I don't recall seeing them on Reddit, but more like NYT. Hope this helps.
I've been experiencing this too! On only one of my machines. I did a complete Windows reinstall but the problem persisted.
It doesn't happen too often, but iirc I saw a text glitch sometime in the past few days. Moving my mouse over the glitched area or a small scroll solves it for me too.
It doesn't happen too often, but iirc I saw a text glitch sometime in the past few days. Moving my mouse over the glitched area or a small scroll solves it for me too.
Yeah I could get rid of it by scrolling or highlighting the text. I remember looking it up and only find like one small bug report a year ago. But I don't see it anymore. Are you on the newest FF? I don't use nightly and I haven't seen this problem in awhile.
Just checked, I'm on latest regular FF, non-nightly. I don't recall seeing it in the past couple days so maaaaybe it's resolved now? I'll keep an eye out for it in case I see it again.
This bug happens to me somewhat often. In fact it happened to me yesterday. It fixes itself after a couple of seconds. No idea how it happens - I haven't noticed a pattern.
I have a GTX 1070.
I have a GTX 1070.
I too have seen the same issue, and I also have a GTX 1070. I also sometimes see the characters on a page suddenly not render too, or parts of the page go black like the squares they mention. I will keeping an eye out to see if I can get some repro steps.
Could you file a bug for us? https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&comp...
I'm in the same boat with Windows 10 + nvidia 2080ti. Not sure why you want a bug report filled when neither of us have any way of reproducing the issue nor more information about where/when it happens.
Because that's what bug reports are helpful for: organizing and collecting data, which helps with the whole "finding a repro case" and eventually fixing this issue.
Did you think bugs got fixed by mentioning "me too" in a HN comment thread? :)
Did you think bugs got fixed by mentioning "me too" in a HN comment thread? :)
Bugs are useful because it’s not possible to attach the about:support data requested to an HN comment, and because in general bug trackers have the opportunity to offer enhanced integration of support attachments to saved searches and so forth.
You can report what OS/GPU/etc you use, which might help find an important correlation.
I’ve seen this happen too a week ago, GTX 2080. Though it seemed to be some kind of corrupt state, was happening on almost every tab and then a restart fixed it.
This is interesting. I have a 1060Q and used to get the text tearing all the time. In the last (2 or 3?) FF updates I have yet to see it happen. (Currently v73.0)
same, gp107. ubuntu, usually after session resume.
the good: it used to crash my pc when the render process would just hang at 100% after resume, doesnt anymore
the bad: sometimes i have to scroll the page and tab bar after resume now
progress
the good: it used to crash my pc when the render process would just hang at 100% after resume, doesnt anymore
the bad: sometimes i have to scroll the page and tab bar after resume now
progress
I was having a weird WebRender issue last year, except it was causing sudden reboots until the computer stayed powered off long enough for the GPU memory to be cleared. I had enabled WebRender in Linux (it's experimental, I know), and the computer would run fine for weeks at a time, then reboot out of nowhere. It would continue to reboot any time I opened firefox, sometimes a few minutes after starting firefox. The reboots would persist even when I would boot into Windows instead of Linux after one of the forced reboots. Once I narrowed it down to firefox causing the reboots, I started it in safe mode and disabled WebRender, and I haven't had any issues since. This was with a 1050TI graphics card.
That sounds more like a Linux or hardware issue than a webrender one! (Likewise if a website causes Firefox to crash, that's a Firefox issue rather than the website's)
[deleted]
I am fairly certain I’ve seen this bug, but on macOS using a MBP’s integrated graphics. I opted into WebRender a while ago via about:config, so I had figured it was just a random beta issue. Will have to see if I can capture it next time it happens!
Me too. I've seen it happen on more than a couple of occasions while visiting Trello.com and YouTube.com. Firefox isn't my primary browser, partly for this reason.
MBP 2013 with integrated graphics, running Mojave and the latest stable public release of Firefox. I haven't messed with about:config.
MBP 2013 with integrated graphics, running Mojave and the latest stable public release of Firefox. I haven't messed with about:config.
Heh, i was talking about this today. I do three days a month for a client where I use their computers and it's the only time I ever use Windows 10 and the only time I see this. I was asking around about it but no one else was using Firefox. Next time I'm in I'll pay more attention.
If you can grab the info in about:support for that machine and file a bug: https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&comp... that would be helpful!
I get it all the time but I have gfx.webrender.all set to false. gfx.webrender.blob-images, webrender.dcomp-win.enabled, force-angle, picture-caching, triple-buffering.enabled are set to true
However gfx.webrender.enabled is set to false so are they even active?
FF 72.0.2
However gfx.webrender.enabled is set to false so are they even active?
FF 72.0.2
If you got to about:support and check the value of "compositing", you will see if webrender is enabled.
This is so bizarre for me because it's like a flashback. I was seeing errors exactly like this in Firefox years ago, around 4-5 years or more I'd say.
This was on windows 7 64bit with a probably outdated install because my favorite extension for vertical tab tree was always behind on version support.
This error would manifest when I had many tabs open for a long time. I'd often keep sessions of hundreds of tabs open for weeks. The errors would start to appear and gradually get worse until I had to force crash ffx and restart (and recover my tabs!)
Not really actionable or reoro, but anecdotally maybe it helps to hear this isn't strictly new.
This was on windows 7 64bit with a probably outdated install because my favorite extension for vertical tab tree was always behind on version support.
This error would manifest when I had many tabs open for a long time. I'd often keep sessions of hundreds of tabs open for weeks. The errors would start to appear and gradually get worse until I had to force crash ffx and restart (and recover my tabs!)
Not really actionable or reoro, but anecdotally maybe it helps to hear this isn't strictly new.
Looks a lot like older graphics cards over heating. I worked in graphics QA.
I get this frequently. Usually when an update fires and I scroll. Have not yet been able to reproduce reliably. I really doubt it's overheating, since it takes a fraction of a second to happen and it couldn't heat up that quickly.
> it couldn't heat up that quickly
It could, actually, especially if it's not well maintained.
It could, actually, especially if it's not well maintained.
It's a $1200 GPU, I do make time to clean. I'm not saying it's Firefox specifically, perhaps a strange interaction between Firefox and the latest Nvidia drivers. But you're welcome to come check my machine.
I experience this bug and my GPU is definitely not overheating.
I will get the black box bug in outlook, temps are fine.
I've never seen this in Firefox but makes me wonder if its windows related instead of FF/Outlook specific
I've never seen this in Firefox but makes me wonder if its windows related instead of FF/Outlook specific
My Windows 7 + nvidia does these black boxes. The card also can't handle 2 monitors anymore (crashes the system from time to time).
Son of a gun, I have been running into this issue sporadically ever since I built my new PC with a Radeon 5700 XT, and I thought it might have been a bug in the drivers or a bad card, but turns out it's this instead.
For what it's worth, I downgraded my drivers to the last set of drivers from 2019 (19.9.2) and the problem seems to have gone away, but I'm having other issues instead (for instance, half the screen flashes dark when Night Light turns on). Guess it's time to upgrade and file some bugs.
For what it's worth, I downgraded my drivers to the last set of drivers from 2019 (19.9.2) and the problem seems to have gone away, but I'm having other issues instead (for instance, half the screen flashes dark when Night Light turns on). Guess it's time to upgrade and file some bugs.
The state of debugging for graphics code is deplorable. When you run code on a GPU you almost always have a gigantic closed source binary blob underneath you, the graphics driver. Graphics drivers contain complete compilers that munge your code with a focus on speed over correctness. The graphics driver is often years out of date, and you can't even run it yourself to reproduce issues unless you go out and buy the exact hardware that each user has.
The state of the art in debugging GPU issues is to have a closet full of random hardware purchased used on eBay that hopefully contains something close enough to what you need to reproduce the issue you're working on.
Most fancy debugging tools pretend that GPUs don't exist and GPU-focused debuggers are incredibly buggy and feature-poor, not to mention hardware specific in many cases.
The state of the art in debugging GPU issues is to have a closet full of random hardware purchased used on eBay that hopefully contains something close enough to what you need to reproduce the issue you're working on.
Most fancy debugging tools pretend that GPUs don't exist and GPU-focused debuggers are incredibly buggy and feature-poor, not to mention hardware specific in many cases.
As someone who debugs graphics drivers for a living, I assure you it's the same from the other side. Except the gigantic closed source binary blob is some AAA game, benchmark, or a popular game engine demo. Also often the developers are using the API against the specification, but one of the GPU vendors is more lenient than the other so it works for them and they are already shipping the game, too late to fix.
I've never understood the logic behind closed-source drivers. Nobody pays for a driver, people pay for hardware. If you want your hardware to get better support, and therefore become more popular, aren't you incentivized to open-source the drivers?
> Nobody pays for a driver
This is not true. Driver quality is a major differentiating factor between GPUs and absolutely influences purchasing decisions.
GPU makers don't want their competitors to be able to take parts of their drivers and benefit from them. They want to protect trade secrets. They want to avoid revealing how many of their competitors' patents they are violating. They don't own the rights to some third party code or trade secrets that are incorporated in their drivers. They want to avoid revealing future product plans.
Of course it's debatable whether closed source drivers actually help with all of the above reasons, or whether they are good reasons to begin with. But those are the reasons.
This is not true. Driver quality is a major differentiating factor between GPUs and absolutely influences purchasing decisions.
GPU makers don't want their competitors to be able to take parts of their drivers and benefit from them. They want to protect trade secrets. They want to avoid revealing how many of their competitors' patents they are violating. They don't own the rights to some third party code or trade secrets that are incorporated in their drivers. They want to avoid revealing future product plans.
Of course it's debatable whether closed source drivers actually help with all of the above reasons, or whether they are good reasons to begin with. But those are the reasons.
AMD Radeon has made multiple of their performance-enhancing projects of theirs open source only to have nVidia copy and implement their work without reciprocating the favor.
Is it mandatory to reciprocate? If not, then that's a problem of their own making, isn't it?
It's not mandatory, but it sure isn't polite, especially when projects like HairWorks are killing AMD because it's a driver handling issue more than a hardware one.
> aren't you incentivized to open-source the drivers?
No, Not at all.
If we go all the way back to 3Dfx era, we have seen dozens of GPU ( or 2D/3D Graphics Accelerator before the term GPU was coined ) trying to compete in the PC space, 3D Labs, Matrox, PowerVR, Intel I740, S3, ATI, Nvidia, Rendition, ( These are on top of my head, sorry if I missed any of your favourite ). None of them had much problem with designing hardware, their maximum triangles, ( If I remember correctly it was one of the unit used to market graphics card before GFLOPS were used ) were all on par with each other. And some even exceed the current dominant players, but in the end they all failed.
Why? Because they cant get the drivers / software to optimise the use of their Hardware. They do not perform any where close to their potential in Tomb Raider or DOOM. There are huge amount of optimisation built up over the years. As Nvidia once said ( That was even before their huge bet on CUDA ), 60% of their engineers are Software.
To point where the I am going to say, the Driver IS the GPU. You are just paying the hardware to use it.
* And now I feel very old just typing this up. :/
No, Not at all.
If we go all the way back to 3Dfx era, we have seen dozens of GPU ( or 2D/3D Graphics Accelerator before the term GPU was coined ) trying to compete in the PC space, 3D Labs, Matrox, PowerVR, Intel I740, S3, ATI, Nvidia, Rendition, ( These are on top of my head, sorry if I missed any of your favourite ). None of them had much problem with designing hardware, their maximum triangles, ( If I remember correctly it was one of the unit used to market graphics card before GFLOPS were used ) were all on par with each other. And some even exceed the current dominant players, but in the end they all failed.
Why? Because they cant get the drivers / software to optimise the use of their Hardware. They do not perform any where close to their potential in Tomb Raider or DOOM. There are huge amount of optimisation built up over the years. As Nvidia once said ( That was even before their huge bet on CUDA ), 60% of their engineers are Software.
To point where the I am going to say, the Driver IS the GPU. You are just paying the hardware to use it.
* And now I feel very old just typing this up. :/
Don't feel old, I still remember doing Blitter stuff on Amiga, or how sad I was that the newly bought 3Dfx card wasn't compatible with my PCI version and had to exchange it for a Nvidia, hardly did I knew.
Graphics drivers contain competitive optimizations that make a significant difference in the performance of the hardware. Since these optimizations are both costly (in R&D) and allow for the vendors GPU to perform better than a competitors, they do not share these optimizations (that a competitor may or may not use to improve their own driver). And since people pay ultimately for performance, not hardware, the driver is just as important as the silicon.
Your second point is correct, that open source drivers do get better support. AMD has better support on Linux than NVIDIA because it has an officially supported open source driver (AMDGPU). However, the support they receive from open-sourcing the drivers is not always the R&D required to gain a competitive performance advantage, limiting the competitiveness of an open source driver (at least compared to proprietary).
Your second point is correct, that open source drivers do get better support. AMD has better support on Linux than NVIDIA because it has an officially supported open source driver (AMDGPU). However, the support they receive from open-sourcing the drivers is not always the R&D required to gain a competitive performance advantage, limiting the competitiveness of an open source driver (at least compared to proprietary).
They do sketch things, like keep a database of third party shaders that warranted hand optimization by their driver team, and their replacement shaders. I'd be surprised if they could open source such a thing. It's an IP nightmare.
Why would that be sketchy? I'm sure there's lots of bad things in there, but hand-optimizing common third-party code paths doesn't seem like it should be one of them.
Would there be some sort of uproar if people found out that Firefox had special optimizations for common websites, for instance?
Would there be some sort of uproar if people found out that Firefox had special optimizations for common websites, for instance?
If I found out my competitors made sweetheart deals with hardware manufacturers so that their software worked better on their hardware than my software does, I'd be pissed.
> Would there be some sort of uproar if people found out that Firefox had special optimizations for common websites, for instance?
It would ruffle a few feathers if Chrome was optimized for Google properties, but ran their competitors' code with a performance penalty.
One of the issues in United States v Microsoft was that IE used optimized APIs that Microsoft's competitors, like Netscape, didn't have access to.
> Would there be some sort of uproar if people found out that Firefox had special optimizations for common websites, for instance?
It would ruffle a few feathers if Chrome was optimized for Google properties, but ran their competitors' code with a performance penalty.
One of the issues in United States v Microsoft was that IE used optimized APIs that Microsoft's competitors, like Netscape, didn't have access to.
> It would ruffle a few feathers if Chrome was optimized for Google properties, but ran their competitors' code with a performance penalty.
It is: https://9to5google.com/2018/07/25/youtube-chrome-firefox-edg...
It is: https://9to5google.com/2018/07/25/youtube-chrome-firefox-edg...
Thanks for pointing this out. I remember that the EU were conducting antitrust investigations into Google, do any of them pertain to this?
> If I found out my competitors made sweetheart deals with hardware manufacturers so that their software worked better on their hardware than my software does, I'd be pissed.
From 2002: https://www.nvidia.com/object/nv_gdc2k2_02.html
From 2002: https://www.nvidia.com/object/nv_gdc2k2_02.html
>If I found out my competitors made sweetheart deals with hardware manufacturers so that their software worked better on their hardware than my software does, I'd be pissed.
As long as they aren't actively sabotaging your software, I don't see why this is a problem. Adobe is clearly the market leader in photo editing. If adobe pays nvidia to improve performance of photoshop, why is that an issue? They aren't paying nvidia to make gimp worse.
Also "sweetheart deal" is a loaded term. What is your definition of sweetheart deal here?
As long as they aren't actively sabotaging your software, I don't see why this is a problem. Adobe is clearly the market leader in photo editing. If adobe pays nvidia to improve performance of photoshop, why is that an issue? They aren't paying nvidia to make gimp worse.
Also "sweetheart deal" is a loaded term. What is your definition of sweetheart deal here?
All of the examples in there involve the government. What does a "sweetheart deal" between two private companies mean?
> A sweetheart deal or sweetheart contract is a contractual agreement, usually worked out in secret, that greatly benefits some of the parties while inappropriately disadvantaging other parties or the public at large.
> A "sweetheart settlement" may also occur in a legal context. For example, in a class-action lawsuit the attorneys representing a class of plaintiffs may reach an agreement with the defendant in which the primary result is a lucrative fee for the attorneys rather than maximum compensation for the class members.
> Noted instances and allegations
> In a 1947 unionization dispute, San Francisco area grocery store owners claimed that other stores who had "given-in" to union demands had signed sweetheart deals with the unions.
> In a 1949 dispute between the rival American Federation of Labor (AFL) and the Congress of Industrial Organizations (CIO) involving unionization of the laundry industry in Indianapolis, Indiana, a lawyer for the 42 laundry and dry-cleaning plants testified before the National Labor Relations Board that an AFL union contract was not a sweetheart deal between the employers and AFL union officials, as alleged by the CIO.
> A "sweetheart settlement" may also occur in a legal context. For example, in a class-action lawsuit the attorneys representing a class of plaintiffs may reach an agreement with the defendant in which the primary result is a lucrative fee for the attorneys rather than maximum compensation for the class members.
> Noted instances and allegations
> In a 1947 unionization dispute, San Francisco area grocery store owners claimed that other stores who had "given-in" to union demands had signed sweetheart deals with the unions.
> In a 1949 dispute between the rival American Federation of Labor (AFL) and the Congress of Industrial Organizations (CIO) involving unionization of the laundry industry in Indianapolis, Indiana, a lawyer for the 42 laundry and dry-cleaning plants testified before the National Labor Relations Board that an AFL union contract was not a sweetheart deal between the employers and AFL union officials, as alleged by the CIO.
> Would there be some sort of uproar if people found out that Firefox had special optimizations for common websites, for instance?
There was a comment on this site a few days ago that claimed Google was being anti-competitive by hard-coding a list of their web properties into Chrome for it to send diagnostic info when visiting them, so yes, anything where there's a special path for some 1st/3rd parties but not others could be construed in many ways that look bad for the author.
There was a comment on this site a few days ago that claimed Google was being anti-competitive by hard-coding a list of their web properties into Chrome for it to send diagnostic info when visiting them, so yes, anything where there's a special path for some 1st/3rd parties but not others could be construed in many ways that look bad for the author.
Because they use partial verbatim copies of other people's shader code to make that happen.
There is a disincentive: patents/IP as one thing (competitors could deduce how your stuff works from oss drivers), and the other thing is exclusivity with games: especially nvidia has deals with game developers to tweak their games in drivers (!) - things like hand optimized shaders or other rendering settings, that provide superior quality for the gamer, so that gamers prefer to buy nvidia cards over AMD.
With open source drivers, AMD or Intel could just walk in and steal whatever optimizations nvidia has made for a game.
With open source drivers, AMD or Intel could just walk in and steal whatever optimizations nvidia has made for a game.
Everything that is patented is already fully disclosed to the public. It's a requirement of getting a patent. Keeping drivers closed-source is more likely to be due to the presence of trade secrets or that the code includes licensed bits that the manufacturer doesn't have the right to disclose the source code to.
With patents you're afaik only required to describe the process itself - but not the implementation in code, and especially not optimizations fitted to your architecture.
From the USPTO:
> The specification must include a written description of the invention and of the manner and process of making and using it, and is required to be in such full, clear, concise, and exact terms as to enable any person skilled in the technological area to which the invention pertains, or with which it is most nearly connected, to make and use the same.
You don't have to provide code, but you have to teach the reader of your patent how to make and use the invention.
> The specification must include a written description of the invention and of the manner and process of making and using it, and is required to be in such full, clear, concise, and exact terms as to enable any person skilled in the technological area to which the invention pertains, or with which it is most nearly connected, to make and use the same.
You don't have to provide code, but you have to teach the reader of your patent how to make and use the invention.
In practice, patents are written in specialized legalese that is so far away from actual practice that it's difficult to translate. Additionally, due to treble damages for willful infringement, standard industry practice forbids engineers from reading any patents whatsoever.
> standard industry practice forbids engineers from reading any patents whatsoever.
It does? Exactly zero of the companies I've worked for in my career have forbidden me from reading patents.
It does? Exactly zero of the companies I've worked for in my career have forbidden me from reading patents.
The thing is, if you've read a patent, then you (and your employer) now "know of" the patent. If you're later found to infringe the patent, the patent owner can ask for triple damages, since it was wilful infringement. But if you never read it, they can only ask for damages.
Given how many patents are vaguely worded, and how, um, interesting the decisions in patent cases sometimes come out, many companies decide that it isn't worth the risk.
Note well: IANAL. I've just been in companies that had this practice (don't read patents), and I remember why.
Given how many patents are vaguely worded, and how, um, interesting the decisions in patent cases sometimes come out, many companies decide that it isn't worth the risk.
Note well: IANAL. I've just been in companies that had this practice (don't read patents), and I remember why.
Yes, I understand the logic of it, and I have heard of companies that include this requirement. I just doubt that this is anything like a standard industry practice. I've been in the industry for a very long time, and have never once encountered such a restriction, even at very large corporations. I would think if this were close to being a standard practice, I would have encountered it at least once.
> Nobody pays for a driver, people pay for hardware.
You'd think that, but understand that Nvidia's primary advantage is actually in the drivers. In the graphics industry it's known that AMD GPUs often perform better at various tasks as they become highly optimized. However Nvidia GPUs most often benchmark better. As it turns out Nvidia drivers have an enormous set of optimizations it can enable based on heuristics which end up being the key to making up most of the difference.
You'd think that, but understand that Nvidia's primary advantage is actually in the drivers. In the graphics industry it's known that AMD GPUs often perform better at various tasks as they become highly optimized. However Nvidia GPUs most often benchmark better. As it turns out Nvidia drivers have an enormous set of optimizations it can enable based on heuristics which end up being the key to making up most of the difference.
Companies think open-source drivers will reveal "special sauce" implementation details of their graphics hardware to their competitors.
No, they think it will prove their use of bog-standard techniques to people who laid patent minefields, instantly fueling a hundred lawsuits.
The USPTO is terrible at performing prior art searches and terrible at rejecting obvious claims, so there are legions of trolls waiting in the wings to jump on them if they go open source.
The USPTO is terrible at performing prior art searches and terrible at rejecting obvious claims, so there are legions of trolls waiting in the wings to jump on them if they go open source.
One possible factor: graphics drivers are full of app-specific hacks to make benchmarks look good, on the level of "if game == GTAV then run super special fast code instead of whatever the game is telling us to do"
they definitely do that, but they don't keep it secret anymore. they even advertise it as "game ready drivers" from nvidia.
> aren't you incentivized to open-source the drivers?
Opening the source to drivers as they exist now might expose IP that might not be yours to share, IP that you aren't licensed to use or open you up to liability because of how bad your drivers actually are.
That said, I do believe hardware companies should prioritize open-source drivers to benefit themselves and their customers.
Opening the source to drivers as they exist now might expose IP that might not be yours to share, IP that you aren't licensed to use or open you up to liability because of how bad your drivers actually are.
That said, I do believe hardware companies should prioritize open-source drivers to benefit themselves and their customers.
I think the incentive to keep drivers closed is not huge, but the incentive to open source them is effectively nil, especially from the point of view of "management types".
It may on may not end up improving support, but you can't really know that ahead of time. Then you have the risk of people using your code against you, finding vulnerabilities, patent/IP violations or simply reverse-engineering your hardware more easily. You also won't be able to cheat in benchmarks anymore.
There's a cultural aspect to it too. Paying all these engineers to write that code was expensive, and now you want to give it all away for free? Most companies never do that for anything, why would they make an exception?
It's dumb, I too would love for these drivers to become open source, but it doesn't look like it will be happening any time soon.
It may on may not end up improving support, but you can't really know that ahead of time. Then you have the risk of people using your code against you, finding vulnerabilities, patent/IP violations or simply reverse-engineering your hardware more easily. You also won't be able to cheat in benchmarks anymore.
There's a cultural aspect to it too. Paying all these engineers to write that code was expensive, and now you want to give it all away for free? Most companies never do that for anything, why would they make an exception?
It's dumb, I too would love for these drivers to become open source, but it doesn't look like it will be happening any time soon.
> Paying all these engineers to write that code was expensive, and now you want to give it all away for free? Most companies never do that for anything, why would they make an exception?
I'm not saying it doesn't exist, but I've been doing professional software development for more than twenty years and have never encountered this. There's plenty of "we should be paid for our work and innovation" but nothing so reflexive as what you describe here.
I'm not saying it doesn't exist, but I've been doing professional software development for more than twenty years and have never encountered this. There's plenty of "we should be paid for our work and innovation" but nothing so reflexive as what you describe here.
I can understand that AMD and Nvidia have spent a ton of time and money developing their drivers and that ML/GPGPU performance and features are highly competitive.
But embedded GPUs are so fucking obnoxious. There’s about a million of them and they pretty much all have proprietary binary blobs. Pretty worrying for something that could potentially allow any device to be remotely compromised via some malicious webGL or something. Good luck getting the manufacturer to continue supporting it 3 years from now though
But embedded GPUs are so fucking obnoxious. There’s about a million of them and they pretty much all have proprietary binary blobs. Pretty worrying for something that could potentially allow any device to be remotely compromised via some malicious webGL or something. Good luck getting the manufacturer to continue supporting it 3 years from now though
It'd expose trade secrets and give away the details basically giving away any competitive edge.
I guess, it makes it harder to copy the hardware design, which is often off the shelf parts. Once you have the finished design it's relative cheap to mass produce.
It’s not that bad, at least on Windows.
> contain complete compilers that munge your code with a focus on speed over correctness
If you’re a developer, the right tools are available. Set D3D11_CREATE_DEVICE_DEBUG when creating the device, also run debug builds of your HLSL shaders. You’ll get huge amount of error checking and diagnostics this way, including very detailed and specific messages about incorrect API use.
> GPU-focused debuggers are incredibly buggy and feature-poor
I indeed found and reported bugs in GPUs and their drivers (mostly Intel GPUs), but it only was a few times over my career. The majority of times they were bugs in my code, not in GPU drivers, and renderdoc.org helped a lot fixing them.
I generally agree GPU debugging is harder than CPU debugging, but I don’t see how open source driver gonna help. It’s an unfortunate combination of execution model (many thousands hardware threads running your code in parallel), external piece of hardware completely separate and asynchronous from the CPU, and very limited ways to interact or even output data (you can’t printf messages, nor allocate dynamic memory, from GPU code).
> contain complete compilers that munge your code with a focus on speed over correctness
If you’re a developer, the right tools are available. Set D3D11_CREATE_DEVICE_DEBUG when creating the device, also run debug builds of your HLSL shaders. You’ll get huge amount of error checking and diagnostics this way, including very detailed and specific messages about incorrect API use.
> GPU-focused debuggers are incredibly buggy and feature-poor
I indeed found and reported bugs in GPUs and their drivers (mostly Intel GPUs), but it only was a few times over my career. The majority of times they were bugs in my code, not in GPU drivers, and renderdoc.org helped a lot fixing them.
I generally agree GPU debugging is harder than CPU debugging, but I don’t see how open source driver gonna help. It’s an unfortunate combination of execution model (many thousands hardware threads running your code in parallel), external piece of hardware completely separate and asynchronous from the CPU, and very limited ways to interact or even output data (you can’t printf messages, nor allocate dynamic memory, from GPU code).
> The majority of times they were bugs in my code, not in GPU drivers
the Servo/WebRender folks maintain such a list of driver bugs with workarounds, you may find useful:
https://github.com/servo/webrender/wiki/Driver-issues
the Servo/WebRender folks maintain such a list of driver bugs with workarounds, you may find useful:
https://github.com/servo/webrender/wiki/Driver-issues
Vast majority of them aren't for Windows.
The majority of their Windows bugs aren't GPU driver bugs, they are bugs of compatibility layers like Angle and SPIRV-Cross.
IMO when using native stack i.e. D3D11 or 12 and HLSL, the quality of GPU drivers is usually OK on modern Windows.
The majority of their Windows bugs aren't GPU driver bugs, they are bugs of compatibility layers like Angle and SPIRV-Cross.
IMO when using native stack i.e. D3D11 or 12 and HLSL, the quality of GPU drivers is usually OK on modern Windows.
> It’s not that bad, at least on Windows.
Funny you say that. I've seen many developers praising the open source stack under Linux, as you can step right into the driver and fix it yourself, instead of landing in symbols land.
Feral Interactive mentioned it there, for instance: https://www.gamingonlinux.com/articles/interview-with-feral-...
Funny you say that. I've seen many developers praising the open source stack under Linux, as you can step right into the driver and fix it yourself, instead of landing in symbols land.
Feral Interactive mentioned it there, for instance: https://www.gamingonlinux.com/articles/interview-with-feral-...
Note that Feral is comparing it with their macOS experience, not Windows (they do not develop for Windows).
They do not develop on Windows, but presumably they also build and trace on Windows to debug ports. Source: I have worked on multiplatform desktop software.
On the bright side the situation is at least better on Windows - D3D11 and D3D9 both have well-specified behavior and full software rasterizers that can be used to render a reference version of a given frame and then debug it at a pixel level. Wish I had something like that for OpenGL... console game developers have had toys like this for ages.
It's 2020 and I still sometimes swap my renderer from OpenGL to D3D9 when I need to debug a graphics issue because the D3D9 graphics debugging tools are that much better than cutting-edge GL debuggers. (I'd use the D3D11 debugging tools but my 11 backend doesn't work right)
It's 2020 and I still sometimes swap my renderer from OpenGL to D3D9 when I need to debug a graphics issue because the D3D9 graphics debugging tools are that much better than cutting-edge GL debuggers. (I'd use the D3D11 debugging tools but my 11 backend doesn't work right)
OT: This is the first time firefox has warned me about blocking social media trackers. Funny that it happened on one of mozillas own websites.
Yeah that's a wordpress blog quickly put together outside of mozilla's official blogging infrastructure. There was no really good reason to do that, it was just laziness on our end.
But hunting is one of the easy to apply kinds of crowd wisdom. Let's hope Mozilla gets enough data to nail down the root cause.
Black rectangle rings true here. I get it pretty reliably on my phone (preview nightly, Android). If I click a GitHub link and FastHub automatically opens (any GitHub link), when I go back on the phone I see a black rectangle for the whole page.
Pixel 3. Hopefully it's a common codepath.
Pixel 3. Hopefully it's a common codepath.
That sounds like a separate issue. Similar to one I had before on android, but fixed. If you go to settings, about Firefox nightly, what version does it say?
Does the black go away by itself after a couple seconds, or when you scroll, or does it stay forever?
Does the black go away by itself after a couple seconds, or when you scroll, or does it stay forever?
I haven't seen this particular issue but I've seen very similar bugs in my own work where GPU and CPU are not properly sync'd when using glyph or small image cache textures.
E.g. gpu has a frame pending, CPU updates glyph cache, GPU renders pending frame using incorrect cache data.
E.g. gpu has a frame pending, CPU updates glyph cache, GPU renders pending frame using incorrect cache data.
I had a similar issue in Chrome and a regular crash-to-desktop in the main game I was playing at the time (Divinity 2) on Windows 10 with a GTX 970. I also had major problems with YouTube.
My fix was to turn off all the Dynamic Clock and GPU Boost stuff in the NVIDIA control panel.
My fix was to turn off all the Dynamic Clock and GPU Boost stuff in the NVIDIA control panel.
Hmm... This looks identical to something that occurred on Ubuntu 14.04 when I came out of suspend, except it happened to all gtk apps. Switching to another virtual terminal then back to 7 seemed to reinitialize something and fix it.
Even nowadays, on rare occasion on Ubuntu 18.04, something like this occurs during startup of Android Studio. I don't recall seeing it on Firefox since at least 16.04 though.
Even nowadays, on rare occasion on Ubuntu 18.04, something like this occurs during startup of Android Studio. I don't recall seeing it on Firefox since at least 16.04 though.
I wonder if Mozilla has enough resources to test on Windows machines, or if it's just bad luck with hardware configuration, or something else entirely. I reported an unrelated bug in Nightly where I couldn't use smartcard authentication and since it only reproed on Windows we had a back and forth exchanging screenshots and logs until the root cause was narrowed down.
I had issues like this in May of last year in Chrome on Windows 10. Oddly it happened most frequently on TravisCI's website, and I thought at first that it was a TravisCI issue!
It turned out a Windows updated over night and replaced my AMD driver with some old compatibility driver. After updating back to the most recent driver the issue went away.
It turned out a Windows updated over night and replaced my AMD driver with some old compatibility driver. After updating back to the most recent driver the issue went away.
A classical race condiction double bug. What happens here is there is a a special case of the data. So other routine of processing the data is used.
It causes a race condition that results in proving incomplete data to the next step of the process.
There is surely logic to prevent it from happening. But the data initially used the bad routine so no one expects the race condition to occur.
And at the end we have a bad routine that processes data badly because data are bad and incomplete. This routine does not expect how it receives the data and in what time.
In a result rendering breaks, but for the logic of the code it seems fine. So the error block is displayed. Gor GPU rendering it is a black box.
What is interesting if you did deep enought to find all these 3 issues that cause it each of them separately is fine. It is what they do together causes the issue.
Very nasty thing to track. And also fix. Because on a high level there is little to about it. And a workaround is mostly to detect the situation and process data slightly different way to avoid the issue, or to just do processing two times in a rather hacky way.
It causes a race condition that results in proving incomplete data to the next step of the process.
There is surely logic to prevent it from happening. But the data initially used the bad routine so no one expects the race condition to occur.
And at the end we have a bad routine that processes data badly because data are bad and incomplete. This routine does not expect how it receives the data and in what time.
In a result rendering breaks, but for the logic of the code it seems fine. So the error block is displayed. Gor GPU rendering it is a black box.
What is interesting if you did deep enought to find all these 3 issues that cause it each of them separately is fine. It is what they do together causes the issue.
Very nasty thing to track. And also fix. Because on a high level there is little to about it. And a workaround is mostly to detect the situation and process data slightly different way to avoid the issue, or to just do processing two times in a rather hacky way.
I have seen very similar bugs (the same text glitches for sure) under Linux (Radeon RX580, open source drivers) in the past. I had put it down to open source drive stack bugs, but maybe it was actually a Firefox bug?
I’ll try and take a screenshot next time it happens & report it.
I’ll try and take a screenshot next time it happens & report it.
I have seen this in the past (I use FF-nightly on MacOS) but subsequent updates seemed to have fixed it. Although maybe some other factor affecting the frequency. Will keep an eye out.
Why the Nightly version only, I'm curious?
The Firefox developers only patch security vulnerabilities in standard Firefox releases. All minor bug fixes and new features go into Nightly and only after a few months into stock Firefox.
Presumably there are other graphics bugs that have been fixed in Firefox Nightly but still exist in the Beta or Stable Release channels. Best to debug and reproduce the bug in the code closest to version the Mozilla engineers are using.
> Update: we have created the channel #gfx-wr-glitch on Matrix
Funnily, this alias is incomplete and therefore not enough to join. A room ID might have been enough, but just an alias without a server part is worthless, a bit like someone left an e-mail adress as gfx-wr-glitch@, without specifying the rest.
I've successfully joined trough #gfx-wr-glitch:mozilla.org, (roomid is !qaAtjMWizEgMcVSbNH:mozilla.org, no alias on matrix.org) and told them so.
Edit: they fixed it. I wonder how often that happens with those new to Matrix?
Funnily, this alias is incomplete and therefore not enough to join. A room ID might have been enough, but just an alias without a server part is worthless, a bit like someone left an e-mail adress as gfx-wr-glitch@, without specifying the rest.
I've successfully joined trough #gfx-wr-glitch:mozilla.org, (roomid is !qaAtjMWizEgMcVSbNH:mozilla.org, no alias on matrix.org) and told them so.
Edit: they fixed it. I wonder how often that happens with those new to Matrix?
I don't think that's a "new to Matrix" thing.
They run their own server, just like they ran their own IRC server before, and at first didn't really consider the need to make that explicit. I doubt there was any misunderstanding of the tech, or that the channel names are per-server.
They run their own server, just like they ran their own IRC server before, and at first didn't really consider the need to make that explicit. I doubt there was any misunderstanding of the tech, or that the channel names are per-server.
> Without having a way to reliably reproduce this bug, we are at a loss on how to solve it.
I wish non-technical people understood this.
I wish non-technical people understood this.
[deleted]
I'm curious, why does a team working for Mozilla need to host their blog as a free account on wordpress.com? They really don't have a unified blog system to provide a more official feeling to all their different departments?
Or is this just an unofficial blog from people that is unrelated to Mozilla?
Or is this just an unofficial blog from people that is unrelated to Mozilla?
In this respect (and probably others) Mozilla is more like a ragtag army of rebels than a uniform-wearing platoon of soldiers. The blog is hosted on WordPress because the person who started it found it most convenient, and it never got migrated anywhere else. We also have hundreds of different github organizations and repos (despite also hosting our own "official" mercurial server), use lots of different communication tools, spread documentation over multiple wikis and bug trackers, etc.
But yes, this is an "official" blog from Mozilla employees on the graphics team, of which I too am a member.
But yes, this is an "official" blog from Mozilla employees on the graphics team, of which I too am a member.
That's both strange, very confusing, and amazing at the same time :-)
It surprised me that Mozilla is able to simultaneously have things like the MDN, basically the best resource for HTML and Web APIs, but then other references or publications scattered around everywhere.
It surprised me that Mozilla is able to simultaneously have things like the MDN, basically the best resource for HTML and Web APIs, but then other references or publications scattered around everywhere.
This reminds me of the comments section or sometimes a mailing list for a particular bug in a driver or a low-level component and most of all the replies were from 'users' who weren't helping to solving the actual problem in the discussion. Then one day an unknown contributor not only was able to reproduce the bug but also sent an actual fix and ended up gaining commit access to the project after staying there for a while.
Whenever I hear the 'mythical legend of the 10X rockstar developer', I think of them. Mozilla needs more of those developers to reproduce AND send patches to interesting bugs like this. Not the whining copypasta forum-posting 'users' calling themselves 'developers' who take many open-source projects like this for granted and don't appreciate the time spent by the maintainers of the project.
Nowadays they're usually doing this on a developer social network through every maintainers nightmare 'The Issues Tab'.
Whenever I hear the 'mythical legend of the 10X rockstar developer', I think of them. Mozilla needs more of those developers to reproduce AND send patches to interesting bugs like this. Not the whining copypasta forum-posting 'users' calling themselves 'developers' who take many open-source projects like this for granted and don't appreciate the time spent by the maintainers of the project.
Nowadays they're usually doing this on a developer social network through every maintainers nightmare 'The Issues Tab'.
"Given enough eyeballs, all bugs are shallow."
https://en.wikipedia.org/wiki/Linus%27s_law
https://en.wikipedia.org/wiki/Linus%27s_law
Hah! As an open source maintainer for a mildly popular repo a big chunk of my time is spent weeding out people filing issues and opening PRs for trivial changes (like adding a line to the README file) just so they can claim to be a "contributor". Meanwhile there are a ton of issues that are ready to code with a full explanation and are even marked as such ("good first issue" or whatever else) that stay untouched.
Regardless of community engagement, perceived interest, Github stars or whatever else — finding a developer willing to spend actual time and effort to make a project better is very, very rare.
Regardless of community engagement, perceived interest, Github stars or whatever else — finding a developer willing to spend actual time and effort to make a project better is very, very rare.
I've made a bunch of one line PRs that I'm worried are perceived like this, but they're always a fix for something that cost me a lot of time. Examples include adding quotes around CSS base64 URLs (our base64 string included //) and changing the case of some headers in documentation (headers were downcased upstream and the example in the doc failed silently). Are these the kind of PRs you don't like?
Not at all. It isn't the size of the PR that matters, but I generally want contributors to:
- Discuss their changes beforehand (usually on the issue page)
- Use patterns and practices that the rest of the codebase follows
- Listen to comments and feedback
- Write tests
While the work is "free", it should still be treated professionally.
- Discuss their changes beforehand (usually on the issue page)
- Use patterns and practices that the rest of the codebase follows
- Listen to comments and feedback
- Write tests
While the work is "free", it should still be treated professionally.
> - Discuss their changes beforehand (usually on the issue page)
Interesting. When I last looked at contributing to open source, some general advice was to offer up code even if its likely the wrong approach. The idea being that maintainers are busy, and there's lots of people that drag on their time without ever contributing anything. Showing you're actually willing to put in time and effort will make the maintainer more likely to guide you in the correct direction because you've already shown you're willing to spend time on the issue.
Interesting. When I last looked at contributing to open source, some general advice was to offer up code even if its likely the wrong approach. The idea being that maintainers are busy, and there's lots of people that drag on their time without ever contributing anything. Showing you're actually willing to put in time and effort will make the maintainer more likely to guide you in the correct direction because you've already shown you're willing to spend time on the issue.
I feel the same way. Although I have only been starting to contribute recently, I thought that by offering code first via pull request I wouldn't be perceived as a whiner in the issues section.
This is definitely true. I'm not a fan of Issues discussion with random people who are not known to be reliable contributors. Talk is cheap, show me the code.
Yeah, people who drive-by PRs to unnecessarily fix a minuscule style or dependency-version issue is one of my pet peeves. I don't spend a lot of time on it, but this kind of cynical game playing sucks. These kinds of contributions produce a net loss for OSS, not a net win.
I submit lots of one-word grammar and writing fixes.
For me it's not about the reputation boost - it's that I see a minor flaw and can offer a quick fix, rather than just moving on and pretending I didn't see it.
It's like picking up litter when you see it on the street.
That said, I'm not a maintainer of any open source project with actual users, so I'm not familiar with the kind of gamesmanship you undoubtedly see once a project is popular.
For me it's not about the reputation boost - it's that I see a minor flaw and can offer a quick fix, rather than just moving on and pretending I didn't see it.
It's like picking up litter when you see it on the street.
That said, I'm not a maintainer of any open source project with actual users, so I'm not familiar with the kind of gamesmanship you undoubtedly see once a project is popular.
Which repo, out of interest?
Given this is the mozillagfx blog, one would hope the "gfx" displayed on the blog were a little better: I can't make out the graphical glitches described in those tiny low-resolution screenshots.
you dont see the glitches in this image https://mozillagfx.files.wordpress.com/2020/02/screen-shot-g...
Not in the thumbnail versions displayed in the post, no. And you can't even click on them to view the full version. I had to right-click, View Image, then strip a resizing parameter off of the URL to get the full thing.
Is that not how reddit looks?
Interesting to note that even the address bar appears to be affected. Several characters are missing from the URL in that screenshot.
Yeah, when I had it happen to me, it happens to the entire Firefox instance, settings page, url bar, tab names, context menu (right click menu) and everything in between.
Much of Firefox's UI is HTML and can be affected by bugs like this. But it is very interesting to see that bug appears to affect both the app UI and web page at the same time.
Where did you get that image? The ones I see in the blogpost are much lower-res, and clicking them doesn't give me a larger version?
is this a real request for help, or a marketing-look-at-our-blog thing?
If you can suggest a better way to get word about a tricky bug out to people who don't usually look at Mozilla's bug tracker I'm sure they'd be happy to hear it :)
This is a real request for help!
When in doubt assume the best of people, not the worst by default.
This very much sound like a similar issue Linux users are facing from more than a year and it's still not resolved? https://askubuntu.com/questions/1088324/firefox-becoming-unr...
I don't think so - in the Linux bug, Firefox becomes unresponsive, whereas in the bug in the article, Firefox runs as normal, and the blanks can be cleared by scrolling or mousing over.
I see a somewhat similar bug on my Linux box, where windows flicker between black and normal, and the flickering stops if i focus on the window. I don't think it's specific to Firefox, though - i believe i've seen all sorts of apps do it. I do have an nvidia graphics card, FWIW.
I see a somewhat similar bug on my Linux box, where windows flicker between black and normal, and the flickering stops if i focus on the window. I don't think it's specific to Firefox, though - i believe i've seen all sorts of apps do it. I do have an nvidia graphics card, FWIW.
As someone who experience this very often I can't say that Firefox is becoming unresponsive, you can still scroll up/down, change tabs, etc.. but the all pages are glitched similar (even worse) to the screenshots.
Can you file a bug? https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&comp...
You should ask the people having the issue to switch graphics cards, PSU and RAM since this >90% smells like a memory/power issue. I think you've just gotten unlucky and collected a few similar reports of people having memory corruptions. I am guessing you cache renderings and that is why the issue sticks around until you re-render.
If you want to reproduce it yourselves then perhaps try pointing a hairdryer from a distance at the various components until they start to create trouble, or alternatively just overclock them towards the breaking points.
If you want to reproduce it yourselves then perhaps try pointing a hairdryer from a distance at the various components until they start to create trouble, or alternatively just overclock them towards the breaking points.
Why the downvotes? Anything contradicting this which you might want to share in text instead?
Based on the symptoms and difficulties to reproduce, I think what you see on the screenshots are incomplete renders. The FF code submitted some draw calls to GPU, and copied the render target texture without waiting for draw calls to complete. A good way to fix is use a D3D11_QUERY_EVENT query to wait for completion of rendering.
If all GPU access happens through D3D11 this shouldn’t happen i.e. the API guarantees to wait for the completion of previously submitted draw calls. It may happen in practice when mixing multiple GPU APIs, e.g. when using DXGI surface sharing to pass textures between D3D11 and DX9. Also, it may happen when using D3D from multiple threads. Easy way to detect the latter, set D3D11_CREATE_DEVICE_DEBUG flag when creating the device, and read warnings in debug output of the process.
Another possibility is just bugs in rendering code. To troubleshoot them, https://renderdoc.org/ is awesome. Unfortunately, if the FF doesn’t use D3D to present, only rendering to textures, some changes to FF’s source code is required to capture frames with RD, see this page for details: https://renderdoc.org/docs/in_application_api.html