Announcement

Collapse
No announcement yet.

Attention Turns To Open-Source Drivers & Firefox

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    It seems to me that easily end-user runnable test frameworks that make it easy to reproduce bugs as well as capture debugging information on what's going on at the time of the bug - not just for WebGL but for all APIs - would go a LONG ways towards improving the state of open source video drivers.

    I have been absolutely plagued by stability and video corruption issues on a number of different video cars - admittedly mostly ATI / radeon.

    If I had a an easy way to reproduce these issues and report USEFUL information about these issues back to the developers, this would improve the user experience not only for me, but for everyone else using similar hardware.

    Issues I've had:

    1. Lack of developer interest - not sure if this is because of poorly written bug reports (I tend to report my bugs upstream first w/Fedora) or lack of developer resources.
    2. Developers instructing me to compile stuff from source as it might be fixed in the latest before seriously looking at the report - unfortunately this is difficult to do and instructions on how to do so are sparse.

    Comment


    • #17
      Originally posted by jakubo View Post
      how can it b i have lived with linux since 2008 without noticing those troubles at all? no matter if ati, nouveau, intel, fglrx or nvidia.
      This is the nature of many bugs. Very specific circumstances are required to trigger them. Simply changing the order of two operations, or slightly changing the value of a single parameters out of dozens, can result in a slightly different codepath being executed that was never tested before.

      The codepaths in modern, large software stacks are essentially untestable. It's always possible that software which has been working rock solidly for a decade will crash and burn the second someone else comes along and tries something just ever so slightly different than what everyone before them tried.

      does everyone write his own graphics commands or what is webGL now? i mean i'm a stupid physicist, and i really wonder what its all about.
      WebGL is basically just the OpenGL ES API exposed to JavaScript so web pages can access your 3D hardware. There's nothing particularly new to it.

      It's exposing a lot of bugs because browsers need to create multiple contexts; one for each tab/window. Almost every other OpenGL application out there creates a single context and a single window. Turned out the code in Mesa is broken when dealing with multiple contexts in a single process. Mozilla found and exposed that bug in code which nobody had ever really stress-tested before.

      want to turn an object? write matrix!
      want to move object? write matrix!
      Without 3D hardware, that's slow as shit. Take a look at some of the Google Chrome Experiments WebGL pages. There are some impressive demos in there that can't even pull 60 FPS on my NVIDIA GTX 460m with the proprietary drivers. Imagine how completely non-functional those would be in a software implementation.

      (And yes, there are valid industry uses for WebGL, particularly in visualization and gaming.)

      or is it so important to have different approaches for different needs?
      There is no other approach. WebGL is the only standard way to access 3D rendering in a browser.

      Comment


      • #18
        Talking about bugs in DRI2, has this patch been applied yet?

        I noticed that Mesa/DRI2 was crashing, and discovered that the patch in this bug report fixed it.

        Crash in dri2_invalidate_drawable

        Comment


        • #19
          Originally posted by blackshard View Post
          Well, I got fedora 13 and to get firefox 4 I need to upgrade to fedora 14 and enable unstable repos. To obtain new ati oss drivers I need to upgrade:

          1) the ati drivers
          2) the kernel
          3) xorg
          4) all libraries related to xorg

          It would be nice if I could do this without recompiling the whole thing myself, but I can't do on my fedora installation. I would need to upgrade, but I won't because I use my system for WORK and don't want to waste time.
          Well, you seem to waste a lot of time rebuilding stuff, adding unstable repos and foremost "upgrading" your distribution every time you need access to newer packages. Especially since Fedora "doesn't recommend upgrading via the package manager".

          Comment


          • #20
            Sure is nice running a single command and having the entire system updated to bleeding edge. And you know what, I've had far fewer stability issues on Arch than I had with Ubuntu, Fedora, etc.

            Comment


            • #21
              A little fact that a bunch of people in this thread seem to be missing.....
              You don't need a firefox update to take advantage of fixed GL drivers!

              MOZ_GLX_IGNORE_BLACKLIST=true firefox

              Comment


              • #22
                Originally posted by drees View Post
                It seems to me that easily end-user runnable test frameworks that make it easy to reproduce bugs as well as capture debugging information on what's going on at the time of the bug - not just for WebGL but for all APIs - would go a LONG ways towards improving the state of open source video drivers.

                I have been absolutely plagued by stability and video corruption issues on a number of different video cars - admittedly mostly ATI / radeon.

                If I had a an easy way to reproduce these issues and report USEFUL information about these issues back to the developers, this would improve the user experience not only for me, but for everyone else using similar hardware.

                Issues I've had:

                1. Lack of developer interest - not sure if this is because of poorly written bug reports (I tend to report my bugs upstream first w/Fedora) or lack of developer resources.
                2. Developers instructing me to compile stuff from source as it might be fixed in the latest before seriously looking at the report - unfortunately this is difficult to do and instructions on how to do so are sparse.
                Good idea!

                There should be some standardized easy to use tools for automating these tests and capture debug information (eg, backtraces and memory dumps) in a format suitable for a bug report in the event of a failure of a test. That should help in providing good quality bug reports for the developers to find the problem and come up with a fix.

                as for (2), another set of easy to use scripts can be devised to automate the process of getting the latest sources from git from appropriate developer repos and building the new binary packages appropriate for your distro. Such scripts can be called from the test suite scripts as well when checking for solutions for failures.

                Automating bug reporting and solution checking will be a big help for end users and developers alike, so problems can be found and fixed and fixes pushed out to users.

                I believe Microsoft does something like this with Windows via the Error Reporting services by prompting the user to send the crash report to MS and also check if there is a fix available. If a fix or workaround for that particular crash is available it's obtained and installed automatically. Linux can benefit from something like this as well.

                Comment


                • #23
                  Originally posted by DeepDayze View Post
                  as for (2), another set of easy to use scripts can be devised to automate the process of getting the latest sources from git from appropriate developer repos and building the new binary packages appropriate for your distro.
                  Sounds like AUR...

                  Comment


                  • #24
                    Originally posted by DoDoENT View Post
                    Sounds like AUR...
                    Right, if you are using Arch. Most likely the most up to date stuff is in a developers' git/cvs repo not in a distro's repo though.

                    Debian and fedora have their own build systems though so there should be a good way to get the fixed code in a distro-independent way and then leverage the distro's build system to make a package that can be installed.

                    Comment


                    • #25
                      OS Shackles 2.0

                      for most users it's then a matter of waiting for the distribution vendors to pick-up the new packages.
                      Aah the shackles of open source stacks not coming with universal package management and systems for the intelligent selection/replacement/removal of certain systems so open source users will be free to easily install or try out whatever they want.

                      I'd like to see Xorg develop a system which allowed users to install various Xorg binary versions and drivers side-by-side on their system in a cross-distro way, with an easy way to select between versions they want to run/try.

                      They complain about needing test data, but ordinary Linux users can't provide them that if they don't offer an easy way for them to install and run it.

                      Comment


                      • #26
                        Originally posted by kraftman View Post
                        I wonder if they're also looking into problems with Kwin. Problems with Kwin - Kwin fault or bad cooperation; problems with Firefox - 'our' Xorg/Mesa devs fault.
                        It's because the developers of Xorg/mesa use and care about Firefox. They don't necessarily use or care about Kwin.

                        Comment

                        Working...
                        X