TDA4VE-Q1: How to enable off-screen surfaceless anti-aliasing

Hi Xingyu, 

Will provide an update shortly, looking into this.

Thanks,
Sarabesh S.

Hello, 

Please expect a delay. Bandwidth has been limited and I will be unavailable the next 1 week.

Thank you,
Sarabesh S.

Hi Sarabesh,

Our customer successfully enabled antialiasing by following the referenced post, but encountered visible seams after enabling anti-aliasing. Key observations:

1. The viewport consists of 9 irregularly shaped tiles;

Each tile comprises multiple triangular faces with shared vertices (no physical gaps);

No visible seams appear when antialiasing is disabled;

2. 8 intermittent dotted-line seams (~1 pixel wide) appear when enabled anti-aliasing;
Seams remain static and show blended colors between tile edges and base color (clear color);

3. Default order (2 4 6 8 1 3 7 9 5) produces 8 seams
Modified order (2 3 6 9 8 7 4 1 5) reduces seams to 4

Even if only rendering 3 6 5 still shows seams.

4. Tiles use camera-captured images as shading;
Seams will disappear if changing fragment shader with fixed color like black vec(0.0, 0.0, 0.0, 1.0)

This issue only occurs on TDA4VE - other SoCs from different vendors using identical logic and data cannot reproduce the behavior. Please assist in analyzing potential root causes for this antialiasing issue.

Hello Zhou.jun

    please refer to following cases about anti-aliasing on TDA4X platform:

     1. (+) TDA4VL-Q1: anti-aliasing cause OpenGL error 0x8d56 - Processors forum - Processors - TI E2E support forums

     2. (+) TDA4VM: Best method to enable anti-aliasing with GPU / OpenGL - Ficosa - SV Jacinto Forum - Ficosa - EP - TI E2E support forums

     3. (+) TDA4VM: How to turn on the anti aliasing mode of GPU in SDK 0806, using srv demo as an example - Processors forum - Processors - TI E2E support forums

    these 3 cases provide the solution how to enable anti-aliasing function on TDA4Vx platform, and how to fix the errors encountered,

Regards

    Semon

Hello,

Additionally, please check if your 1.15 DDK is fully updated with the latest KM patches and UM binary as shown in this FAQ: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1316731/faq-tda4vl-q1-what-are-the-gpu-driver-bug-fixes-for-sdk-8-6-or-earlier

Thanks,
Sarabesh S.

Hi Sarabesh,

Yes, our customer has updated, but the issue still exists.

Hello,

Can you confirm that you've tried the solutions referenced by Semon Zhang

Regards,
Sarabesh S.

Sarabesh Srinivasan said:

Can you confirm that you've tried the solutions referenced by Semon Zhang

Hi Sarabesh

     discussed with customer, they provided following explanation:

     ---------------------------------------------------from customer--------------------

     The scheme and details are as follows:
We're using off-screen rendering, so we're rendering the image to the texture first, and the anti-aliasing is of course also done in the process of rendering to the texture. For the specific implementation process, following code snippet is used for anti-aliasing:

===============================

enable anti-aliasing function：

*********************************************

PFNGLRENDERBUFFERSTORAGEMULTISAMPLEIMGPROC glRenderbufferStorageMultisampleEXT =

      (PFNGLRENDERBUFFERSTORAGEMULTISAMPLEIMGPROC)eglGetProcAddress("glRenderbufferStorageMultisampleEXT");

      glRenderbufferStorageMultisampleEXT(GL_RENDERBUFFER, 4, GL_DEPTH24_STENCIL8_OES, m_pixmaps[0].width, m_pixmaps[0].height);

      PFNGLFRAMEBUFFERTEXTURE2DMULTISAMPLEEXTPROC glFramebufferTexture2DMultisampleEXT = 

      (PFNGLFRAMEBUFFERTEXTURE2DMULTISAMPLEEXTPROC)eglGetProcAddress("glFramebufferTexture2DMultisampleEXT");

   glFramebufferTexture2DMultisampleEXT (GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D,

      m_eglConfig.surfaces[m_frameData4Vidout.m_currentPixmap].tex, 0, 4);

========================================================
Secondly, the more important information is that our pictures are taken by the camera in real time, and the camera images are updated to the pictures in real time through DMA technology. This picture is sampled as a direct parameter to the texture2D function in the shader.
According to the MSAA anti-aliasing principle, the possible cause of the gap is that the color buffer of the multi-sampled point is not updated by the texture2D process described above. and still retains the color of the initialized clear color. That is, there may be a problem with the writing of anti-aliased multi-sample points. If you write the color value directly, you can write it, and there will be no gaps. So the problem is located in this texture2D texture sampling process. I'm not sure if it's due to DMA used in this procedure, or if normal picture sampling will do the same? I'll do this experiment later.
In addition, off-screen rendering and DMA are common solutions for other ADAS driving companies. You can refer to whether other customers of yours have had similar problems and how to solve them.

If you know how to write openGL, my suggestion is to draw two triangles with overlapping sides, and the color of the triangles is provided by a map that uses DMA technology. Let's see if we can reproduce the problem above.

-------------------------------------------------------

please help check this issue and propose a solution

Thanks

   Semon

Hi Semon, 

I'm still reviewing all the context and past threads regarding MSAA in regards to surfaceless offscreen rendering. I also suspect that the issue is with how DMA +texture sampling is used here. To help understand the implementation I have the following questions:

How are you ensuring that the DMA update is fully synchronized with the GPU rendering? Is there a flush or glFinish called before drawing? Could the texture be unready during sampling?

I can work on reproducing your error but I also plan to discuss this with the weekly meeting I have with the graphics team this Friday. I should have another update for you in 1-2 days.

Thank you,
Sarabesh S.

Hi Semon, 

I'm still reviewing all the context and past threads regarding MSAA in regards to surfaceless offscreen rendering. I also suspect that the issue is with how DMA +texture sampling is used here. To help understand the implementation I have the following questions:

How are you ensuring that the DMA update is fully synchronized with the GPU rendering? Is there a flush or glFinish called before drawing? Could the texture be unready during sampling?

I can work on reproducing your error but I also plan to discuss this with the weekly meeting I have with the graphics team this Friday. I should have another update for you in few days.

Thank you,
Sarabesh S.

Hi Sarabesh:

                    How to set the qos of gpu on TDA4VE platform? I set the GPU qos according to the TDA4VM platform, and the GPU ATYPE is 3. I found that the bottom layer will report an error and the GPU cannot work normally.

Hello Sarabesh

    customer already verify the sdk10.1 patch for sdk8.6, other function is OK,

    but the anti-aliasing issue is not solved with the new patch, need further investigation

Thanks

    Semon

Hi Semon, 

Understood. I am currently looking into it and will provide an update by end of the week. 

Sarabesh Srinivasan said:

How are you ensuring that the DMA update is fully synchronized with the GPU rendering? Is there a flush or glFinish called before drawing? Could the texture be unready during sampling?

Could you please confirm this?

Thanks,
Sarabesh S.

Gaston yan said:

 How to set the qos of gpu on TDA4VE platform? I set the GPU qos according to the TDA4VM platform, and the GPU ATYPE is 3. I found that the bottom layer will report an error and the GPU cannot work normally.

Hello Gaston, 

Is this point related to the initial anti-aliasing query in the SRV application?

Is the goal to change priority of GPU traffic through QoS? If so, I don't believe you need to set ATYPE. The OrderID is what you should modify to set QoS. Additionally, I have some more clarifying questions about the above point:

1. Did you confirm that the register map is the same between TDA4VM and TDA4VE? If not, I can look into this. Also,
2. could you test with making ATYPE=0 (default) and let me know the results?
3. Does the time out occur when the GPU loads or only when you run an application?

Thanks,
Sarabesh S.

Hi Sarabesh：

1. Did you confirm that the register map is the same between TDA4VM and TDA4VE? If not, I can look into this. Also

             Regarding the J721S2 TDA4VE platform, I did not find any registers for gpu qos. When testing, I directly copied the register settings of TDA4VM.

        2. could you test with making ATYPE=0 (default) and let me know the results?

        3.Does the time out occur when the GPU loads or only when you run an application?

            The timeout occurs when running the application

Hello, I am out of office today and will inspect these results tomorrow.

Thank you,

Sarabesh S.

Hello Gaston, 

Thank you for the responses. I have some followup questions:

1. Are you able to provide me with the applications code? Or is this being modified entirely based on the SRV demo from the Vision Apps SDK (Linux+RTOS)?

Gaston yan said:

      

2. Based on this log, you have a firmware mismatch which suggests a difference between the kernel and DDK. Not sure how that can be unless you're using a different UM binary. Is this error only happening when changing ATYPE=0 (default)? I haven't seen this error in the other logs above.

3. Additionally, after looking into modifying the QOS registers, this would be done in U-boot. Have you made any changes in your bootloader that you can share? What makes you think the QOS setting is the problem?

4. Can you share the commit log of your GPU kernel driver?

And, can you confirm that you have this patch in your kernel source (services/system/rogue/rgx_j721s2/sysconfig.c):

132 static void SysDevFeatureDepInit(PVRSRV_DEVICE_CONFIG *psDevConfig, IMG_UINT64 ui64Features)
133 {
134 #if defined(SUPPORT_AXI_ACE_TEST)
135         if( ui64Features & RGX_FEATURE_AXI_ACELITE_BIT_MASK)
136         {
137             gsDevices[0].eCacheSnoopingMode     = PVRSRV_DEVICE_SNOOP_CPU_ONLY;
138         }
139         else
140 #endif
141         {
142             psDevConfig->eCacheSnoopingMode = PVRSRV_DEVICE_SNOOP_NONE;
143         }
144 }

And change it to this:

132 static void SysDevFeatureDepInit(PVRSRV_DEVICE_CONFIG *psDevConfig, IMG_UINT64 ui64Features)
133 {
134 #if defined(SUPPORT_AXI_ACE_TEST)
135         if( ui64Features & RGX_FEATURE_AXI_ACELITE_BIT_MASK)
136         {
137             gsDevices[0].eCacheSnoopingMode     = PVRSRV_DEVICE_SNOOP_CPU_ONLY;
138         }
139         else
140 #endif
141         {
142             psDevConfig->eCacheSnoopingMode = PVRSRV_DEVICE_SNOOP_CPU_ONLY;
143         }
144 }

Thank you,
Sarabesh S.

Hi Sarabesh:

                   Sorry, recently our UM and KM have been upgraded to version 24.2.6643903. The last test reported an error. You can check the picture and find that it is caused by the version mismatch. All updated to version 24.2.6643903. After the full version update, open the gpu qos settings and find that there will be no error. Regarding OrderID, it is directly copied from the TDA4VM platform. Open the GPU qos configuration and we will test the anti-aliasing problem. Reply later, thank you

Hello Gaston, 

So to be clear, updating to 24.2 DDK has resolved your previous timeout errors and GPU QoS can be enabled without issues. 

Gaston yan said:

Open the GPU qos configuration and we will test the anti-aliasing problem.

Sure, please let us know if the MSAA tile boundary problem still persists.

Thanks,
Sarabesh S.

Hi Sarabesh:

                   Qos does not improve the MSAA tile boundary problem,

Hi Gaston, 

Will continue looking into this as we are discussing GPU priority on this thread: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1519401/tda4ve-q1-tda4ve-gpu-driver-and-process-priority

Thank you,
Sarabesh S.

Hi Sarabesh:

we just try centroid qualifier in our camera image shader, but the lines still remians.

https://www.opengl.org/pipeline/article/vol003_6/

we refer to above article, is this same with texture bleeding?

henry

Hi Henry, 

I am not sure, the article seems to be addressing something different. Also, why do you need to enable antialiasing? If the application works without MSAA enabled then can you just keep those settings?

Thanks,
Sarabesh S.

Also, please note, I will be out of office till the 23rd, so expect a delay in responses. I will respond as I become available. 

Thank you,
Sarabesh S.

Sarabesh Srinivasan said:

I am not sure, the article seems to be addressing something different. Also, why do you need to enable antialiasing? If the application works without MSAA enabled then can you just keep those settings?

Thanks,

Hello Sarabesh

    customer feedback is that the static pictures can be merged without a gap between the pictures, 

    but the pictures from camera have such problem,

    please help check it

Regards

   Semon

Hi Sarabesh,

Anti-aliasing is a must required feature from CAR OEM. 

Hi,

The texture bleeding that is occurring is expected of anti-aliasing. When anti-aliasing, the edges are blurred to remove the jagged edges, and this can cause texture bleeding. Examples of the problem:

• https://discussions.unity.com/t/crazy-amount-of-texture-bleeding/250681/2 
• https://www.reddit.com/r/Blockbench/comments/vqbhkx/how_do_i_get_rid_of_these_dreaded_lines_on_the/ 
• https://gamedev.stackexchange.com/questions/67166/color-bleed-on-voxel-edges-when-using-anti-aliasing 

There are multiple of ways to fix it, but they are within the graphics application itself, not the GPU or DMA subsystems. A couple solutions:

• Remove anti-aliasing
• Add padding

Xingyu Zhu said:

Anti-aliasing is a must required feature from CAR OEM. 

Why is anti-aliasing a must required feature? What benefit will it provide? I don't see a benefit for adding anti-aliasing to the camera tiles. Those aren't 3D objects and shouldn't be subjected to jagged edges.

Adding anti-aliasing to the card model is fair, but unrelated to the camera tiles.

Best,
Jared

Hi,

Can y'all take a PVRCarbon recording of the behavior and post it here?

Documentation: https://docs.imgtec.com/tools-manuals/pvrcarbon-manual/html/topics/introduction.html 

Best,
Jared

Hello Gaston, 

    i tried the example in ti-processor-sdk-rtos-j721s2-evm-08_06_01_03/vision_apps/apps/basic_demos/app_linux_arm_opengl_mosaic/

    it will convert 4 pictures in opt/vision_apps/test_data/psdkra/app_opengl_mosaic/input1_file.bin (nv21 yuv format)

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/input1_5F00_file.bin

    to one picture output in output/mosaic_output_file.bin

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/mosaic_5F00_output_5F00_file.bin

    is this the same operation in your case?

Regards

   Semon

Hi Semon, 

To avoid having a single ticket address multiple queries, could you open a new ticket on this topic. I will address your questions and provide updates there. 

Thank you,
Sarabesh S.

Hello,

Following up on Jared's request here. Has there been any update on getting a PVRCarbon of the Anti-Aliasing SRV application?

You can also refer to this FAQ to obtain the necessary PVRCarbon file that is needed. After talking w/ the IP vendor, we highly suspect this is a result of texture bleeding and they are requesting this information.

Thank you,
Sarabesh S.

customer already fix this issue by a workaround solution: merging the pictures first with a application running on A72 core, then feed the merged picture to GPU for post processing, thus avoid blending the picture in Opengl/GPU with anti-aliasing issue, but will cause CPU load high, used as a temporary solution,

if CPU load becomes an issue, this issue needs further work,

now this issue can be closed

Regards

   Semon