Emulator

Unable to reproduce, though; I'm on the NTSC version of the game.

Could be caused by two things, realistically. 1: PAL version of the game has a bug the NTSC one doesn't or 2: The HD4600 is doing something wrong.

There were lots of graphics pipeline changes, and I do know that 1288 does introduce other bugs, so, I'll be curious to see what's going on. A fifolog would be very nice.

Thanks for the quick checkup! I wouldn't be surprised if it indeed is related to HD4600 (for which I do have the latest 3/14 drivers, btw). I'll see what I can do about the fifolog, haven't done those before :)

For instructions, please check https://wiki.dolphin-emu.org/index.php?title=FifoPlayer

.. Nevermind, you said OGL works fine. I'm on Linux and hence cannot test D3D :/

I'm not able to reproduce the glitches on my other computer using the same game dumps & Dolphin versions. This other computer has a much older cpu (Q9450@3,2GHz) and Radeon HD 7850. On my newer computer the problem is reproducible with default graphics settings. I originally noticed it with 4.0-1340, and tested every option separately (per pixel lighting, forced filtering, efb to ram, xfb, openmp, fast depth, cache accuracy safe-fast and the rest). Only change from D3D to OGL fixes this.
So it seems to be GPU-related, but I'll get to those fifos later. Based on my 4months ownership of Intel HD, generally DirectX has been more "compatible" than other backends, but not this time.

Managed to record with Fifo player (seemed to give errors and crashes on -1288, worked fine on -1340). Shows the glitches clearly, but textures are not loaded, so objects appear black. Can you make something out of this?

https://dl.dropboxusercontent.com/u/23618751/Dolphin4.0.1288_glitch/NSMB_D3D_IHD4600_D4.0-1340.dff

And again, the glitches are not visible on my other computer when playing the fifolog, so here's a screenshot. Especially the eggs looks like a christmas tree...

https://dl.dropboxusercontent.com/u/23618751/Dolphin4.0.1288_glitch/00000000-2.png

Another user confirmed the same glitches ( https://forums.dolphin-emu.org/Thread-graphic-glitches-on-d3d-backend-on-intel-hd-4600-since-dolphin-version-4-0-1288 ) with Intel HD 4000 (NSMB, PAL version). So far it seems (as to my understanding) that Intel HD GPU/drivers are not able to do something that the recent D3D-backend wants. I'll leave it to developers to decide, if this should be addressed by changing dolphin (since the glitch only appeared after 1288 merge) or if we'll wait for Intel to provide more able drivers.

All I can ask in the meantime is that you keep us updated as new versions of Dolphin and Intel Drivers come out. If there is a new version of Dolphin that we may think affects this issue, we will post in the issue.

Most appreciated!

This suddenly started showing up on my computer: http://imgur.com/vSOIroC . Using an Intel HD 4000. And by "suddenly", I mean I just noticed it today, and it didn't reproduce for me before.

I hate to suggest it, but my best guess is that it's a hardware defect: given that this suddenly started showing up for me, and the glittering effect happens even with a 1-frame FIFO, I can't think of any other explanation.

Ok... so I'm a bit afraid to ask, but is there anything to do about it?

I found out that the issue emerged with commit 4f82d6f7af "PixelShaderGen: Implement tev combiner lerping in a faster way which … ". The code has evolved ever since, but is there any way to implement a bypass for situation if ApiType = D3D AND GPU includes words Intel HD, so that lerping would be done the "old way"? My copy-pasting in the code didn't bring me more than a bunch of crashes.. :)

Until we actually understand what's going on, I don't want to blindly mess with the pixel shader code hoping that we'll get lucky and cover up the driver/hardware bug in some cases. Changing around the code and praying it works isn't a sustainable solution.

I'm going to try and see if I can get any information out of Intel.

That sounds very reasonable, you're right. I don't want that kind of ugly hacks, either.

I kind of got a little carried away when I could with VS2013 build the non-glitcy version and then with one cherry-picked commit (the one mentioned above) I could reproduce the whole issue. I might play a little more with my "fork", but more profound approach (the one that involves Intel) is the only right way.

I edited the code on my fork https://github.com/TurboK234/dolphin_old_tevlerp , the hack bypasses the new lerping formula and uses the old one, if [Video_Hacks] / OldTEVLerpOnD3D = True is set in gameini (ShaderCache needs to be deleted after this option is set to clear the glitches).
This is a questionable fix (fallback to old inaccurate code) to a questionable issue (HW/driver problem), but it works for me. Does this make the issue (questionably) Fixed-In-Branch, I don't know.
I suggest the issue title to be changed to "Texture glitches on Intel HD+D3D backend since 4.0-1288"

(A current build at 4.0-1574 can be found at https://dl.dropboxusercontent.com/u/23618751/Dolphin4.0.1288_glitch/x64_old_tev_lerp_4.0-1574.zip , not planning to publish these in the future so other users need to build their own copies)

EDIT for comment #17, I sorted out the GitHub remote repository, and the link above won't work, instead I have a dolphin -repsitory which is basically the same as master (only outdated), and it has a branch called oldtevlerp , that has a single commit 1d5b15c2b704d901a61a15f5a96907b096304750 that adds the option to use old TEV lerping.
Address is https://github.com/TurboK234/dolphin/tree/oldtevlerp .

Any chance this could survive as a pull request to master..? ;)

If I don't have any better ideas, I'll adapt https://github.com/magumagu/dolphin/commit/b281e722c6b6d266947ef31ef62d2816fb456f86 into a proper patch.

Great news, that looks elegant! I tried to play around with those bit shifts and change those into something else, but I'm not quite there yet with my programming.

Issue 7319 has been merged into this issue.

Judging by comment #21, this very much looks like an issue with the Intel driver. In this case, the issue is on the vendor's side, and should be reported through the proper channels to the driver development team.

NeoBrain: I agree, this should be addressed properly with driver update, it's just that Intel drivers don't update that often ;)
Anyway, has someone reported this to Intel (I haven't, since I don't have the insight of the code of what might be wrong. Although magumagu's #21 fix narrows it down to incorrect handling of some bitwise operations, doesn't it?)? I can fill out a report, there is a support "form" on Intel's webpage, let's see if they have somethin to say...

Isn't it possible to check for the driver's version using the code? this way, we can force the new option only for other drivers. Another solution is simply set the whole thing using an option as in replay #19.

Is this the same glitch as massive texture corruption?
Dell Inspiron 15R SE switchable HD4000 or AMD 7730M.
When using HD4000 D3D11, textures are seriously glitched, especially semitransparent textures.
MKWii title screen covered with grid-like noise on my laptop. Intro movie unaffected. Menus are seriously affected. In game, ground is covered with grid-like pattern of darkened or lightened areas.
MKDD Nintendo logo glitched, menu icons glitched. In game, ground is glitched.
Dolphin 4.0-2246.

That sounds somewhat like the glitches related to this, but I can't relate them to semitransparent objects, nor is the grid-like pattern so pronounced. More like scattered pixels, but only on some objects.
Since the problematic line of code is known, the 100% sure way to check whether your glitches are of same kind is to test it with a build that has the fix implemented (and nothing else).
I would do a 64bit win build for you (if you don't have the tools installed), but I won't be at my desktop pc until next week, sorry.

Okay, here's a link to the latest win x64 version of Dolphin with the D3D TEV fix, the person who posted #28 can check, whether your graphics problems persist. If they do, then they are NOT the same as reported in this issue. This is a portable version (includes portable.txt in the Dolphin.exe folder), so that your old shader cache can not mess this test...

I also included the lighting fix (to remove the "dark goombas" glitch from SMG2, it hasn't been merged, yet, but is suggested in Git. So this is the build I intend to use also for the near future...

https://dl.dropboxusercontent.com/u/23618751/Dolphin4.0.1288_glitch/x64_4.0-2362_fixedD3DTEVandLighting_portable.zip

Ok, thank you, for you clearly have given enough thought for this decision :)

I'll try to keep the bug report open on Intel forums and bump the issue every now and then. Plus I'll make a post on Dolphin forum so people will find the resolution there, also.

Hey, I found out something rather interesting. My intention today was to make a fraps-video of Donkey Kong Country Returns, that would show the glitches at their worst, just to demonstrate. This was not the original title that I used to narrow down the issue (I used NSMB), so I had not checked all the Dolphin options (especially Fast Depth) with this game.
There was another discussion recently on forums about flickering sun in DKCR and the resolution was not to use fast depth in this game, so I changed this to off. Otherwise I intended to do the recording with D3D default settings.

So I almost fell from my chair when I launched DKCR and the glitches were gone. At least the most apparent ones, I did not play long.

So next I tested NSMB, I was kinda hoping that the issue would have been totally fixed here, too, but it wasn't. And I would have seen that in my original tests. The gift ribbons, cannon etc are still affected. BUT the title screen ground gets fixed with fast depth turned off, I honestly don't remember noticing this before.

So this gives me an impression, that the depth of the glitched pixels is somehow involved. Could it by chance be, that the depth receives an invalid value on some objects / depths? Maybe this could still be fixed within Dolphin (without altering The TEV formula) by applying some adjustments to depth calculations..? Just a thought.

I did some more testing with New Super Mario Bros Wii, and saw that Fast Depth really affects how the glitches look. Turning Fast Depth off makes some objects almost glitchless, then again some objects get even more glitches. So this doesn't really fix the issue, but kind of "shifts" it. Still interesting.

I did test this issue with the depth matrix shaders -fix (PR #823, still unmerged atm, but fixes a LOT of depth related issues). This fix only affects EFB to Texture related bugs, and this issue is the same regardless of EFBtoTexture/EFBtoRAM selection.

It's likely whatever driver bug is occurring is related to depth then, maybe? That is merged as of now, so, hopefully things are more playable for you until a permanent solution comes up.

Here are some screenshots:
Fast Depth on: http://imgur.com/7JNfpMw
FD Off: http://imgur.com/9oKxXKy (especially the eggs cleaned up)
FD On: http://imgur.com/FY19nT7
FD Off: http://imgur.com/1K4Ieuf

JMC: Yeah I just noticed that PR #823 got merged, great!
I'm kinda obsessed with this issue, but things are very much playable for me since I'm using the "workaround" in PR #509 and I only have to compile a new version when something big comes up. Like this #823 :)