Also, you wat?
Ray tracing is like the first type of rendering application most 3D programmers learn to do, I imagine. At least my own game developer program introduced 3D by having us create a simple 3D renderer that used raytracing to render the 3D objects.
Ray tracing isn’t technically that hard to do math-wise – it’s just not efficient at all to do in real-time.
It’s why even DXR / RTX isn’t even “pure” raytracing but uses a lot of ways to essentially “cheat” its way through, such as using a hybrid rendering approach combining rasterization and raytracing, as well as using an extremely limited number of rays and bounces, and then using a denoising algorithm to guess the final result.
Real real-time ray tracing in video games is still like 20-30 years out most likely.
Btw, shouldn’t the direction be reversed? Cameras let light in, after all.
Laserz go brrrrr, bounce, bounce, bounce, bhrrrr, waaam!
… Don’t… open that can of worm…
Must. Resist. So. Tempted. 
Updated MSI Afterburner and RTSS builds, with changelogs.
Just needs to be a little toggle button that says advanced, that makes the crazy stuff appear.
RTSS finally starts reporting VRAM usage properly? Cool!
Properly is subjective… I believe firmly that the correct way to report that is to measure the maximum budget in addition to current utilization. VRAM demand in modern Windows is a function of both of those things, you’re only in problem territory when the usage approaches capacity and the driver varies capacity dynamically.
Until you either make special k work in dx9-Dx12, opengl, and vulkan without any issues, or until you separate the monitoring into its own program that works in all games seamlessly, I will have to continue to recommend that people use rtss instead of special K, in regards to statistics.
When special K works its fantastic, but it’s nowhere near where it needs to be as far as game compatibility in order to be the one stop statistics overlay shop.
It already collects all those statistics in all games, and spits out memory debug info in dxgi_budget.log
Much more sophisticated tool for determining VRAM requirements in a game, frankly having to look at an overlay and read instantaneous values does more harm than good when your goal is to measure VRAM usage.
The actual ceiling for useable budget changes constantly during gameplay, and if the software reporting budget numbers is not also including the maximum useable budget in its instantaneous read of VRAM, then it’s not really providing useful information.
This is why the post-game analysis of VRAM exists in Special K. It tracks events where the maximum budget changes, and then also records overdrafts between budget cap and used budget. That’s the correct way to measure VRAM requirements in modern games.
Requirements are explicitly defined by:
VRAM used >= capacity driver allots
The driver does its own internal maintenance to bring down budget usage for resources that don’t need to be resident, it’s only the resources that cannot be trimmed that ever bring the number above capacity. Happily, those untrimmable resources are the finest measure of required VRAM anyone has conceived to date 
That is not user friendly, and if you want critical mass, or even youtubers to use it, you need user friendly.
I’m not saying the info isn’t great, but digging into a log after exiting the game, is not the right way for your users to get it
Press Ctrl + Shift + M, same info is in the main overlay.
I’ve pointed this stuff out to Unwinder before, he’s only interested in measuring instantaneous VRAM. So we’re back to RTSS irresponsibly reporting information and giving the wrong impression about game reqs.
Thing is, you’re absolutely nuts if you want that on your screen all the time 
That’s why I favor dxgi_budget.log instead.
Also, who says I want a critical mass using this info? I think it would overwhelm most users, and my only responsibility should be to offer more sophisticated logging for the likes of Digital Foundry, GamersNexus, etc. who can responsibly use the information to avoid wild claims that they would otherwise be likely to make if the only measurements they had were the ones produced by RTSS.
And I’ve said, if you can’t make that overlay work in every game, you won’t have anyone use it. You don’t have Dx12 or vulkan working, you don’t have dx10 working. In a way too large amount of games even in dx11, it crashes due to drm or anti-cheat. The # of games that rtss doesn’t work with is probably able to be counted on two hands.
Your way is superior, WHEN it works
You are misunderstanding how most users are using rtss or special K widgets. Most people have a toggle to display or not display.
And I have approached Unwinder on a number of occasions explaining how to improve his data collection, which is the better way to approach this.
SK is built to do a lot more than RTSS is, if I can pass off some of my wisdom to a project that’s much simpler than SK and improve the quality of the experience for non-game modders, that’s great. But I don’t want to dumb SK down just so its statistics reporting on-screen works in APIs SK cannot even modify.
I’ve offered my framerate limiter, my knowledge of stats reporting, etc. It’s up to other projects that specialize in just that stuff to take and do as they please with this to improve the experience for everyone. SK’s primiarly for modifying / reverse engineering games.
You should know by now, that working with Unwinder is impossible. He doesn’t care. He only implemented the per process vram, after years of begging, and he did it in order to try to prove me wrong (at least he made it sound that way)
I understand that you don’t want to split it out, and that’s your perogative, but expecting any one else to do something right, is foolish at best.
I’ve been one of your biggest supporters for many months now, and I’ve done everything in my power to grow your visibility and reach.
You’ve asked us what needs to happen to have a successful patreon, which implies you do in fact want as many people as possible using the software.
If you want more success and visibility such as the Digital Foundry video, you will need to make your program easier to use at some point, and with better % of software that at least part of the features work in.
No one expects you to be able to enable flip model or hdr in every single game, but if you can’t at the very least get an overlay to appear in Dx12 and vulkan, your software will only grow more and more obsolete every year. Games will not be supporting dx11 at all in a few years.
I’m telling you this with the best of intentions, I want to see you succeed and grow. I’m sorry if this isn’t want you want to hear.
1 Like
Incidentally, SK used to use the RTSS feature that allowed it to print statistics directly to it across all APIs, whether they were APIs SK actively modified or just monitored.
Unwinder had some kind of objection to something and requested I stop doing that 
That’s why CEGUI does text-OSD rendering and I use something completely different for the control panel / widgets – had to race to find a solution for clear text rendering when I got that cease and desist.
I do want as many people as possible using it, and where I cannot meet their needs, I want visibility enough to be able to collaborate with other developers and dish out pieces of Special K that are relevant to other projects that may happen to be more compatible.
To me, that’s what you’re supporting if you are a Special K patreon, this is largely a research project where I look for better ways to do things. As soon as enough people realize that and I can get these collabs going successfully, whether the mothership project offers the feature you want or it has been delivered to some other prolific project, supporting SK is what gets it in the hands of as many users as possible.
Currently people think of SK mostly as that project that improves performance in JRPGs It has not gotten adequate exposure as a general-purpose tool. I don’t think it needs to be the easiest to use product, since my goal is to do the crazy frustrating reverse engineering work and then feedback to other common tools in PC gaming.
1 Like
To that end, support for Vulkan and D3D12 via Multiplane Overlays is on a TODO list of mine. It’s an alternative method for drawing overlays that virtually no software uses, that has potential benefits in resolution scaling, HDR and framerate independence.
I expect to go full steam ahead on that in 2021. If it pans out, I’d like to also convince other developers of overlays to use it going forward since HDR is going to be problematic for everyone and I cannot fix everyone’s overlay shaders to work in HDR as I’m only one very overworked person
1 Like