   Is Effects 11 basically abandoned junk?
  The February 2010 SDK has only 3 DX11 samples containing a .fx file: BasicHLSL11, DDSWithoutD3DX11, and SimpleSample11.  All 3 use "technique," i.e. DX9 syntax, not the DX11 "technique11" syntax.  Clearly, these samples were just moved forwards from earlier SDK releases, with no updating of the .fx files.  None of the other DX11 samples use .fx files, they're all straight .hlsl.There is no DX11 equivalent to D3DX10CreateEffectFromFile.  You can't compile everything in a .fx file at once.  Instead, you have to compile each shader individually, providing the name of the shader entrypoint to be compiled.  This is silly.  It means you have to load the .fx file multiple times, just to keep the lazy API happy.  Techniques often have compile semantics in them; this again becomes redundant.  It makes nonsense out of compiling an "effect," not just a shader contained within an effect.  What's the entrypoint for an entire "effect" ?  I say the API has gotten lazy because MS is abandoning Effects.  Effect pools went away, which shows a serious disregard for compile time during development.  Eh, what do they care, too much work for them?  So they release the source and leave developers to fend for themselves.  Manually providing shader entrypoints is just a legacy support workaround.   
  Actually, the manner in which the Effect file is built has changed and the old Compile***FromFile have all been merged into D3DX11CompileFromFile().  This function will compile a shader or an effect - it only depends on the profile being compiled.  The resulting compiled blob can then be handed to the function D3DXCreateEffectFromMemory() to build the ID3DX11Effect object.So, everything still works fine and you don't have to go out of your way and compile each shader individually as you suggest.The Effect src was released so that people can see and learn from it.  Large studios do not use the Effects system (they prefer to use libraries that they can modify) and there are always lots of questions from the community about shader management.  So having the Effects system be source available should help people understand how everything works and possibly even allow them to make improvements, or perhaps only take and use the pieces they need.   ;Quote:Original post by bvaneveryThe February 2010 SDK has only 3 DX11 samples containing a .fx file: BasicHLSL11, DDSWithoutD3DX11, and SimpleSample11.  All 3 use "technique," i.e. DX9 syntax, not the DX11 "technique11" syntax.  Clearly, these samples were just moved forwards from earlier SDK releases, with no updating of the .fx files.  None of the other DX11 samples use .fx files, they're all straight .hlsl.*shrug*Samples for native DX are nowhere near as important as they used to be. It used to be that a lot of beginners and students used native DX, and needed a lot of samples to learn the basics of graphics programming. Today most of those people use XNA, and native DX is mostly the realm of professionals. Those people don't need a million samples...they'll usually just need something that gets them started with the API, and a few that show how to use some of the very advanced features.Quote:Original post by bvaneveryThere is no DX11 equivalent to D3DX10CreateEffectFromFile.  You can't compile everything in a .fx file at once.  Instead, you have to compile each shader individually, providing the name of the shader entrypoint to be compiled.  This is silly.  It means you have to load the .fx file multiple times, just to keep the lazy API happy.  Techniques often have compile semantics in them; this again becomes redundant.  It makes nonsense out of compiling an "effect," not just a shader contained within an effect.  What's the entrypoint for an entire "effect" ?  I say the API has gotten lazy because MS is abandoning Effects.  Effect pools went away, which shows a serious disregard for compile time during development.  Eh, what do they care, too much work for them?  So they release the source and leave developers to fend for themselves.  Manually providing shader entrypoints is just a legacy support workaround.Before you start up the anti-MS battle cry, you might want to actually take a look through the documentation.I really don't know how you came to the conclusion that they "abandoned" effects. With D3D11 you've got the best possible situation: the implementation is available and complete if you want to use it, and you can customize it for your needs since you have the source.  Again, these days DX is mostly the real of professionals who have their own effects/shader management system. It's a lot more useful for these people to have a source library, as opposed to a black box.   ;Quote:Original post by MJPBefore you start up the anti-MS battle cry, you might want to actually take a look through the documentation.What do you think I did for a few weeks before getting disgusted with this?  You find me the definition of an entry point for an "effect," not a shader.  It ain't there dude.  Pretty much every example relies on pFunctionName, an abdication of responsibility to some higher caller.;Quote:Original post by MJPand native DX is mostly the realm of professionals. Those people don't need a million samples...they'll usually just need something that gets them started with the API, and a few that show how to use some of the very advanced features.Have you paid attention to how much horse hockey is necessary just to get a triangle up on the screen nowadays?  The cumbersomeness is amazing.  People have been complaining about this since DX5, and if it ever got better at some point, now it is clearly much worse.;Quote:Original post by bvaneveryQuote:Original post by MJPand native DX is mostly the realm of professionals. Those people don't need a million samples...they'll usually just need something that gets them started with the API, and a few that show how to use some of the very advanced features.Have you paid attention to how much horse hockey is necessary just to get a triangle up on the screen nowadays?  The cumbersomeness is amazing.  People have been complaining about this since DX5, and if it ever got better at some point, now it is clearly much worse.No one ever has to draw just one triangle, so no one really cares how difficult it is to do.   ;Quote:Original post by bvaneveryQuote:Original post by MJPBefore you start up the anti-MS battle cry, you might want to actually take a look through the documentation.What do you think I did for a few weeks before getting disgusted with this?  You find me the definition of an entry point for an "effect," not a shader.  It ain't there dude.  Pretty much every example relies on pFunctionName, an abdication of responsibility to some higher caller.Did you try just passing NULL? I just tried compiling an effect like this, and it worked:D3DX11CompileFromFileW(L"BasicHLSL10.fx", NULL, NULL, NULL, "fx_5_0", 0, 0, NULL, &effectBlob, &compileErrors, NULL);Also with regards to effect pools...I haven't actually used Effects11 so I don't know much about how this works, but the docs seem to suggest that the effect pool functionality was replaced rather than removed.   ;Quote:Original post by bvaneveryQuote:Original post by MJPand native DX is mostly the realm of professionals. Those people don't need a million samples...they'll usually just need something that gets them started with the API, and a few that show how to use some of the very advanced features.Have you paid attention to how much horse hockey is necessary just to get a triangle up on the screen nowadays?  The cumbersomeness is amazing.  People have been complaining about this since DX5, and if it ever got better at some point, now it is clearly much worse.Anybody using D3D11 doesn't care about how easy it is to draw a single triangle. If that's what they cared about, they would be using the old, slow-as-hell OpenGL immediate mode functions.People who use D3D11 care about having an API that maps as close as it possibly can to the underlying hardware, so that they can extract the best performance and make full use of the available features. I've never seen anyone argue that D3D10/D3D11 didn't deliver on that front. If you want a library that makes it easier and quicker to get things on the screen, then there are much better choices available (like XNA).   ;Quote:Original post by MJPDid you try just passing NULL? I just tried compiling an effect like this, and it worked:D3DX11CompileFromFileW(L"BasicHLSL10.fx", NULL, NULL, NULL, "fx_5_0", 0, 0, NULL, &effectBlob, &compileErrors, NULL);I didn't, as it isn't documented.  I thought about it; in fact, I thought about hacking my way through every single possibility until I actually found the answer, based on fxc compiler errors.  Instead, I spent a lot of time Googling for answers, which is frustrating because nobody is talking about this ill-defined notion of an "effect" entrypoint.  I found a lot of circumstantial evidence to make me believe that MS doesn't care much about Effects 11 and that I'm wasting my time trying to learn to use it.  Based on what large studios seem to be doing, I don't think I was wrong.When you say, "it worked," do you mean you actually got an app to compile everything in a .fx file, then make use of the results, successfully rendering pretty things on the screen?  Because "it didn't barf when I fed it that" doesn't mean it worked.  I've found several examples of fxc failing later, without a lot of warning or fanfare about what it didn't like.  That's why I didn't just hack it out, because it looked like there was a good chance it would further waste my time.Quote:  but the docs seem to suggest that the effect pool functionality was replaced rather than removed.Not really, from the standpoint of building an app with lots of effects.[Edited by - bvanevery on March 25, 2010 10:38:58 AM];Quote:Original post by MJPAnybody using D3D11 doesn't care about how easy it is to draw a single triangle. If that's what they cared about, they would be using the old, slow-as-hell OpenGL immediate mode functions.I do care about how much of my time is wasted by shoddy documentation and design.  It's enough to make me evaluate the Mac as a platform.  I've done Windows, I've done Linux.  I don't think much of the engineering on either of them.  I know performance 3D graphics just fine, I've written software rasterization libraries and device drivers.  I wonder if those functions are bad on OpenGL in general, or just bad on Windows, or... maybe you're exaggerating.Quote:If you want a library that makes it easier and quicker to get things on the screen, then there are much better choices available (like XNA).Of course then you're stuck with it, which is what MS wants.   