Recent content by SoulWager

AMD being quiet about Pascal doesn't mean anything. Why would they say something if they're screwed?

There were rumors(not particularly reliable rumors) of a large die gaming optimized part(GP102). If that's true there would be zero reason to sell GP100 as a consumer part.

Depends on how fast stuff is moving, how much stuff is moving, how much contrast and visual noise there is, refresh rate, etc. For something like moving a cursor around, I probably couldn't tell the difference between 65 and 70fps on a 60hz display, but I probably could tell the difference...

I'd like you to come up with an example of a biased conclusion. I.e. A situation where AMD had a clearly better product, and PCPer still pushed Nvidia. If you can't do that, then maybe you should question your assumptions. PCPer did the exact same low framerate investigation with the g-sync diy...

Actually, I can come to a conclusion like that. I can make that assessment confidently because I understand how an oscilloscope works, and what the waveform on the scope should look like. If it was working with a 7ms lockout, you'd see a big peak(25ms) followed by a short peak(7ms) when running...

What are you on about? PCPer still uses FCAT for their video card reviews. People were talking a lot about frame pacing because there was a big difference between AMD and Nvidia. Now there isn't, so why would people spend a lot of time talking about it? It doesn't matter where the tools come...

The tearing is pretty obvious in that video, but right now I'm curious about the AMD guy on the beyond3d forums. I looked through the posts in that freesync thread since march, and didn't see any new information about how freesync is implemented, just the blatantly obvious "It should be able to...

How about instead of listening to what AMD has to say, you look at the screen of test equipment hooked up to an actual monitor? Mute the video if you think the reviewers are biased, the correlation between framerate and refresh interval speaks for it's self: https://youtu.be/VkrJU5d2RfA?t=1410

The monitor doesn't change the time it takes to do a refresh, but the driver won't send a new frame for another 18ms after the monitor is done with the repeat. It's definitely a bug, and AMD's behavior here is really suspicious.

AMD claims missing a frame deadline causes a 7ms lockout, PCPer's testing demonstrates a 25ms lockout. This article basically says PCPer is wrong, but without actually testing the issue, just taking AMD's word on it. This is an AMD driver problem that AMD is trying to deny exists.

I am NOT talking about subjective statements, I'm talking about factual representation of behavior below 40fps.

Wait just a minute here. 25ms + 7ms = 32ms. 30fps = 33ms The freesync monitor should be displaying new frames exactly on time here, just like the g-sync monitor. What gives?

PCPer actually tested the behavior, techreport appears to be taking AMD's word for it. It's completely ridiculous to trust AMD's representation here without actually testing it.

Yes, the monitor is supposed to be able to accept a new frame after the 7ms refresh, but that can't happen unless the driver actually sends that next new frame. It's pretty silly that they drew their conclusions without actually testing that. It wouldn't be particularly hard to test either...

Look at the post I was replying to. Running at max refresh to reenable overdrive is kind of incompatible with a framerate cap that keeps you in the VRR range, is it not?