This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: DSS alpha blending issue

Part Number: AM5728

Tool/software: Linux

Hi.

we use all plane of DSS. Of that, VID1 plane(zorder is below than VID3) use VIDEO and VID3 plane(zorder is upper than VID1) use GUI for HDMI display. because VID3 plane is GUI, zorder of VID3 plane must have upper value than zorder of VID1 plane(VIDEO). 

we works well throung (VID1 + VID3) -> overlay.

but, When VID3 plane have as follwoing GUI (attached file(bmp_0.bmp)), HDMI display have some abnormal pixel at specific position.

we debug gpu and dss during some day and then we have result that alpha blending of DSS have any problem.

we attach source file(tt.7z) https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/tt.7z that can see this.

this source file(tt.7z) have as follow it.

- we clearly see abnormal pixel throug 1080i display resolution.(JUN_1080I_SUPPORT)

- HDMI connctor id is 36, VID1 plane is 37 for video and VID3 plane is 43 for GUI at our custom board.(JUN_BITMAP_LOAD_TEST)

- bmp_0.bmp is loaded on VID3 plane(JUN_PLANE2_BITMAP_LOAD)

- fill_bitmap of buffer.c forcely replace red color to find specific postion that HDMI display abnormal pixel(we attach TV display).

  -> we can mark(delete) pixel debug not to see red color.

we try to change global alpha, premultiply alpha blending and zorder many times. we don't find correct solution.

-./drmzalpha -s 1920x1080 -w 37:0:255:0 -w 43:1:255:1

./drmzalpha -s 1920x1080 -w 37:0:255:1 -w 43:1:255:0

.....

./drmzalpha -s 1920x1080 -w 37:0:255:0 -w 43:4:255:0

./drmzalpha -s 1920x1080 -w 37:1:254:1 -w 43:2:255:1

...

I want to resolve this  DSS alpha blending's problem will be fixed.

Thanks a lot.

  • Please post the Linux version you are using.
  • Hi.
    we use ti-processor-sdk-linux-am57xx-evm-04.00.00.04.
    Thanks a lot.
  • It's caused by scaling.

    For example, if there are two pixels, one below and one above. The one above is 0x00ffffff, and the one below 0xff000000. So the above one is totally transparent white pixel, below one is totally opaque black pixel.

    Presuming a black background, without scaling, this will not show anything on the screen, as the above pixel is seen through and shows the black background, and the below pixel is black itself. This is as it should.

    But with scaling, the pixels values get "averaged" by the scaler. The end result may be, say, 0x7f7f7f7f, i.e. the average of the two pixels.
    This pixel is half transparent grey pixel, which is not the expected result, of course.

    The best way around this may be to just not use scaling.
  • HI.
    you are right for DSS' scaler issue.
    we try to modify source, test as below it and display well .

    ./drmzalpha -s 1280x720 -w 37:0:255:0 -w 43:1:255:0

    ./drmzalpha -s 1280x720 -w 37:0:255:0 -w 43:2:255:0

    ./drmzalpha -s 1280x720 -w 37:1:254:1 -w 43:2:255:1

    ./drmzalpha -s 1280x720 -w 37:2:255:0 -w 43:3:255:0

    but, we need that gui layer size is 1280x720 and to scale to display(1080 resoulution).

    we test to scale up issue as below url.
    e2e.ti.com/.../2506334 scale#2506334

    we have same problem.

    How do i fix it with scaling it ?

    Thanks a lot.
  • Can you try scaling gui layer using vpe or GC320?

    Regards,
    Manisha
  • Hi.
    GC320 use for blitting/alpha blending/flush many surface(total surface's size is about 100MB). It takes 1GB per 1 second for memory bandwidth.
    and then, we can't scale at GC320 due to GC320 IP is heavey full for 60 FPS.
    VPE use for deinterlacing IVA-HD H.64 decoding for full HD (1080I contents).
    and we need 60 FPS of Video. we don't use more scaler of VPE.

    we tested it at other SoC( Broadcom and Sigma design ).
    The SoC don't have problem.

    I want that DSS resolve this problem.

    Thanks a lot.
  • Hi Joonho,

    I will consult our DSS IP expert. He is on vacation. Will reply back here when he is back in office and able to look at this reported problem.

    Regards,
    Manisha
  • Hi Joonho,

    Can you please do another level of testing and let me know the results?

    1. Can you try the up-scaling of gui without the video overlay and see if the issue still exists?
    2. If you don't see issue with just gui scaling, can you switch to non transparent GUI plane (e.g. not using RGBA, but RGB or RGBX format in the gui plane) and try the blending?

    Regards,
    Manisha
  • Hi.

    we let you know the result.

    1. Can you try the up-scaling of gui without the video overlay and see if the issue still exists?

    ->  this result is same error.

         -> ./drmzalpha -s 1920x1080 -k 43:0:255:0 -w 37:1:255:0    (here, k is  used for video layer is skipped)

    ->  If gui zorder is 0, dss display well.

       -> ./drmzalpha -s 1920x1080 -k 43:0:255:0 -w 37:0:255:0    (here, k is  used for video layer is skipped)

             -> actually, If gui zorder is 0, we don't see video layer.

    2. RGBX format

    -> we use RGBX format instead of RGBA. this have same problem.

    we attach test source.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/tt2.7z

    Thanks a lot.

  • Hi Joonho,

    Thanks for doing additional testing. The next expert whom I need to consult is on vacation till July end. I will be able to get back into this once he is back in office and able to look into this problem.
  • JOONHO LEE said:

    ->  If gui zorder is 0, dss display well.

       -> ./drmzalpha -s 1920x1080 -k 43:0:255:0 -w 37:0:255:0    (here, k is  used for video layer is skipped)

             -> actually, If gui zorder is 0, we don't see video layer.

    Do you mean to say with this settings, 1080p GUI layer is seen on the display (without video layer) and there is no issue with the output quality?  Only difference between the two testings (this and the previous one) is gui layer been assigned zorder 1 vs 0. In both the testing video layer was skipped. Please confirm.

  • Hi Joonho,

    I am closing this thread for now. Will re-open it once we have our next level of experts back in office and can look at this issue.
  • Hi.

    I am OK as you say about closing it.

    When your expects review it, let me know it.

    Thanks a lot.

  • Hi Joonho,

    The DSS IP expert has below comments -

    1. DSS should be only used to scale video or natural images (That is why DSS IP has a “VIDEO” pipeline with Scaling and a “GFX” pipeline with no scaling in DSS). GFX/GUI (GPU or CPU generated) should always be generated at display resolution such that it is never scaled inside DSS. 
      1. GRPX image scaling might do fine if the source image (particularly alpha value) has single alpha value or pixels (including alpha value) are anti-aliased prior to scaling.

    2. Force DSS scaler to not do low pass filtering while resizing. This is possible by changing the filter coefficient to a different set than the default. This is exactly what is done in the patch in,

    The above patch changes the scaler filtering to a “Nearest-Neighbor” algorithm

    This patch will not work in all cases and will perform poorly while scaling Video or natural images.

    Regards,

    Manisha

  • Hi. Thanks you for answering our question.

    The patch that you indicate is already applyed and tested it. but, It don't help it at our environment.

    Can I get more better scaler filter patch ?

    Thanks a lot.

  • Hi Joonho,

    Unfortunately there is no better scaler filter patch. If the shared patch doesn't work, then you need to try other suggestions, best among them is not to scale the graphics image.

    Regards,
    Manisha