Announcement

Collapse
No announcement yet.

Major Performance Breakthrough Discovered For Intel's Mesa Driver

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

  • saski
    replied
    Any Updates on if and when these patches will be made public?

    Leave a comment:


  • smitty3268
    replied
    Originally posted by curaga View Post
    You really smell of hypocrisy. Show me one bug where *you* bisected something that took that long, on your workstation that you need daily to be stable for *actual work*.
    Sure. I'll do that as soon as you show me where I've been complaining about a bug in open source code that hasn't been fixed for months.

    It'd be different if this was proprietary software. You can't fix that.

    Leave a comment:


  • darkbasic
    replied
    Originally posted by curaga View Post
    You really smell of hypocrisy. Show me one bug where *you* bisected something that took that long, on your workstation that you need daily to be stable for *actual work*.
    +1

    Also, you don't have any guarantee that some other bug steps in and ruins your 3-months bisection because you marked a good commit as bad.

    Leave a comment:


  • curaga
    replied
    Originally posted by smitty3268 View Post
    So it happens in 3 days or less each time?

    Great, that means you just have to run each version for a solid week. That's plenty of extra time, just to make sure.

    After 3 months, you could have run run 13 steps in the bisection process. It'd probably be done, and fixed by now.

    Instead, we are approximately nowhere. I bet in another 3 months, there are still people on here complaining about how it hasn't been fixed yet.

    And that's fair enough, you can complain all you like. But if you really want it fixed, now is the time to start helping find the cause.
    You really smell of hypocrisy. Show me one bug where *you* bisected something that took that long, on your workstation that you need daily to be stable for *actual work*.

    Leave a comment:


  • tomtomme
    replied
    Originally posted by FutureSuture View Post
    If you think that is dysfunctional, then head on over to AMD. How many drivers for Linux will AMD be maintaining? 1? 2? 3? I am not even sure now. I wish Valve would spend its own money to hire a third party developer to aid AMD. Competition is good but AMD needs some help in that department.

    they are maintaining 1 and for some cases 2 linux drivers:

    R9 285 (GCN 1.2) and newer: new combined oss+fglrx driver only
    HD7000 to R9 (GCN 1.0+1.1): oss radeonsi + fglrx
    HD5000 to HD6000 (VLIW): oss r600 + fglrx (but I bet it will be legacy soon)
    HD2000 to HD4000 (VLIW): oss r600 only (fglrx is not maintained anymore = legacy)
    even older cards: oss r300

    Leave a comment:


  • smitty3268
    replied
    Originally posted by TheAaronB123 View Post
    Hard to bisect something that takes 5 minutes to 3 days to arise. I am the OP to bug 61844 for Mesa's RadeonSI random crashes. Why don't you go ahead and bisect it for me over an entire month, even if it is because of a single commit? Be reminded it's not known clearly to be Mesa, or a kernel update that shows it, or anything else. I personally think it's DMA issues of some sort, but I'm also not a kernel/AMD dev. Still, besides this bug for me, RadeonSI is fine on my R9 270X. But this bug is bad. And it's been a problem for about 3 months now. Other than that, most games run fine with everything on Ultra: Civ 5, The Witcher, tons of valve games. Rust has major engine issues with it being a POS, but most games programmed well are just fine.
    So it happens in 3 days or less each time?

    Great, that means you just have to run each version for a solid week. That's plenty of extra time, just to make sure.

    After 3 months, you could have run run 13 steps in the bisection process. It'd probably be done, and fixed by now.

    Instead, we are approximately nowhere. I bet in another 3 months, there are still people on here complaining about how it hasn't been fixed yet.

    And that's fair enough, you can complain all you like. But if you really want it fixed, now is the time to start helping find the cause.

    Leave a comment:


  • theghost
    replied
    I can confirm radeonsi (with Radeon R9 270x) is pretty much broken atm.
    Also it's pretty easy to trigger hangs / crasher but I don't mind to create bug reports. I'm just a user.

    Just run Gnome-Shell and start a CS:GO game. Full xorg crash at nearly every game. Happens since Xorg 1.16 and Mesa 10.3.x.

    Also run XCom, just play a few minutes. Screen turns black, game comes back and full xorg crash. Also happens since Xorg 1.16 and Mesa 10.3.x.

    Afaik the second crasher is pretty much known, I think it's this guy: https://www.libreoffice.org/bugzilla...g.cgi?id=80419

    I don't understand why the bug reporter should bisect the problem. There are maintainers who are paid for this and who know their driver.

    Leave a comment:


  • V10lator
    replied
    Originally posted by grndzro View Post
    AMD has only FGLRX now. They are merging FGLRX and opensource into a binary driver. Firepro driver are pretty much FGLRX.
    Not correct:
    On the kernel side AMD has FGLRX, FGLRX Legacy and radeon for now.
    On the userspace side AMD has FGLRX, FGLRX Legacy, r600g and radeonSI for now.
    Planned is for kernel side a new driver called amdgpu and for userspace side a new FGLRX (will we have FGLRX Legacy v1, FGLRX Legacy v2 and FGLRX then?) and a new OS driver.

    That will be: On kernel space 4 drivers, on userspace side 5 drivers. I'm not sure if we should talk about 5 or 4 drivers now, are we talking about user- or kernelspace?

    Leave a comment:


  • darkbasic
    replied
    Originally posted by chrisb View Post
    Are you talking about two separate issues here?
    I can not say for sure but yes, I bet they are two separate issues.

    Sorry for not answering to all the other points but you should deal with a completely unusable system for six months which such an impossible bug to track down to able to understand how frustrating it can be.
    I have not that much time to spend on my PC and usually when I use it it's because I have to work with it. It means I need stable drivers (Catalyst), so no way to do a 3 month bisect.

    Leave a comment:


  • chrisb
    replied
    Originally posted by TheAaronB123 View Post
    You are wrong, that is all I'm going to leave it at. I've bisected a few issues for them related to my card, I'm not exactly new, I even had a automated script to forward and set up bisects and installs. When a commit isn't bad because of one commit specifically in one software but maybe multiple like the kernel and such, you can't bisect from one and get a good result, period. YOu narrow it down by jumping versions, but you also have to know which mesa is good. If the kernel is bad, they're ALL bad! Does it make sense, yet?
    What you describe is the problem of sub-project dependencies in testing. It is possible to bisect these kind of problems, but you have to plan a bit more since git doesn't do it automatically (even for git submodules). Remember that git-bisect is just a tool that does a checkout by choosing the midpoint between known good and known bad. You can do this yourself by creating a test matrix of your sub-projects, and if versions of one depend on particular versions of another, then you can incorporate this in to your git bisect script by having the script check out and build the particular dependency of the project for each tested version.

    Obviously this is a bit harder to set up than a git-bisect on a single project, but once you get the idea it isn't that difficult. At the end of the testing, there will be some set of commits, across one or more projects, where the good/bad transition happened (considering all projects as a whole).

    I'm not saying that you should do this testing, or remarking on whether or not AMD should be doing more testing, merely pointing out that testing across multiple projects with version dependencies is possible.

    Leave a comment:

Working...
X