Announcement

Collapse
No announcement yet.

Attention Turns To Open-Source Drivers & Firefox

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

  • allquixotic
    replied
    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.

    Leave a comment:


  • Yfrwlf
    replied
    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.

    Leave a comment:


  • DeepDayze
    replied
    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.

    Leave a comment:


  • DoDoENT
    replied
    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...

    Leave a comment:


  • DeepDayze
    replied
    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.

    Leave a comment:


  • droidhacker
    replied
    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

    Leave a comment:


  • jeremyj
    replied
    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.

    Leave a comment:


  • Azpegath
    replied
    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".

    Leave a comment:


  • chrisr
    replied
    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

    Leave a comment:


  • elanthis
    replied
    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.

    Leave a comment:

Working...
X