Announcement

Collapse
No announcement yet.

RadeonSI Adds Workaround To Deal With Incorrect Rendering In Counter-Strike: GO

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

  • abott
    replied
    You're a fucking moron. Keep it up, stupid.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by abott View Post
    You don't even know why the driver shows shit when an app starts.You're out of your league on this, by a lot if you don't even know WHY that happens.
    What evidence do you have of this? What suggests you know better? How is any of this relevant? Stick to the subject at hand - if you're so confident you're right, you'd stop trying to distract from all the points you can't refute. Or, do you want to meet me on the playground at 3:00 where we can settle this the way that suits you best?
    The workaround is a hack to make the driver clear all surfaces to a "default" state which is wrong. Day 1 of malloc/buffer programming teaches you not to use non-int'd memory from a fresh buffer. The app doesn't follow that. The driver is never supposed to return int'd memory, it says in spec because they didn't change anything relating to core OGL.
    And yet, most drivers do do that. Y'know why? Because everyone make mistakes, and contrary to what you want to believe, it doesn't hurt anything in any meaningful way. Some people (like CS:GO devs) never catch those mistakes. Why is that so hard to wrap your head around?
    It is an application flaw, you stupid moron. It's slow to clear any buffer when not needed, which it now does because of the flag to enable that "fix" in csgo. The driver isn't at fault because they changed nothing about OGL implementation in the patch, only enabling a pre-programmed workaround.
    I never said the application wasn't flawed, dipshit. But you're so caught up in your own ego and came in so hot that you can't back out of this now. I said companies like Valve aren't solely responsible for this. That being said, neither is AMD. Game devs are responsible to fix this, but they're not, as you so eloquently put it, "1000% at fault"... that phrasing still makes me laugh.

    If you understood how things actually worked, you'd realize that you don't have to clear the buffer every damn frame. As far as I'm concerned, doing that every frame wouldn't just cause performance issues, it'd make the game largely unplayable. So, whatever performance loss you're expecting of this (assuming both the driver and the game conformed to standards) is negligible. You're whining about a worst-case scenario of a few microseconds lost every once in a while, or perhaps 1FPS. Is that really a hill you want to die on?
    Stop replying, you idiot.
    Seeing as your logic is crumbling and you keep resorting to amusing hissy-fits, I'm going to gladly keep going. Go ahead kid, bring it on.

    Leave a comment:


  • abott
    replied
    Originally posted by schmidtbag View Post
    How, exactly? Do you not know what a workaround is? Do you even know what my argument is, because I'm quite sure you don't.
    You don't even know why the driver shows shit when an app starts.You're out of your league on this, by a lot if you don't even know WHY that happens.


    The workaround is a hack to make the driver clear all surfaces to a "default" state which is wrong. Day 1 of malloc/buffer programming teaches you not to use non-int'd memory from a fresh buffer. The app doesn't follow that. The driver is never supposed to return int'd memory, it says in spec because they didn't change anything relating to core OGL.


    It is an application flaw, you stupid moron. It's slow to clear any buffer when not needed, which it now does because of the flag to enable that "fix" in csgo. The driver isn't at fault because they changed nothing about OGL implementation in the patch, only enabling a pre-programmed workaround.


    Stop replying, you idiot. You're making yourself seem dumber and dumber each time.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by abott View Post
    The patch location confirms you're wrong. Retard.
    How, exactly? Do you not know what a workaround is? Do you even know what my argument is, because I'm quite sure you don't.

    Leave a comment:


  • abott
    replied
    The patch location confirms you're wrong. Retard.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by abott View Post
    If you didn't start with a jackass post, you wouldn't get a jackass response you moron.
    Clearly you don't know what you're talking about, seeing as people here either seem to agree with me or just simply misunderstood what I meant. Maybe lay off the roids and perhaps you'd realize that you're taking things a bit too far. You haven't actually come up with a response to any of my points regarding the article, so if you're so confident I'm wrong, you should be able to actually prove your point rather than get in a hissy-fit.
    Grow up kid.
    And the code I write isn't flawless, but it's not flawed from not following spec, that's for certain.
    Which spec? Cite your sources. If you're suggesting "everyone does it so it's implied", well ostensibly, the same argument applies to the GPU drivers that zero-out VRAM by default. radeonsi is the odd one out in this case, just as these handful of games are.

    And just to clarify, I'm not ridiculing the radeonsi devs. Seeing as most games don't have this problem, I don't blame them for not knowing about it. As I said before, it's really not a big deal.

    Leave a comment:


  • abott
    replied
    Originally posted by schmidtbag View Post
    Calm your tits.

    As the article stated, the assumed default behavior of the driver is to zero out VRAM allocations. While you could argue it's lazy code for Valve to not do this themselves, the reason that behavior is the default is to make up for user errors. Seeing as Valve isn't the only one who does this, it's no wonder why the Windows drivers defaulted this behavior. So no, they're not "1000% at fault", they're just mildly at fault and arguably negligent. Seriously, it's not a big deal, especially not as big as you're making it out to be. Meanwhile, let's see your flawless code, eh?

    Next time, don't user juvenile exaggerations to make your point - it doesn't make you more right, you just look like a jackass.
    If you didn't start with a jackass post, you wouldn't get a jackass response you moron. And the code I write isn't flawless, but it's not flawed from not following spec, that's for certain.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by schmidtbag View Post
    Calm your tits.

    As the article stated, the assumed default behavior of the driver is to zero out VRAM allocations. While you could argue it's lazy code for Valve to not do this themselves, the reason that behavior is the default is to make up for user errors. Seeing as Valve isn't the only one who does this, it's no wonder why the Windows drivers defaulted this behavior. So no, they're not "1000% at fault", they're just mildly at fault and arguably negligent. Seriously, it's not a big deal, especially not as big as you're making it out to be. Meanwhile, let's see your flawless code, eh?

    Next time, don't user juvenile exaggerations to make your point - it doesn't make you more right, you just look like a jackass.
    Code:
    fn main() {
        println!("It's in Rust because people here hate it!");
    }

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by abott View Post
    You are an idiot and didn't listen to the issue. The game uses uninitialized buffers for data. The driver, in 0 cases for any reason, should be initing them to any value. That is 100% the apps responsibility to clear any buffer allocated if needed or not. The game chooses to or not to, and it's the only thing that should decide, as some buffers it isn't needed to init on allocation. It's rare because any developer worth their pay knows better than to use a buffer that isn't initialized. It means the game it's self is 1000% at fault. Period. No questions. It's actual moronic talk to suggest anything otherwise.
    Calm your tits.

    As the article stated, the assumed default behavior of the driver is to zero out VRAM allocations. While you could argue it's lazy code for Valve to not do this themselves, the reason that behavior is the default is to make up for user errors. Seeing as Valve isn't the only one who does this, it's no wonder why the Windows drivers defaulted this behavior. So no, they're not "1000% at fault", they're just mildly at fault and arguably negligent. Seriously, it's not a big deal, especially not as big as you're making it out to be. Meanwhile, let's see your flawless code, eh?

    Next time, don't user juvenile exaggerations to make your point - it doesn't make you more right, you just look like a jackass.

    Leave a comment:


  • abott
    replied
    Originally posted by schmidtbag View Post
    The workaround is game specific but the actual fix isn't (at least not to my understanding). The article mentions other games that can be affected by it and I'm sure there are more. The thing is, most games were coded in a manner where this problem wasn't exploited/noticeable. It's generally a non-issue, but just because it's rare, that doesn't necessarily mean the game itself is at fault.
    You are an idiot and didn't listen to the issue. The game uses uninitialized buffers for data. The driver, in 0 cases for any reason, should be initing them to any value. That is 100% the apps responsibility to clear any buffer allocated if needed or not. The game chooses to or not to, and it's the only thing that should decide, as some buffers it isn't needed to init on allocation. It's rare because any developer worth their pay knows better than to use a buffer that isn't initialized. It means the game it's self is 1000% at fault. Period. No questions. It's actual moronic talk to suggest anything otherwise.

    Leave a comment:

Working...
X