Wierd results with ComputeImageChannelOrder.R

Help
Jeff Adams
2010-05-05
2012-12-21
  • Jeff Adams

    Jeff Adams - 2010-05-05

    I'm trying to use single-channel image2ds, and getting odd results. 

    Here's the relevant bit of my kernel:

    for (int x = 0; x < 10; x++) {
        for (int y = 0; y < 10; y++) {
            write_imagef(b, (int2)(x, y), (float4)
                (100.0f + (x*10)+(y),
                 200.0f + (x*10)+(y),
                 300.0f + (x*10)+(y),
                 400.0f + (x*10)+(y)));
        }
    }

    Here's what I get in my array back in C# after the read:

    _100.00__110.00____0.00____0.00____0.00__102.00__112.00____0.00____0.00____0.00
    _104.00__114.00____0.00____0.00____0.00__106.00__116.00____0.00____0.00____0.00
    _108.00__118.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00
    ___0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00
    ___0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00
    ___0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00
    ___0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00
    ___0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00
    ___0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00
    ___0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00____0.00

    It kind of looks like something is walking 4 values at a time, or at least that's part of what's going on.  I'm still looking into it but I figured it was worth posting (in case the single-channel-order isn't working yet or something).

     
  • Jeff Adams

    Jeff Adams - 2010-05-05

    Oh sorry, forgot to say "b" is an image2d_t created with:

    new ComputeImage2D(_context, ComputeMemoryFlags.WriteOnly | ComputeMemoryFlags.AllocateHostPointer,
                        new ComputeImageFormat(ComputeImageChannelOrder.R, ComputeImageChannelType.Float),
                        width, height, 0, IntPtr.Zero)

     
  • nythrix

    nythrix - 2010-05-05

    You're declaring an image with a single float per pixel (R) but writing four floats per pixel (as in RGBA). That's my bet.

     
  • Jeff Adams

    Jeff Adams - 2010-05-05

    There's no way to write less than a float4 though.  That's what the API takes.

    For reading, it specifies what you get in the float4 (I.E. in "R" order you get "value, 0, 0, 1") so I am assuming it works the same with writing ("value, ignored, ignored, ignored") which is what seems to be the case, if you look at my output there are no 200, 300, or 400 values).

     
  • nythrix

    nythrix - 2010-05-06

    You're right. I had the impression write_image and read_image take different vectors for different image formats. But then no float3 exists so it wouldn't work in all cases.
    Maybe it's a readback problem? How do you retrieve the resulting array?

     
  • nythrix

    nythrix - 2010-08-13

    If you're running ATI Stream and hit this issue, consider upgrading to a newer (Stream) version. Previous versions (<2.2) had no support for single channel images.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks