none
AMP Texture::set assert RRS feed

  • Question

  • When trying out the interop between AMP and D3D11 textures i stumbled upon a possible mistake in the amp_graphics.h header file.

    Situation:

    I Created a ID3D11Testure2D using D3D and called Concurrency::graphics::direct3d::make_texture to get a Texture which you can use with AMP.

    The format of the D3D texture is DXGI_FORMAT_R8G8B8A8_UNORM, the result of the make_texture call is a texture<unorm_4, 2> type.

    When a call to the set member function is included the compilation fails due to 2 static asserts within this function;

    /// <summary> /// Set the element indexed by _Index with value _Value. /// </summary> /// <param name="_Index"> /// The index. /// </param> /// <param name="_Value"> /// The value to be set to the element indexed by _Index. /// </param> void set(const index<_Rank>& _Index, const value_type& _Value) __GPU_ONLY

    {

    static_assert(_Short_vector_type_traits<_Value_type>::_Num_channels == 1, "Invalid value_type for set method."); static_assert(_Short_vector_type_traits<_Value_type>::_Format_base_type_id != _Unorm_type, "Invalid value_type for set method."); static_assert(_Short_vector_type_traits<_Value_type>::_Format_base_type_id != _Norm_type, "Invalid value_type for set method."); _Texture_write_helper<index<_Rank>, _Rank>::func(_M_texture_descriptor._M_data_ptr, &_Value, _Index); }


    The first 2 asserts fire.

    Is it me or are the static_asserts inverted?

    Requiring a texture to use >1 channel and normalized types seem pretty obvious, the asserts however do not allow it.

    I'm just asking here to be certain before i post it at the feedback site.

    This happens on the VS11 Beta.


    • Edited by Kodiak123 Saturday, March 17, 2012 6:24 PM
    Saturday, March 17, 2012 6:23 PM

Answers

  • Hi Kodiak123,

    Sorry for lack of the documentation on this. We will be publishing a series of blog posts to drill into the details.

    When bind a D3D11 texture to UAV, for most DXGI formats, it's write-only, thus not allow read.  When it's bound to SRV, it's read-only. The only exceptions are R32_FLOAT/R32_UINT/RS32_SINT, UAV of such format is allowed for both read/write. 

    We try to disallow read/write on the same texture statically as much as we can.  Thus the subscript operator (only allows read) is always enabled for texture class, but the "set" method of texture class is disallowed for any texture with more than 1 channels, or using norm/unorm. So accessing such texture using texture class is actually read-only.

    To write to such texture,  one has to create a writeonly_texture_view, which only offers the "set" method. You can create a writeonly_texture_view on top of a texture, then capture it by value to parallel_for_each. Then you can use the "set" method to write into such textures within parallel_for_each.

    For texture with only 1 channel but 8/16 bits per channel (only known at runtime), for example, R16G16_FLOAT, we cannot enforce this statically, if user ever tries to do both read/write to the texture, a runtime exception will be triggered.

    As I mentioned at the beginning, we will give great details on texture usage in coming blog posts. Please stay tuned.

    Thanks,

    Weirong

    • Marked as answer by Kodiak123 Sunday, March 18, 2012 8:31 AM
    Sunday, March 18, 2012 12:14 AM