Announcement
Collapse
No announcement yet.
RadeonSI Adds Workaround To Deal With Incorrect Rendering In Counter-Strike: GO
Collapse
X
-
Originally posted by abott View PostYou 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.
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.
Leave a comment:
-
Originally posted by schmidtbag View PostHow, 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.
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.
- 1 like
Leave a comment:
-
Originally posted by abott View PostThe patch location confirms you're wrong. Retard.
Leave a comment:
-
Originally posted by abott View PostIf you didn't start with a jackass post, you wouldn't get a jackass response you moron.
Grow up kid.
And the code I write isn't flawless, but it's not flawed from not following spec, that's for certain.
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:
-
Originally posted by schmidtbag View PostCalm 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.
- 1 like
Leave a comment:
-
Originally posted by schmidtbag View PostCalm 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:
-
Originally posted by abott View PostYou 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.
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:
-
Originally posted by schmidtbag View PostThe 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.
- 1 like
Leave a comment:
Leave a comment: