Emulator

Checking Skip EFB Access didn't work, but incidentally, the OpenGL backend doesn't seem to render the snow either. I think this is just one of those Hyrule Field-type scenarios. Thanks for the response!

Could you please record a single frame fifo log of the snow?

adiffin502: I think OpenGL's lack of line-width is part of the problem. Please record a fifolog for us to examine! Thanks!

Okay, so another strange thing I realized is that the slowdown only seems to occur in the Grand Prixs in which this effect is used! When playing on the same track in, say, Single Race mode, the slowdown is far less pronounced (50-60FPS).

Here's the FIFO log, by the way:
https://docs.google.com/uc?export=download&confirm=Ufws&id=0B3AFeSVGmg9sMGY4TEk0azNybXc

Could I specifically ask for a 5 frame fifolog. Thanks. And do compress again aswell.

I can't download from that link.

Hope this works:
https://drive.google.com/file/d/0B3AFeSVGmg9sdTI5bmJyWWFHM2M/view?usp=sharing

Another strange thing I noticed is that there seems to be more falling snow in the Grand Prix appearances of the snow tracks (when it is snowing) than there is in any other mode O_o

Grand Prix: http://i.imgur.com/3uVgfo2.jpg
All other modes: http://i.imgur.com/VNuo5u3.jpg

Yeah, each snow flake is rendered as a point, seperately. Between them, the uniform are changed. Likely because of a changed transformation matrix...

Can we just make this a duplicate of the flanoir issue then?

This one renderes points, in flanoir are lots of triangles. iirc our d3d code has some special overhead if lots of points or lines are drawn.
Maybe you can recheck if the slowdown is still the same on armada's line-width PR. Please both D3D and OGL.

@Armada: Do you think we should add the culling state in the state manager?

@wickmarkus86

The state managers is already used by the Renderer for the culling state.

Also the previous D3D line-width implementation re-uploaded the uniforms every draw call, not just when they're changed. Thus if the uniform upload process is the bottleneck the line-width branch likely fixes it.

Try this build: http://dl.dolphin-emu.org/prs/pr-1706-dolphin-latest-x64.7z

The slowdown is still the same on the line-width PR (I very much appreciate all of your responses, regardless!), but what's strange is that the snow is now invisible (still being "rendered", but cannot be seen), though the RAIN of all things still works as intended. Maybe the rain works differently?

OpenGL does make the snow visible (it was invisible on OGL outside the LW PR), but is actually about twice as slow (~18FPS compared to ~29FPS on D3D, but that's no surprise seeing as AMD cards aren't nearly as good with OGL as the green team.)

Makes sense. Thanks for the responses. If you have Tales of Symphonia + save files; could you see if the City of Flanoir to see if the snow there gives you a similar slowdown? I have a feeling it will; allowing us to merge those two issues. That way, it would be accepted within that issue instead of questionable as a performance issue here.

We shouldn't merge this with 6587 unless someone actually proves it's the same issue... the fact that both slowdowns involve drawing snow doesn't make them related in any meaningful way.

This one looks like it's not points but 2 triangles together for every snowflake.

I think based on what I remember it's something to do with all the primitives causing pipeline flushes all the time? I think both may be causing the same problem.

This just got a lot worse on OpenGL.
I had 75 FPS on 4.0-4674 but now its a mere 43 on the newly merged 4.0-4699.
That sucks.

Because now OpenGL actually renders the snow properly?

You could do that if you enabled Texture Format Overlay.

And I'm now realizing some of OpenGls advanced options like Wireframe are broken. I'll bisect later.

Nah, we know Wireframe is broken. It'll get fixed soon.

Oh OK well tell whoevers gonna fix it do also fix show statistics when used with that option since I can't remember when that worked.

That never worked with OpenGL's wireframe.

Just did a brief investigation; it looks like the game draws a bunch of points, and changes the point size (bpmem.lineptwidth.pointsize) after every point, forcing a flush each time. Commenting out the line "dirty = true" in GeometryShaderManager::SetLinePtWidthChanged gives approximately a 50% speed increase for the given FIFO.

This is a similar issue to the Flanior slowdown, but the details are different enough that fixing one might not fix the other.

Is there any side effect to the dirty = true change? Or does that make it so it doesn't update it, I guess?

A slowdown that makes the effect work properly would be permissable, though.

Tested this on my NVIDIA card, I get 160 - 250 fps in the snow levels with the snow on in latest master. Flanoir snow is a lot slower than this.

Yeah, commenting out dirty = true breaks the rendering; I just mentioned it to demonstrate the point. Although, thinking about it a bit more, commenting out that line shouldn't have quite that large an impact. I wonder if we can optimize our constant buffer usage somehow.

What we could do is check whether the point size has changed, maybe it sets the field to the same size?

You could queue those pointsize changes in a buffer (iff they really happen consecutively without any other state change) and store them as vertex attributes, couldn't you? That way, the geometry shader can take care of applying the proper size per-vertex dynamically. (I'm usually not too happy about things like this, but here it seems reasonably sensible)

@neobrain: I don't think so. I guess it's more because the game also changes some other constands between each point. Likely the transformation matrix.

Just to be clear, the "crazy slowdown" snow is only present in certain snow levels in the Championship modes. For a good example of one of these instances, go to Custom Series Championship > Point of Impact Grand Prix (restart the GP if you aren't on the first race) and start it. I should probably have been more clear about that :/

Oh, and I've just noticed that "Show EFB Copy Regions" doesn't work on D3D.

This slowdown has been repeatable for me in over two thousand revisions on the Crystal Summit Lake stage set to snow conditions, this one particular track is plagued with huge fps hits and makes the emulation stop and start horribly. You have to go out of your way to select snow conditions so most players would only play this track in the story mode I'd imagine. However it's not the snow that's causing the problems I don't think, since the slowdown only occurs halfway through the track and other parts of the track or other tracks entirely are fine that also have snow effects. So to make it repeatable, go to single race, choose a car, on stage select scroll over to Crystal Summit Lake, scroll down to conditions, select snow, then start the race and race about a minute or two into the track where you reach hairpin downhill turns, immediately after the game will freak out and become virtually unplayable.

This is on linux so using OGL, I can usually get stable framerates everywhere else but recent revisions have caused more issues with this game, I'll make another report for that.

Sorry for the issue resurrection, here. What is actually happening is that there are two separate snow effects in the game - regular snow and "snow showers."

As the name implies, the snow shower is much heavier than the normal snow effect, meaning there are more snowflakes on screen at once, hence the larger slowdown. Rain also has a "shower" counterpart (just called "showers") that is also slower than the normal rain effect.

This AR code will disable all particle-based weather effects for the NTSC version, thus removing the slowdown:

$Disable Rain and Snow
042206E0 00000000

I'm not sure it's the geometry shader that is at fault.

I think dolphin is shoving every single snow particle into a separate draw call, because XFmem has been updated between each snow particle.

If this is the cause of the slow down, it is theoretically possible to fix this slow down by improving dolphin to pack multiple XFmem updates into a single draw call. Would improve performance all over the place.