Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Jul 2008
Offline Last Active Jun 30 2014 08:25 PM

#5007949 [SharpDX] Questions about DirectX11

Posted by xoofx on 06 December 2012 - 06:55 PM

Also, in case you want to access by the name of the variable in your shader and get the slot associated with this name, you can query these slots using D3DReflect (via the ID3D11ShaderReflection or ShaderReflection in SharpDX), and shaderReflection.GetResourceBindingDesc() methods. This is used by legacy D3DX Effect systems. Note that the reflection API is not certified API on the Windows Store App so if you really need this access at runtime, you will have to store them along the bytecode of your shader.

While it can be practical to hardcode these specifics register slots in the original shader, you have less opportunity after this to combine includes/shaders (as you could have some conflicts: for example if you declare in a include TextureA.h a TextureA mapped to register t0, and in TextureB.h a TextureB mapped to register t0, the HLSL compiler will failed at compiling a shader that is using these two variables for the same stage). Though assigning a specific register can be handy in some cases where you want a specific resources to be accessible at a specific slot (for example a particular constant buffer used across all your shaders... etc.), while the others variable could be assigned automatically to the available registers.

#5005919 DeviceContext->map() using system and GPU memory?

Posted by xoofx on 30 November 2012 - 08:23 PM

@MJP, indeed, unlike D3D9, D3D11 doesn't make any strict assumption about the location of the memory, but a MAP_WRITE_DISCARD needs anyway to allocate a new buffer, even if it is in a shared memory, and the previous memory of the buffer will be released at a later "flush" when It is no longer being used by the GPU. So in practice, when using MAP_WRITE_DISCARD, you are more likely to at *least* double the memory usage (exactly like a double buffering).

#5005903 DeviceContext->map() using system and GPU memory?

Posted by xoofx on 30 November 2012 - 06:54 PM

After the end of these lines, the amount of memory the program uses is greater than before. If it does in fact keep the vertices stored in main RAM and video RAM, what is the reason for this?

This is expected, as MAP_WRITE_DISCARD requires behind the scene to invalidate the previous buffer, and It has no other ways than to allocate a new buffer on the CPU side before sending it later to a new buffer on the GPU (and releasing the previous GPU buffer). So basically, at the time you use MAP_WRITE_DISCARD, It is not writing directly to the GPU memory, but delaying the writing (and storing this in a temp buffer).

#5000732 Windows Phone (7 or 8) platform that supports custom shaders?

Posted by xoofx on 13 November 2012 - 07:05 PM

You will only get custom shaders from WP8 using Direct3D11. SharpDX is providing DirectX API for WP8 so custom shaders are working well. But if you want to leverage on XNA, MonoGame is working on a port to WP8 platform - which is using SharpDX (I saw a screenshot on twitter that the port was already working, but you should better check their latest github sourcecode branches/forks)

#4999053 Using Direct X 11 from the old DX-SDK under Windows 8

Posted by xoofx on 08 November 2012 - 04:36 PM

To create DirectX 11.1 device you need to use different functions. DirectX 11 functions haven't changed so SlimDX should continue working on Windows 8.

Not exactly, with D3D11.1, you create a normal D3D11 device and you query a D3D11.1 interface on it if you want to access the new features.

I'm using SlimDX for Direct X 11 (DX-SDK) development currently under Windows 7 with VS2012. I want to install Windows 8 but my concern is that as SlimDX does not support Direct X 11.1 (Windows SDK) that if I move to Windows 8 I won't be able to work. So I'd like to know if I can have Direct X 11 (DX-SDK) installed on Windows 8 side by side with Windows SDK so that I can keep working normally.

There is no problem installing DirectX June 2010 End-User runtime or SDK on Windows 8, I doesn't interfere with the Windows SDK. From a runtime point of view, your D3D11 application will work without any issues.

#4996064 Sorry if this is a stupid question. What would it take to get DirectX on Linux?

Posted by xoofx on 31 October 2012 - 09:46 PM

There was an attempt two years ago with Gallium "Direct3D 10/11 Is Now Natively Implemented On Linux!", but not sure they have been working on it since then...

#4995656 SharpDX 2.4 on WP8 and high level XNA like API

Posted by xoofx on 30 October 2012 - 07:41 PM

Hi All!

I'm glad to announce the availability of a new version 2.4 of SharpDX - a Managed .NET framework supporting the whole DirectX API - with two new major features:
  • Adds support for Windows Phone 8: This new version provides full access to WP8 DirectX from .NET (Direct3D11.1, XAudio2, MediaEngine). It allows you to add 3D content seamlessly integrated into your XAML DrawingSurface very easily. Like SharpDX for Windows RT, you can develop a game using Direct3D from .NET without using C++.
  • New SharpDX.Toolkit (beta), a high level API that greatly simplifies access to Direct3D11 by providing a XNA like API with the full power Direct3D11.1 The toolkit allows you to develop a 3D application to target Windows Desktop, Windows RT or Windows Phone 8 using exactly the same code base.
You can find more information here.

#4990598 WPF Fullscreen [SharpDX / SlimDX]

Posted by xoofx on 15 October 2012 - 09:26 PM

Since this topic is up I have another question, the fullscreen method I use at present is very similiar to the one in your link, same results different methods, it acts much like Windows Mode [Fixed] in games and is really decent but I often wonder the real difference between playing games in Fullscreen mode / Windows Mode [Fixed] or Windows Mode in general, now this may just be me but I find Fullscreen to look better though I have never actually known why. In terms of quality do games 'look' better when in fullscreen?

I'm not aware about a quality improvement when a backbuffer goes to fullscreen (apart from some color correction that could be applied in fullscreen differently by the gfx card?, not sure). The main difference is that for a plain window there is a copy (a blit) from the back buffer to the front buffer while in fullscreen mode, it is just a flip (see msdn doc about DXGI), plus the fact that the surface will go through Windows Manager composition, so It is usually slower and you can have less guarantee on the FPS/vsync in Window mode.

#4990572 WPF Fullscreen [SharpDX / SlimDX]

Posted by xoofx on 15 October 2012 - 07:06 PM

I don't think that WPF is supporting fullscreen mode with full control of the output monitor handled by DXGI swap chain as it can be done with WinForm. The only thing that you could do is probably to fake WPF form to look like a fullscreen app, like this. Also, when operating with WPF, you usually don't use a swap chain, as the process of copying/surface sharing with d3d9 is not using it.

#4989113 ShaderReflection; stripping information from an Effect

Posted by xoofx on 11 October 2012 - 08:42 AM

Very nice, I didn't realize you've released code for your toolkit (I heard mentions of it a while ago). But yeah, exactly the process that I've went with.
FYI, TinyPG produces code for a scanner/parser/parsetree, so there isn't any runtime dependencies. All you write is a grammer (e.g. terminals, production rules to parse and evaluate technique/pass expressions, etc). It's a lot simpler than writing out your own parser by hand.

TinyPG is indeed really nice and the generated code is concise and relatively efficient. But there are a couple of things that would require probably some changes to TinyPG in order to parse correctly HLSL with preprocessor:
  • For example, in my case, I parse and build an AST only for a technique block, everything else is eaten by the parser but skipped. I'm only checking that all braces {}[]() are matching until a technique is found.
  • I'm handling preprocessor (though D3DCompiler.PreProcess) and parsing #line directive in order to provide the exact line/file error from an included file. This would probably required some changes in TinyPG generated code or at least quite some code to re-process all parse tree errors and adjust line (and provide file information). Also a preprocessor doesn't fit well with a general grammar as it can be interleaved everywhere, so most of the time, you need some entry point between the scanner and the parser in order to handle them correctly (and I don't think that TinyPG has this kind of extension points).

#4989077 ShaderReflection; stripping information from an Effect

Posted by xoofx on 11 October 2012 - 06:35 AM

And even then, you can still use the FX file format - the difference is you'd have an offline compiler tool that parses the format for techniques/passes in order to acquire the necessary shader profiles + entry points. So with the profile/entry point in hand, you can run the FX file through the D3DCompiler to get a ShaderByteCode object for each shader, then use that to create a reflection object to query all your meta data. Then write out the reflected meta data to a file, that gets consumed by your application at runtime - which would be your own implementation of Effects11 (or something completely different, either way...you use the meta data to automatically setup your constant buffers, bind resources, and manage the shader pipeline by directly using the Direct3D11 shader interfaces).

For parsing, you can use something like Tiny Parser Generator, which is a really neat little tool if you know how to create a grammar. This is a problem that I've been working on myself for my own software and the approach has been working out pretty well (and frankly, I love TinyPG). I also believe the MonoGame folks have adopted this method, so that may be a good place to gather some ideas.

You are right, that is basically what has been done recently in SharpDX.Toolkit to support parsing of HLSL FX shaders:

- I decided to almost parse fx file format (only the content of technique/passes) in order to keep things quite compatible with legacy shaders and ease porting (though the syntax is slightly simplidied and different, check for example BasicEffect.fx link below)
- Write a parser, done by hand (nothing more than a couple of hundred of lines) and is mainly parsing technique/passes and the content of a pass, but the syntax supported is slightly closer to D3D9, producing an AST.
- Write a custom metadata fileformat (EffectData in the toolkit) that is able to save the whole description of a shader (shader bytecodes, constant buffers, value & resource variables, techniques/passes), nice thing is that It supports multiple effects inside a same archive that can be merged (like a zip of effects)
- Write a compilerthat takes the AST produced by the parser and compile all shaders and put them in the metadata format.
- A command line tool "fxc.exe" like called "tkfxc.exe" which basically allow to generate an archive of effects (unlike legacy FX, I can then put several effects inside the same tkfxo file), it is also outputing a friendly colored output as the original fxc.exe.
- Then you have to rewrite the whole Effect framework

Getting all this efficiently written is really really a long way (correct handling of constant buffers update, minimize calls to XXSetShaderResource/SetSamplers...for each shader stages...etc.), but in the end the result is pretty close to XNA effects (thus, I have been able to reuse all StockEffects from XNA, for example BasicEffect.fx is very similar to the original one, only techniques/passes declaration is slgihtly changing) but a bit more flexible as It can provide some extras features like linking of shader declared from another shader (export/import of a particular shader shareable between effects), or constant buffer pooling, or automatic access to all non-builtin variable declared in the effect pass at runtime (if you declare Toto = 1.0f; in the effect pass, you will be able to get this value from C#).

#4981880 Is XNA dying and MS forcing to C++?

Posted by xoofx on 19 September 2012 - 07:00 PM

The main reason why MSFT was encouraging developer to use C++ on Win8 to make games, is simply that they didn't have any other alternative.

All Win8 games provided in their SDK samples were developed in C++ and this was the official supported way to go with Win8 game development. I say 'was', because SharpDX filled the gap quite quickly last year, bringing the new DirectX11.1 API accessible to C# and support for the new Win8 "Modern App" platform restrictions as well. In the mean time, lots of companies that were developing games in XNA were absolutely against going back to C++ to publish simple games, and these companies have been using SharpDX quite successfully to develop Win8 Modern App. As Pete mention, several legacy popular games - minesweep...etc.- from Microsoft Game Studios were developed by a partner called 'Arkadium' which uses SharpDX. When I talked to Arkadium folks several months ago, they told me that it was quite difficult for them at the beginning to bring MSFT to accept that games could be developed in C# with SharpDX. In MSFT mind, only C++ was viable and supported, but Arkadium was able to produce their games, and MSFT got finally convinced that C# games are possible on Win8. They even talked about SharpDX as an alternative API at GDC last March.

So about your orginal question @Sooker, you are not forced to go to C++ to develop DirectX11.1 games, but as I have said many times, an API like SharpDX is low level (though there is a Toolkit on the way) and requires as much as native knowledge about the DirectX C++ API as you would go with C++, but the benefits are that you can leverage on the .NET ecosystem and C# languages to make things a lot more friendly to use than pure C++ (things like C# async/await are blowing away any kind of non-fluent game scripting for example).

Concerning the rumor of a XNA revival, if MSFT is working on a revamp of their graphics API, It will certainly not be XNA. The only work that is currently relevant would be to repackage the whole DirectX API into a WinRT like api, as they want to get rid of any legacy Win32/COM API. This revamp under WinRT is not entirely simple, as they would like probably to keep the same graphics level API for the next gen XBOX, and WinRT is currently not really designed to support optimized scenarios used on consoles (for example, the Direct3D9 API in XBOX 360 is not a pure COM API but a set of inlineable methods that are directly talking to the GPU command buffers, without going through the layers of Windows desktop WDDM/GPU-Scheduler).

#4950517 ID3D11DeviceContext::OMSetRenderTargetsAndUnorderedAccessViews(...)

Posted by xoofx on 19 June 2012 - 02:39 AM

You should setup the OIT_StartOffsetBuffer variable on the Effect (using AsUnorderedAccessView() on the variable) and not directly using OMSetRenderTargetsAndUnorderedAccessViews. (Check Effects11/EffectRuntime.cpp:205 in the DirectX SDK).

#4941136 [SharpDX] C# Handling Windows, Resizing, set custom resolutions

Posted by xoofx on 18 May 2012 - 02:48 AM

You should better ask your question directly on http://sharpdx.org/forum

#4939653 Speed up shader compilation (HLSL)

Posted by xoofx on 12 May 2012 - 05:03 PM

Given the fact that I have no option to pre-compile my shaders in the game I'm modding because it's always compiling the HLSL source files on every start-up (and again whenever you load a savegame) - what options would I have to speed up the game's just-in-time compilation?.

Just by curiosity, why can't you ship precompiled shaders?
As it has been said nested loops with texture sampling can be damn slow, as the compiler is trying to calculate correct ddx/ddy. If you can calculate them yourself or you can afford to sample a single mipmap the shader will compile more quickly.