Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Apr 2000
Offline Last Active Today, 07:38 AM

#5087486 Using both D3D9 and D3D11

Posted by Tape_Worm on 19 August 2013 - 10:49 PM

This is probably a very stupid question and I apologise if it is. But can't you just use the D3D9 feature levels in DX11 for the D3D9 renderer ?

It's not a stupid question at all, it's definitely something developers should look into if they wish to support direct3d 9 video devices.  However, there are caveats.  For example, if the dev wanted to run their application on Windows XP, they couldn't use the Direct3D 11 runtime because it won't work on XP.  
Also, from personal experience, the D3D9 feature levels are a pain in the ass to work with.  I've had several little "gotchas" when dealing with the D3D9 feature level (some of which have no or very sparse documentation) that I've nearly given up on caring if people can use it.  
An example of one of the issues I ran into was copying a texture into a staging texture.  Apparently, under feature level 9 you can't copy a resource into a staging resource if the source resource is in GPU memory and it's got a shader view attached to it.  So, if you created a texture with a shader view, you're out of luck.  So, create one without a shader view right?  Unfortunately, no, that leads to another set of issues (e.g. you can't bind to a pixel shader, kinda necessary).  There was that and a few other small issues I ran into (multi monitor was especially painful).


Another issue with feature level 9 is that the highest vertex/pixel shader model supported is SM2_x.  If you wanted to support SM3, then you're out of luck.

So in my own personal renderer, I want it to be able to support D3D9 and D3D11. To do this, I thought about having a master renderer interface that two classes will derive from. One will implement the D3D9 renderer and the other will implement the D3D11 renderer. However, this requires that I statically link to both D3D9 and D3D11, which will (I think) require that both dlls be present at run time. Is there any way I can avoid this?

You could design a system to load your renderer dynamically as a DLL.  This way the DLL would be the only thing linking to the libraries in question, your host application/API would have the interface abstracted so it wouldn't care about the dependencies.  So, for example, you can detect whether the user is running XP and force load the D3D 9 renderer DLL, or if they're not then load the D3D 11 renderer DLL.  
If you put both renderers in the same DLL then yes, you'll need to link against both.  Whether the end user will require D3D11 and D3D9 installed to run, I can't answer with any degree of certainty because it's been an incredibly long time since I've dealt with that stuff, but I'm going to guess that yes they would require both.

#5065686 [SharpDX]Loading Multiple Images into a Texture Array

Posted by Tape_Worm on 28 May 2013 - 08:38 PM

I've ported a bit of the DDS/WIC image loading/saving code from DirectTex/SharpDX toolkit for use in Gorgon.  I've got full support for texture arrays and other bits in there, particularly a function that allows me to take a series of System.Drawing.Image objects and make a texture array.


If it'll help, and if you want to adapt my code for your own use, go right ahead:



The code should be under the IO and Textures folders.


Just a word of warning though, this code is nowhere near production level and is being worked on often, so stuff may be broken at times.

#4981313 File I/O streaming performance.

Posted by Tape_Worm on 18 September 2012 - 11:55 AM

That's incredibly short sighted of your employers.

Regardless, here's an update:
I tried a memory mapped file, and nothing good came of it (I probably implemented it wrong, but I was getting horrid results). So I tried just CreateFile with FILE_FLAG_SEQUENTIAL_SCAN and I didn't see any improvement.

However, one thing that did impro... Wait, wait. I'm getting ahead of myself. Let me tell you a story. You see, once upon a time there was an employee, a dashing and handsome employee of a company who inherited a real mess of a code base and was told to fix it up and optimize it. He toiled day and ... day... and started seeing results. However, he noticed his CPU would spike intermittently during rendering. He said "What the shit is this?? Might be the constant file I/O..." and so off he went to research the various forums and troll dwellings to find a more optimal solution. And so, here I am trying my damnedest to get this thing optimized from slide-show to interactive frame rates. I can't really go into detail about the project, nor can I say anything about why I'm so restricted (it's in the contract).

Anyway. That's the story.

So, what I noticed this morning was that the dude who was writing this before me was calling _fseeki64 before -every- read. Even on sequential reads. Now, maybe it's not that bad, but I did notice an improvement after setting it up to only seek on random access. And it's actually not too bad now.

Regardless, 5GB of data is too damned much, and I need to cull that down. So I'm thinking the compression idea is worth a shot. I considered using BC4 to compress it, but I found out that it requires the texture be a power of 2 (at least, I think that's what I read). And the data I have (and will continue to receive) will not be guaranteed to be in powers of 2. It'll be a monumental pain in the ass to resize a volume texture and encode it into BC4, so for now I'm trying out RLE compression (yeah, it's old, it's non-native, but it's fast enough and it appears to be working...?) As this is all 8 bit values in the volumes, it might be sufficient.

Anyway, that's where I am as of today.

#4917852 Enumerating display adapter outputs

Posted by Tape_Worm on 29 February 2012 - 11:47 AM

I found this article, which shows, how to enumerate display adapters and adapter outputs using Direct3D: http://msdn.microsof...spx#Enumeration
I see from this article, that IDXGIFactory::EnumAdapters gives access to IDXGIAdapter interface, and D3D11CreateDevice can create 3D device from IDXGIAdapter. There is also IDXGIAdapter::EnumOutputs method, which gives an access to IDXGIOutput interface.
So, I can create ID3D11Device for every adapter. Is it possible, to create ID3D11Device for every adapter output? For example, if display adapter has two outputs, how can I draw separately on every monitor, connected to these outputs?

You create a swap chain for each output, you don't create a device for each output.

Use the SetFullscreenState to assign an output:
HRESULT SetFullscreenState(
  [in]  BOOL Fullscreen,
  [in]  IDXGIOutput *pTarget

Note that this is for full screen only.

#4023777 SlimDX -- A Prototype MDX Replacement Library

Posted by Tape_Worm on 02 August 2007 - 03:49 AM

Original post by jpetrie

I'm confident that promit/jpetrie have been careful about this as both are experienced developers


Shhh!!! No one can ever know the horrible, awful truth...

#4023765 SlimDX -- A Prototype MDX Replacement Library

Posted by Tape_Worm on 02 August 2007 - 03:37 AM

Original post by DragonL
I seem to recall reading somewhere that MDX is not, per se, a wrapper of the COM implementation of DX, and as such is closer to the driver and therefore has the potential to be faster than plain vanilla DX. This may be a load of bollocks since I can't remember where I read that, but I'd like to hear your opinions on this.

This is simply untrue. If you examine the MDX assemblies in a program such as reflector you can see that many of the methods call the methods of the IDirect3D* interfaces.

Another thing that pops up in my mind is boxing and what I've read about MDX having trouble with performance due to doing too much boxing/unboxing of the struct parameters. I assume that you guys have thought of such issues though?

I'm confident that promit/jpetrie have been careful about this as both are experienced developers (although mistakes do happen from time to time) and as such they're quite aware of the penalties of the box/unbox operations. After poking through SlimDX several times myself, I've not seen anything that immediately pops out as inefficient.

I'm sure promit/jpetrie can comment further on this and/or correct me if I'm mistaken. [grin]

#4002686 SlimDX -- A Prototype MDX Replacement Library

Posted by Tape_Worm on 07 July 2007 - 09:47 PM

Original post by bibiskuk
Hi, me again.

I started a new project with SlimDX, and I have some suggestions :

  • There is no Device::GetRenderTarget function, and no Device::SetDepthStencilSurface function as well. I have written this to have it :
    *** Source Snippet Removed ***

  • Why the Surface::CreateDepthStencil function is not a static method ? i must have another surface created to have a new DepthStencilSurface :)

I notified Promit of these items and sent the necessary changes to him a few days ago. Until the changes are integrated, just make the function static in the class declaration.


  • Is there some code already written which use SlimDX ? I search a little example for the use of the VertexBuffers, I can't have it working at all.

  • It's pretty similar to how vertex buffers worked in MDX. What exactly is causing you trouble?

    #3998691 SlimDX -- A Prototype MDX Replacement Library

    Posted by Tape_Worm on 02 July 2007 - 04:09 PM

    Original post by Promit
    Original post by Tape_Worm
    There is another thing I make use of that is not in SlimDX:
    The FromStream function should have an overload that has a parameter for size (replacing Width and Height if need be, or not if we wish to resize to that width and height), to indicate the amount of data to read from the stream (in bytes obviously).
    Ok, that's in. May I ask what you're using this bit of functionality for? (And on a sidenote, you could have actually written this functionality app-side by reading from the stream manually via Utils.ReadStream and then using Texture.FromMemory.)

    Yeah, I realize that now, I hadn't really thought about it hard enough (a result of next to no sleep). If you think it'd be superfluous perhaps it probably doesn't need to be in there, I think I can easily adjust from my end.

    #3998534 SlimDX -- A Prototype MDX Replacement Library

    Posted by Tape_Worm on 02 July 2007 - 11:53 AM

    Original post by Promit
    Done. LockRectangle returns a LockedRect, LockBox returns a LockedBox. The GraphicsStream is inside, along with the pitch info. Works nicely, I think.

    Awesome. That's exactly what I envisioned.


    Also done. I added a bunch of stuff here. The functions from IDirect3D9 are all available, and then that same info is wrapped into collections which you can foreach across. Each AdapterInformation (comes from Direct3D.Adapters) has a GetDisplayModes function that returns a list of display modes for a certain format.

    I didn't bother to check what MDX does here, so apologies if I deviate a lot. This is simple and makes sense to me, though.

    Awesome again. Doesn't matter how it works, I can easily adjust to whatever you set up and it's much easier when the modes are in a collection so it shouldn't take any effort to change on my end.

    I'll get the latest version and continue on once you go through my changes and integrate what you need.

    There is another thing I make use of that is not in SlimDX:
    The FromStream function should have an overload that has a parameter for size (replacing Width and Height if need be, or not if we wish to resize to that width and height), to indicate the amount of data to read from the stream (in bytes obviously).

    #3998034 SlimDX -- A Prototype MDX Replacement Library

    Posted by Tape_Worm on 01 July 2007 - 10:33 PM

    Original post by Promit
    The plan is to do a proper binary build when I label a 0.1 release version. That'll happen when I'm fairly content that grievous omissions and mistakes in D3D 9 core and basic D3DX (like the stuff Tape_Worm brought up) is repaired. I also don't want to make massive reorganizations after 0.1, if at all possible. For example, a whole bunch of stuff just got moved around so that D3D 10 can be slid in easily when it's ready. (Yeah, I had a change of heart on the D3D 10 thing. D3D9 Ex might just show up some time too.)

    Something else I've noticed: In the Texture->LockRectangle() functionality, you really need to return the pitch or else you'll have no concrete idea of the byte-width for the texture. Currently there's nothing to facilitate that. I hated the MDX approach of using the [out] parameters to relay this information. And of course that's a personal preference. But I think returning a value type from LockRectangle() that contains both the graphics stream and the pitch would be a more elegant approach. It'd be similar to how LockRect works in the C++ API, by sending back the byte data and pitch in D3DLOCKED_RECT.

    It took me a bit to wrap my head around how things work compared to MDX. The SlimDX, while not finished, seems more consistent in design and in how it matches up with the C++ API (the naming is pretty much the same for both, which is really nice). Whereas I find Managed DirectX to be a complete and total mess in many areas.

    I wish I were able to continue, but until the display mode enumeration is added I'll have to stop at this point.

    #3997911 SlimDX -- A Prototype MDX Replacement Library

    Posted by Tape_Worm on 01 July 2007 - 05:36 PM

    So I've tried today to migrate SlimDX into my Gorgon library. For the most part it's going well. However, I am missing a couple of functions from MDX. The (D3DX)CheckTextureRequirements function, and the TextureLoader.SaveToStream function. I can't seem to find any equivalent in SlimDX. I've found the Texture.From* functions, but nothing to save into a stream or file. Seems odd there'd be loading, but no saving functionality. Are either of these functions in some out of the way class? Or if they don't exist, will they be introduced in a newer version soon? If they don't exist, I can probably put them in myself, but I don't really want to duplicate any one elses effort.

    I've also found a couple of instances where a struct is empty. That is, the struct was declared without any access modifier for its members. The structs I've found so far are: Viewport, and SurfaceDescription. Easily fixed by adding 'public:' before the member declarations.

    #3994327 SlimDX -- A Prototype MDX Replacement Library

    Posted by Tape_Worm on 26 June 2007 - 10:07 AM

    I just ran the little water demo with the debug spew on. Ran much better than the first time I tried it.

    However, I did get this message in the debug output:
    3024: Direct3D9: (ERROR) :Final Release for a device can only be called from the thread that the device was created from.

    I think it might have to do with that auto-release stuff (I only poked around a little, I have no idea if I'm even close). And it's probably harmless, just thought you should be aware of it.