Make ShaderSignature's GetHashCode return the address of its underlying buffer?

[GoogleCodeExporter]

It would be awesome if the ShaderSignature's GetHashCode is overridden to 
give the underlying shader bytecode's address.
In this way a dictionary can be created to map a ShaderSignature to an 
approapriate Mesh InputLayout.

Original issue reported on code.google.com by wanzi8...@gmail.com on 23 Nov 2008 at 4:52

[GoogleCodeExporter]

I think we're more likely to add a property that returns an IntPtr to the 
internal 
buffer, but we'll see.

Original comment by promit....@gmail.com on 25 Nov 2008 at 2:37

• Changed state: Accepted

[GoogleCodeExporter]

You can already create the mapping you describe, it will simply be less optimal
(perhaps) since the hash code is that of the default implementation (from
System.Object). I don't see a particularly compelling reason to override 
GetHashCode
for this interface, and even if I did it would not be to provide such an
implementation-specific value.

I'll look into exposing an IntPtr to the native object, but that may not end up 
being
viable; these objects are intentionally quite opaque. The SDK does not provide 
you
much in the way of their format or ownership semantics; many times they are just
void* controlled by the API.

Original comment by josh.petrie on 1 Dec 2008 at 9:52

[GoogleCodeExporter]

Thanks for the replies.

The problem with the default GetHashCode() is that currently 
EffectPass.Description.Signature returns a new ShaderSignature object with a 
different hash code each time it's called, and the same goes to EffectPass, a 
new 
EffectPass object gets created each time EffectTechnique.GetPassByIndex() is 
called.

In other words, the real problem is that for a given ShaderSignature or a 
EffectPass, there is no easy way for us to know if it is really equal to 
another 
ShaderSignature or EffectPass, even if they may live in different places in the 
heap.

I understand it's not safe to give out a void* pointer address, but even the 
class 
name ShaderSignature itself implies a certain degree of ownership, we sure 
should be 
able to compare whether or not two signatures are same.

Cheers

Original comment by wanzi8...@gmail.com on 4 Dec 2008 at 9:05

[GoogleCodeExporter]

The problem you describe is caused by the fact that the objects containing the 
signature in SlimDX are value 
types. Overriding GetHashCode() for ShaderSignature wouldn't solve that problem 
-- it would allow you to 
determine if two ShaderSignatures refer to the same signature (*maybe*, 
assuming the native API provides an 
appropriate invariant for the signature pointer). But it would not allow you to 
determine if two signatures 
were the same.

In other words, it would only return true if you were comparing two signature 
objects that were both from the 
same effect pass. Two signatures from differing effects would not compare true 
even if they were functionally 
identical. Unless the native API provides the appropriate invariant for that 
case -- but I don't think it does? I 
think the signature is just an offset into the compiled bytecode of the effect.

ShaderSignature was not created to provide ownership, it was created to provide 
type safety -- there are 
places in the API that take void* that mean shader bytecode or shader 
signatures, and we needed a way to 
disambiguate. 

The address as a hash might at least help with your issue. I'll add it and see.

Original comment by josh.petrie on 6 Dec 2008 at 5:09

[GoogleCodeExporter]

Original comment by josh.petrie on 8 Jan 2009 at 12:32

• Changed state: Fixed