Crashing on CreatePixelShader

Might be an issue with the shader level (specified in the technique). The GPU in the low end laptop likely does not support the higher shader levels that the desktop does.

@KonajuGames: I have the same, or a close, issue with some of my code, the point is more likely to be the shader model in use.

4_0_level_9_3 is ok for both MGFX and in SharpDX code
4_0 rise SharpDX exception above (a little different in stack strace) in Shader.DirectX.cs CreatePixelShader method, line 90, which is called from some methods up to LoadContent
3_0 MGFX failed with exception:

error: Processor ‘EffectProcessor’ had unexpected failure!
System.Exception: Invalid profile ‘vs_3_0’. Vertex shader ‘LinShadowMapVertexShader’ must be SM 4.0 level 9.1 or higher!
à TwoMGFX.DirectX11ShaderProfile.ValidateShaderModels(PassInfo pass) dans M:\C#\MonoGame\MonoGame\MonoGame-develop\MonoGame\Tools\2MGFX\ShaderProfile.DirectX.cs:ligne 37
à TwoMGFX.EffectObject.CompileEffect(ShaderInfo shaderInfo, String& errorsAndWarnings) dans M:\C#\MonoGame\MonoGame\MonoGame-develop\MonoGame\Tools\2MGFX\EffectObject.cs:ligne 686
à Microsoft.Xna.Framework.Content.Pipeline.Processors.EffectProcessor.Process(EffectContent input, ContentProcessorContext context) dans M:\C#\MonoGame\MonoGame\MonoGame-develop\MonoGame\MonoGame.Framework.Content.Pipeline\Processors\EffectProcessor.cs:ligne 92
à Microsoft.Xna.Framework.Content.Pipeline.ContentProcessor`2.Microsoft.Xna.Framework.Content.Pipeline.IContentProcessor.Process(Object input, ContentProcessorContext context) dans M:\C#\MonoGame\MonoGame\MonoGame-develop\MonoGame\MonoGame.Framework.Content.Pipeline\ContentProcessor.cs:ligne 60
à MonoGame.Framework.Content.Pipeline.Builder.PipelineManager.ProcessContent(PipelineBuildEvent pipelineEvent) dans M:\C#\MonoGame\MonoGame\MonoGame-develop\MonoGame\MonoGame.Framework.Content.Pipeline\Builder\PipelineManager.cs:ligne 696

Just for a try, using HiDef profile rise another exception (“Could not find a graphics device that supports the HiDef profile”)

Any hints ?

Win 7 64b, winDX platform, Nvidia GeForce GTX 780M and MG dev updated and built today

Maybe graphics drivers? Do you have the latest? Have you been able to run hidef before? This shouln’t be a problem with that GPU

You can’t go below SM4, but 4_0_level9_1 and 4_0_level9_3 emulate lower shader models. Those two should run on reach. 4_0 and up require HiDef

same thing happened to me when i switched to the newest development build.
Just can’t compile FX anymore.
That said I have a pretty powerful computer (but not the newest dx12 gpu, but dx11.2 high end)

It works in an older build for me (specifically I use 3.6.187), so that is a tad annoying.

Maybe we can pinpoint were this stopped working

Thanks for your replies guys.

I don’t have installed the very latest drivers, which anyway are more focused on latest hardware too, it may be related, but most likely not.
I never use HiDef profile before with MonoGame (only with XNA).

shader model numbering is quite messy, no thanks to MS or whoever who’s in charge of this, 3 is > 4_9_x.

It may be something with SharpDX which doesn’t list all hardwares or didn’t recognize some and fallback to a reasonable and safe default which cause the issue (after all, error comes first from SharpDX !)

I remember a bit something about it, and so ?
What was your issue ? HiDef needed and cannot be used ?
I don’t have any error compiling effect with 4 or 5 shader model version, MGFX don’t complain at all, but having a working code is another story.

Yeah, this is a bit confusing, but for MG it’s like:

  • Reach: 4_0_level_9_1 or 4_0_level_9_3
  • HiDef: 4_0 and up (and the 4_0_level_9_* too obviously)

The ‘weird’ numbering is for compatibility. If you’d like to read up there’s some nice information on that here: Direct3D feature levels - Win32 apps | Microsoft Learn

For @kosmonautgames issue, I guess it is this thread which is less than a month old.

I build my own MG libs from repository, not updating submodule and using whatever SharpDX version provided (the one I have date back April 10th, probably the day I get the MG source tree, just run submodules update).

So to don’t forget things: there is HiDef profile which won’t work and pixel shader which also won’t work, both related to SharpDX.
I’ll eventually try with the latest SharpDX source tree.

Thanks @Jjagg for the link.

Update: I’ve tried with MG 3.5.1 release, shader compile without any warning, game run without any exception.
Note that settings HiDef profile looks like to “work” (doing nothing would be more accurate).

Same code, same computer, different MG/SharpDX only.

I have no idea, I tried to ask about it on livestream yesterday, but I guess I phrased it very poorly and they thought it was a shader mgfx problem (as in my shader is broken).

The content pipeline is fine with the shader with the newest build, it just crashes upon loading the effect via content.Load

There was no other solution than to switch back to an older monogame branch. I work on 3.6.187 now and it’s fine, but this is mildly infuriating.

If a solution is found that would be greatly appreciated.

On a related topic: Does monogame even care about reach/HiDef any more? For Dx users it’s probably obsolete.

You mean because pretty much everyone can use HiDef? There is an open issue on expanding this so there’s more capability levels.

It’s unfortunate, maybe by setting up the smallest possible test case and try in various config, it may help to narrow down the issue and identify some useful lead, or even find a fix.
Juts loading an effect straight away from the game template, a simple “do nothing” (pass trough) effect with SM 2, 3, 4 and 5, try it with various hardwares, config and MG/SharpDX version.

That’s disturbing :confused: AFAIK and unless doing something wrong (but how to do it right ? I have no idea either), HiDef does not work because some SharpDX issue (at least with the version used by MG dev), and it looks like I’m forced to use Reach profile, and/so shader model <= 3, or even 2, I’m no 100% sure.
Anyway I don’t think Dx users can just ignore this, ie: my own issue with it.

yes I tried that. A simple ambient shader. Only color. 99.9999% sure there was no shader problem.
Did compile in the content pipeline with mgfx, no errors, no warnings.
Didn’t work.

I don’t remember however what shader model I was using there.

But honestly I don’t want to use anything lower than SM5.0/at least 4.0 anyways. It would be a reason not to upgrade by itself if suddenly dx11 is not supported any more.

All tests run fine and the graphical ones all use a HiDef profile. It’s not like HiDef doesn’t work with latest develop.

All tests ON THE TEST hardware(s) with the TEST softwares; this doesn’t mean at all it WILL WORK 100% sure on ALL hardwares available on Earth. Unit tests are good but far to be enough.

We have one system with issue for sure (mine), @komonautgames: you may try again with more care if you get some spare time.

I think I got a lead: graphicsProfile is called twice, one with Reach and it’s ok, another one wit HiDef and it’s not ok !

Look at the sequence below: putting a single breakpoint in GraphicsDevice.GraphicsProfile method, called from this code:

graphics.PreferredBackBufferWidth = 1024;
graphics.PreferredBackBufferHeight = 768;
graphics.IsFullScreen = false;
graphics.GraphicsProfile = GraphicsProfile.HiDef;

Can you try using this PR ? I changed a bunch of things in GraphicsDeviceManager. Maybe something got fixed :stuck_out_tongue:

You got it ;).

With your PR, I’m able to run the project and SharpDX is happy now (or at least no longer complains :stuck_out_tongue: ), shader works the same way as it did with MG 3.5.1.
@kosmonautgames: you may give it a shot too with your issue as both HiDef works AND there is no longer exception on CreatePixelShader, and the OP may test too.

Good job on this @Jjagg.

To test the PR: inside your MG source tree, do

git fetch origin pull/5139/head:jjaggGDtest


git checkout jjaggGDtest

(jjaggGDtest is an arbitrary name of your choice)

1 Like

Woah, awesome! I did some fixes to be more consistent with XNA, but I didn’t really expect it to fix this. Glad it did :slight_smile:

The OpenGL path still uses the old graphicsDeviceManager so some similar issues may still occur. The plan is to get OpenGL tests running and then have the OpenGL path use the updated GDM.