[Robert Devlin]

FPS jump from 15 to 100. Before that, FPS was 58-60...unsucceseful mod..

[Jonathan Egan]

Hi everyone,

Short question: Does this mod block Steam achievements? I think I should get one yesterday while playing on this mod but I didn't get it (Sneaky tongue). Anyone else noticed it?

Nothing so far blocks Steam Achievements (as in no mod that currently exists). You can even use the console to get some achievements. Specifically all this mod does is change CPU code...you'd have to fool with scripting to be able to stop Steam Achievements.

FPS jump from 15 to 100. Before that, FPS was 58-60...unsucceseful mod..

And how did you test it? Did you disable Vsync? If you were getting 58-60 before it seems like you had Vsync enabled but turned it off to test this mod? You WILL get more fluctuations with Vsync disabled (mod or no mod), although I find it highly unlikely with Vsync enabled you got 60 FPS where with it disabled + this mod you get 15 FPS. To properly test you need to be able to reproduce the same situation, like going up to the top of the steps leading to Dragonsreach and looking down on Whiterun.

[Siobhan Thompson]

Nothing so far blocks Steam Achievements. You can even use the console to get some achievements. Specifically all this mod does is change CPU code...you'd have to fool with scripting to be able to stop Steam Achievements.

OK, thanks.

[Tanya Parra]

I got a 25% improvement in cpu bound areas.

The sad thing is that as an amd user running a Phenom2x4 @3.8G, there are not really much better amd cpus for the game. The FX processors clock worse than a x4 phenom2. I could spend another $200 on a new x4 cpu for .5G or so, which would net only a few fps and is not future proof.

Based on performance of other games, it should be possible for beth to optimize it so its not cpu bound.

I am afriad that bethesda will not release an optimized version; they were probably trying to keep the executable small for compatibility with low memory systems. I am guessing they tried compiler optimization and it pushed the game over their target utilization, thus they turned it off so not to completely alienate millions of users. I dont see it as a failing of their developers, just a business decision.

[Nicole Coucopoulos]

I got a 25% improvement in cpu bound areas.

The sad thing is that as an amd user running a Phenom2x4 @3.8G, there are not really much better amd cpus for the game. The FX processors clock worse than a x4 phenom2. I could spend another $200 on a new x4 cpu for .5G or so, which would net only a few fps and is not future proof.

Based on performance of other games, it should be possible for beth to optimize it so its not cpu bound.

I am afriad that bethesda will not release an optimized version; they were probably trying to keep the executable small for compatibility with low memory systems. I am guessing they tried compiler optimization and it pushed the game over their target utilization, thus they turned it off so not to completely alienate millions of users. I dont see it as a failing of their developers, just a business decision.

It's a shame they don't create alternate options that allow for advanced/normal users. I guess that would take effort.

Personally i'd be pretty happy if they managed to at least fix the microstuttering for anyone with an ati duel gpu, due to the 64htz bug. It could be a long while before the skrim stutter remover get's released.

I would much rather a low framerate than microstutter.

[Brian LeHury]

It's a shame they don't create alternate options that allow for advanced/normal users. I guess that would take effort.

Personally i'd be pretty happy if they managed to at least fix the microstuttering for anyone with an ati duel gpu, due to the 64htz bug. It could be a long while before the skrim stutter remover get's released.

I would much rather a low framerate than microstutter.

I am running 6850x2 in crossfire and have done a bunch of testing since release with multiple ati drivers. I am not aware of any microstutter, the problems are all with cpu bottleneck.

Here is the deal with crossfire. It works as of patch 11.11abc. But because of cpu bottleneck, you will rarely see full 99/99 utilization. When you increase the graphics options, AA and AF, then you start to see positive crossfire scaling, but they also appear to put a greater burden on the cpu, which causes the stuttering. I can turn up all the graphics options in dungeons/caves, its smooth as silk and looks amazing, but as soon as I go outside the game crawls. Its just so stupidly cpu-bound, likely because of shadow rendering, that without an i7, no combination of graphics options will really get you far above "average".

I agree they should release multiple exes, one optimized for those with the specs to handle it. I also wonder if they can offload shadow rendering to the gpu?

[Susan Elizabeth]

Is there any chance or hope of this mod maybe being ported to New Vegas?

The source code is free. I believe that some modders from New Vegas are looking at this thread. If any of them want to modify this to work with New Vegas, they are free to do so.

[Austin England]

I am afriad that bethesda will not release an optimized version; they were probably trying to keep the executable small for compatibility with low memory systems. I am guessing they tried compiler optimization and it pushed the game over their target utilization, thus they turned it off so not to completely alienate millions of users. I dont see it as a failing of their developers, just a business decision.

From my testing TESVAL itself doesn't use up more memory, nor should it. If you mean the executable itself, adding a few extra megabytes is nothing for a game that requires at least 2GB.

I think ianpatt said it best, at one point the engine didn't compile with optimization so they disabled it and eventually that became standard practice. It could have been a Gamebryo part only like 1 guy on their team fully understands. Happens all the time in big projects, it's just usually you go back and fix this in the optimization phase, but then there's that 11.11.11 release date they had to adhere to. Skyrim is really polished in some areas but there's some glaring problems that would be very obvious to even incompetent QA, which makes me think it was rushed through QA approval.

Huh? But nothing gives you permission to have exclusive upload rights!
It's a "totally free anyone can do whatever they want with the code" type of situation, said by Arisu who created it!

That's true of the code, not the actual compiled plugin. Without explicit approval it's always best to err on the side of caution out of respect for the authors. One of the main reasons is that these versions are outside your control and may give your mod a bad name if they uploaded a version with a bug in it (like version 1 of TESVAL).

[Je suis]

I also wonder if they can offload shadow rendering to the gpu?

Why in the world is this still going around? The engine renders shadows with the GPU, period.

[Jose ordaz]

Why in the world is this still going around? The engine renders shadows with the GPU, period.

Because it wasn't the case in older games, since many of them came out at a time when most people didn't HAVE a GPU.

[Nick Jase Mason]

Why in the world is this still going around? The engine renders shadows with the GPU, period.

I actually never looked into why a CPU bottleneck can be substantially reduced by disabling Shadows. It can't be all the Blur Mask, can it? Maybe it's all the Shadow calculations from the Sun and other light sources?

On my machine, disabling Shadows seems to help with CPU-sensitive areas, while my GPU usage nor VRAM are still not maxxed out (well below their limits).

[TWITTER.COM]

This is as request to add to TESVAL from the Nexus forum:

both before and after the mod, I am having trouble where I get major FPS drops to a crawl. It's mostly after going in and out of the Whiterun Jarl's Hall, but also at Labryrinthian and a few other places. Problem is, even if I go to less demanding area, it stays unplayably slow. Restarting the game fixes it, and it's very smooth again. It's almost like a memory leak. Anyone have an idea how I might fix it?

It's not specifically related to the mod, but since the folks around these parts seemed more knowledgeable about the inner workings of the game and optimization, so I thought I might ask!

I

[Marie Maillos]

From my testing TESVAL itself doesn't use up more memory, nor should it. If you mean the executable itself, adding a few extra megabytes is nothing for a game that requires at least 2GB.

I think ianpatt said it best, at one point the engine didn't compile with optimization so they disabled it and eventually that became standard practice. It could have been a Gamebryo part only like 1 guy on their team fully understands. Happens all the time in big projects, it's just usually you go back and fix this in the optimization phase, but then there's that 11.11.11 release date they had to adhere to. Skyrim is really polished in some areas but there's some glaring problems that would be very obvious to even incompetent QA, which makes me think it was rushed through QA approval.

The acceleration layer patch (or equivalent) may only cause the executable to grow by a small amount, but what their compiler produced with optimization checked might have been much larger. My point is that we shouldn't necessarily be cursing the developers; often these things are business decisions dictated by other constraints, not just time.

It may also be possible it did not compile with optimizations as you say, but that should be something they could have debugged in short order. If that is the case, I would have expected it to have been fixed weeks ago.

[Kat Ives]

I have updated the description at Nexus and the OP here to reflect that this version of TESVAL is only maintained on Nexus and currently at silverlock.org, which is the SKSE team's website.

I will get that added to the readme shortly.

[Ana Torrecilla Cabeza]

I actually never looked into why a CPU bottleneck can be substantially reduced by disabling Shadows. It can't be all the Blur Mask, can it? Maybe it's all the Shadow calculations from the Sun and other light sources?

On my machine, disabling Shadows seems to help with CPU-sensitive areas, while my GPU usage nor VRAM are still not maxxed out (well below their limits).

Scene management (CPU-bound) and/or buffer overhead (motherboard bandwidth-bound) probably. And no, that does not mean the shadows are being computed on the CPU. If they were, Skyrim would be a slideshow for everybody on any hardware configuration.

[мistrєss]

I actually never looked into why a CPU bottleneck can be substantially reduced by disabling Shadows. It can't be all the Blur Mask, can it? Maybe it's all the Shadow calculations from the Sun and other light sources?

On my machine, disabling Shadows seems to help with CPU-sensitive areas, while my GPU usage nor VRAM are still not maxxed out (well below their limits).

DirectX10 pdf, but related anyhow

DirectX 10’s Draw overhead
This tool is designed to allow the user to get an idea of instancing performance gains and to do performance anolysis. However, it is likely that there are some common results that are worth discussing. Microsoft has removed a lot of runtime verification of draw calls, and as a result the per-call overhead of Draw*() under DirectX 10 is considerably lower than under previous DirectX versions.
Nevertheless, there are still cases where using instancing will provide a significant performance due to reduction of CPU load. In addition, given the fact that GPU power is increasing faster than CPU power, the benefits of reducing CPU load will grow. The bottom line is that because each Draw call has some overhead, reducing the number of Draw calls will always increase efficiency.

increasing the shadow distance increases the number of draw calls, from experience with the gamebryo sdk, its fairly inefficient with how it batches shadow creation in the first place..... wouldn't be a surprise to me at all if it hasn't improved with skyrims implementation

[Gwen]

Scene management (CPU-bound) and/or buffer overhead (motherboard bandwidth-bound) probably. And no, that does not mean the shadows are being computed on the CPU. If they were, Skyrim would be a slideshow for everybody on any hardware configuration.

I wasn't the one that said Shadows were rendered on the CPU, but they definitely seem more easily CPU-limited than GPU on high-end machines.

I specifically wanted to spark a discussion on whether this is due to something that the community might be able to improve. It does seem to be doing something inefficiently, while increasing max draw distance itself seems pretty efficient.

[Marilú]

I wasn't the one that said Shadows were rendered on the CPU, but they definitely seem more easily CPU-limited than GPU on high-end machines.

I specifically wanted to spark a discussion on whether this is due to something that the community might be able to improve. It does seem to be doing something inefficiently, while increasing max draw distance itself seems pretty efficient.

If it is, fixing it (outside of Bethesda doing it) would involve a massive undertaking to reverse engineer the renderer as was done with Oblivion.

[Alessandra Botham]

The acceleration layer patch (or equivalent) may only cause the executable to grow by a small amount, but what their compiler produced with optimization checked might have been much larger. My point is that we shouldn't necessarily be cursing the developers; often these things are business decisions dictated by other constraints, not just time.

It may also be possible it did not compile with optimizations as you say, but that should be something they could have debugged in short order. If that is the case, I would have expected it to have been fixed weeks ago.

Actually, the exe compiled with optimizations would be smaller in size, it just takes slightly longer to compile. And there shouldn't be any bugs with the low-level optimizations found in TESVAL, apart from the initial spelling mistake by Arisu. There is a reason compilers have optimization flags, use them! Bethesda finally added support for Large Address Aware; Although it took 5 years to get it, there is a slight possibility that they might compile with optimizations down the line.

[He got the]

If they were running out of memory on the build machine, adding optimization flags to that could have pushed them over the edge. The Firefox team hit this wall recently and have been scrambling to get around it through all sorts of shenanigans. The obvious answer of course is to switch to a 64bit machine and a 64bit compiler. They didn't seem to want to do this for some reason. Bethesda might well be in the same boat and reluctant to switch for reasons unknown. Companies do irrational things when faced with the prospect of having to pay for infrastructure upgrades.

[Darlene DIllow]

If they were running out of memory on the build machine, adding optimization flags to that could have pushed them over the edge. The Firefox team hit this wall recently and have been scrambling to get around it through all sorts of shenanigans. The obvious answer of course is to switch to a 64bit machine and a 64bit compiler. They didn't seem to want to do this for some reason. Bethesda might well be in the same boat and reluctant to switch for reasons unknown. Companies do irrational things when faced with the prospect of having to pay for infrastructure upgrades.

They weren't. Firefox has a code base that is probably an order of magnitude larger than Skyrim (really) and also is compiled with PGO (profile guided optimization). Both of these eat memory badly; linking a codebase the size of Skyrim should probably take less than 1GB of memory.

[jessica robson]

There actually isn't a need to update TESVAL or any other SKSE plugin along with our core updates unless you need something we added in a specific version. In this case I added TESVAL v1 to the "do not load" list for plugins; v2 and later will all load properly, so you may want to watch out for that in peoples' skse.log files.

Info for anyone providing help to other players. Thanks again ianpatt for that information.

[Lynette Wilson]

If they were running out of memory on the build machine, adding optimization flags to that could have pushed them over the edge. The Firefox team hit this wall recently and have been scrambling to get around it through all sorts of shenanigans. The obvious answer of course is to switch to a 64bit machine and a 64bit compiler. They didn't seem to want to do this for some reason. Bethesda might well be in the same boat and reluctant to switch for reasons unknown. Companies do irrational things when faced with the prospect of having to pay for infrastructure upgrades.

Is this why Firefox keeps popping up little messages saying it's using too much memory? 300 mb or so? Not like I care with 4 GB and nothing but the browser open.

[Lyndsey Bird]

Didn't work for me, unfortunately But congrats to the programmer and those who got performance improved!

[Stace]

Didn't work for me, unfortunately But congrats to the programmer and those who got performance improved!

Strange, I tried this on four computers and it worked on every one. What are your specs?