I'll do it for future builds.
If these builds give different functional results than vanilla VC++ builds for anybody, I certainly want to hear about it. As of now though, I am unable to verify any reports of this.
(09-17-2011, 06:05 PM)FilthyMonkey Wrote: [ -> ]I just tested it myself. I get identical graphics in all of the builds. I took screenshots of the actual window, so the version numbers could be seen. All are using the dx9 graphics plugin. The putting grid problem can be seen in all of them.
my new-shadercache-uids build
ExtremeDude2's build labeled as new-shadercache-uids
my 3.0-96 build
ExtremeDude2's build labeled as 3.0-95
I say 'labeled as' because ExtremeDude2 builds seem to show strange revision numbers in the window title. His 3.0-95 build has 3.0-112 as the title.
An interesting note is the window title of the screenshot in the report you linked, purposing that the screenshot is showing bugs from the new-shadercache-uid branch. It is a screenshot from ExtremeDude2's 3.0-95 head build, as I don't think anything else shows up as 3.0-112 in the window title. This is the screenshot linked in that report. It is possible that the person making it linked the wrong screenshot.
The person mentioned that the problems went away when he switched to ExtremeDude2's branch build. I do not think that his 'branch build' (taken from this post ) is actually a branch build. It doesn't have 'new-shadercache-uids' in the window title as mine does, and if you check the about screen, it says that it is from "branch: master". Mine says "branch: new-shadercache-uids". That isn't something that I filled in myself.
Thanks for taking the time to look into this. But I guess I wasn't that clear. The main issue was with DX11 it looks like. Try that one (if you can) and you should see the same results as I did - a difference between your builds and Extreme's/others.
The screenshot WAS from Extremedude showing the proper gfx. In all of your builds the putting grid is 100% missing and the [A] [B] buttons do not show on the shot meter.
I just tried it with DX11, and I do indeed get the same problems you described. I am going to remove all of my builds temporarily while I test the different optimization options to see what the cause is. I suspect inter-procedural optimization or intel optimized headers. Provided I find the culprit, I will upload a new set of builds.
(09-18-2011, 04:17 AM)FilthyMonkey Wrote: [ -> ]I just tried it with DX11, and I do indeed get the same problems you described. I am going to remove all of my builds temporarily while I test the different optimization options to see what the cause is. I suspect inter-procedural optimization or intel optimized headers. Provided I find the culprit, I will upload a new set of builds.
I'm glad you're seeing the same thing. Good luck and thanks for your contributions!
Initial testing isn't looking good. I've turned off every optimization option, to the point where I have a 36 megabyte executable, and I still have the problem.
I tested Lectrode's r7676, and his ICC builds have the same problem. At least I know that it isn't just my builds.
More testing.
A debug build with VC++ has the same problem as the ICC builds. It throws the same panic alerts and has the same graphical glitches. I dumped the shader code in the working case as well as the nonworking case, and they are identical. The value coming back from PD3DX11CompileFromMemory in the erroneous case is E_FAIL, which I suppose shouldn't surprise anybody.
Edit: The problem is with the pDefines argument.
Okay. Problem solved, I believe.
http://code.google.com/p/dolphin-emu/source/browse/Source/Plugins/Plugin_VideoDX11/Src/LineGeometryShader.cpp#196
By the time time D3DX11CompileFromMemory is called, the pointer returned by numTexCoordsStr.str().c_str() on the above line is toast. It is a dangerous practice to be passing that into a function, and will have unpredictable results.
Fix is to copy the string out into a new variable and pass that into D3D::CompileAndCreateGeometryShader. It looks like the same practice happens in a couple of other places too, like
here.
I've confirmed that copying it to a new variable fixes the problem in the VC++ debug build. I presume it will fix the problem in ICC as well, though I have yet to test it.
Adding that copy does fix the problem in ICC as well. Here is an SS3 ICC build with my patch applied.
http://www.mediafire.com/?71bhk2kb9qqh5uk
If you are still out there Legend80, please let me know if this build works for you as well. I no longer see the problem in mario golf.
It probably should be fixed in the actual codebase. It isn't an ICC specific problem. It just so happened that the 'undefined behavior' exhibited itself in ICC, as well as the VC++ debug build.
If you have a patch, please share it.
(09-18-2011, 04:23 AM)Legend80 Wrote: [ -> ] (09-18-2011, 04:17 AM)FilthyMonkey Wrote: [ -> ]I just tried it with DX11, and I do indeed get the same problems you described. I am going to remove all of my builds temporarily while I test the different optimization options to see what the cause is. I suspect inter-procedural optimization or intel optimized headers. Provided I find the culprit, I will upload a new set of builds.
I'm glad you're seeing the same thing. Good luck and thanks for your contributions!
Looks all good here too! Nice work!