TDA4VM: Opengl render issue when migrating from SDK 08.02.XX.XX to SDK 08.05.XX.XX

Hi, 

I ends up on this post today: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1080425/tda4vm-ldc-nv12p12-output-incorrect/4003139?tisearch=e2e-sitesearch&keymatch=nv12%25252520alignment#4003139

It seems to be my problem. I'm using a 3848x1034 RGB vx_image than convert it to nv12, but the nv12 stride-y is 3856. When modifying the stride to 3904, the image is render as it should.

With this finding, I would have two questions.

1. I am not sure to understand which hardware component in the system require this 64 bit alignement.

2. To fix this problem I changed the TIVX_DEFAULT_STRIDE_Y_ALIGN from 16 to 64. Is there any issue we could encounter if we use the VPAC and the other accelerator in the TDA4VM?

Regards,

Hi,

David Khouya said:

I am not sure to understand which hardware component in the system require this 64 bit alignement

This is basically for the OpenVX framework and not for any hardware component.

David Khouya said:

To fix this problem I changed the TIVX_DEFAULT_STRIDE_Y_ALIGN from 16 to 64. Is there any issue we could encounter if we use the VPAC and the other accelerator in the TDA4VM

If you are using the stride x and y values directly obtained after mapping the image, then I think there wouldn't be a need for this change.

However, I think this change wouldn't affect anything, Only that the buffer size would be increased.

Regards,
Nikhil

Actually for the second question, we are using the code from the vx_opengl_mosaic_target to send the vx_image to opengl. Here is a snippet from tivxOpenglMosaicProcess function in SDK rtos 8.5

            GLuint texYuv[8] = {0};
            app_egl_tex_prop_t texProp[4], renderTexProp;
            void *pEglWindowObj = mosaicParams->eglWindowObj;
            unsigned int i, numWindows;

            numWindows = 1;
            if(mosaicParams->createArgs.renderType==TIVX_KERNEL_OPENGL_MOSAIC_TYPE_2x2)
            {
                numWindows = MAX_TILES;
            }

            for (i = 0; i<numWindows; i++)
            {
                texProp[i].width             = img_input_desc[0]->imagepatch_addr[0].dim_x;
                texProp[i].height            = img_input_desc[0]->imagepatch_addr[0].dim_y;
                texProp[i].pitch[0]          = img_input_desc[0]->imagepatch_addr[0].stride_y;
                texProp[i].pitch[1]          = img_input_desc[0]->imagepatch_addr[1].stride_y;
                texProp[i].dataFormat        = APP_EGL_DF_NV12;
            }

            texProp[0].dmaBufFdOffset[0] = img_input_desc[0]->mem_ptr[0].dma_buf_fd_offset;
            texProp[0].dmaBufFdOffset[1] = img_input_desc[0]->mem_ptr[1].dma_buf_fd_offset;

            if (numWindows > 1)
            {
                for (i = 1; i < MAX_TILES; i++)
                {
                    for (j = 0; j < img_input_desc[i]->planes; j++)
                    {
                        texProp[i].dmaBufFdOffset[j] = img_input_desc[i]->mem_ptr[j].dma_buf_fd_offset;
                    }
                }
            }

I'm not sure how I can use the stride x and y in this situation to map the vx_image, here img_input_desc, passed to the kernel.

Hi,

In the target file, we get the input_desc which is the object array of images sent as input.

From this, we get img_input_desc, which consists the information of the vx_image you had created in the application, with width, height provided by you and the stride value provided by the framework.

Hence, here we could see the pitch value being sent using the stride_y. 

texProp[i].pitch[0]          = img_input_desc[0]->imagepatch_addr[0].stride_y;

This way, the alignment criteria is met by the framework.

Regards,
Nikhil

If we use the default y stride alignement (16bits) with our image which as a resolution of 3848x1034. we get corruption after the opengl node like the image below:

If we change the default y stride to 64 bits, then the pink line is not there anymore. I'm trying to understand why the default y stride change fix the issue. I see here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/971596/tda4vm-scaler-problem-on-ho/3589726?tisearch=e2e-sitesearch&keymatch=TIVX_DEFAULT_STRIDE_Y_ALIGN#3589726 that the video codec need a y stride aligned on 64 bit, does this apply also when using opengl?

Thanks!

David,

I am checking with our development team whether 64-bit alignment is required for OpenGL External EGLImages.

Thanks,

Erick