arjun.a
embed files
325bfe1
Ticket Name: TDA4VM: Create 2 framebuffers, But introduced a new problem: splash screen, the screen keeps flickering
Query Text:
Part Number: TDA4VM Other Parts Discussed in Thread: TDA2 background: Based on TDA4, SDK7.03, QNX system, to achieve off-screen rendering problem: what I want to do is this: Create 2 framebuffers, let’s call them fb1 and fb2. Render the scene to fb2 normally. Render fb2 to fb1 with one post-processing effect. Render fb1 to the default framebuffer (we’ll call it fb0) with another post-processing effect. This method really works. But introduced a new problem: splash screen, the screen keeps flickering. After verification: changing glFinish to glReadPixels, the flickering phenomenon still exists. But the image saved by glReadPixels is normal. The specific implementation is as follows:
Responses:
Hello, Thank you for creating a new thread. I will close the other one and let us use this one. For reference: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1033627/tda4vm-off-screen-rendering-problem-0x506-gl_invalid_framebuffer_operation The fact that glReadPixels on the offscreen buffer returns normal expected image, we need to think if the display node is somehow showing the wrong buffer. Do we know if there is a timing involved? Some suggestions and questions: 1. Have you tried glReadPixels on the final FB? Does this look okay? 2. Instead of any post processing, can we do a simple glClear (of different colors) to fb0, fb1 and fb2 And can we switch colors for each to see what is ending up on the display. 3. As a separate experiment, continue with normal rendering processing but do a glClear of alternating colors on fb0 Regards Hemant
OK, I will start experimenting now, and I will tell you immediately if there is a conclusion, it is expected in three hours. But this is done to verify: the two Buffers are constantly switching or?
In order to better verify, compare and analyze the result data, FB1 was rendered red by me; FB2 was rendered blue by me; FB0 was finally rendered (including the content on FB1 and FB2 and other textures such as the car model drawn normally) After verification, the image results saved by FB0, FB1, and FB2 are all completely OK. [AVM] FB0 Width=1920, Height=720, Format=0x80e1 (GL_BGRA=0x80e1, GL_BGR=0x80e0), Type=0x1401... [AVM] FB1 Width=560, Height=720, Format=0x80e1 (GL_BGRA=0x80e1, GL_BGR=0x80e0), Type=0x1401... [AVM] FB2 Width=1280, Height=960, Format=0x80e1 (GL_BGRA=0x80e1, GL_BGR=0x80e0), Type=0x1401... FB0 is the default FB of external TDA4: 1920*720 format GL_BGRA (GL_BGRA_EXT), save the image OK FB1 is an FB created internally by myself: 560*720 format GL_BGRA (GL_BGRA_EXT), save the image OK FB2 is another FB created internally by myself: 1280*960 format GL_BGRA (GL_BGRA_EXT), save the image OK The specific video and the results, I will let Fredy forward it to you,Here is just a screenshot
Let me add the setting parameters of Display Node. Is there a problem with these parameter settings, especially the two parameters opMode and pipeId (Can you explain what is the meaning of setting different values for these two parameters? I will also do verification at the same time, See the impact of these different values): display_params.opMode = TIVX_KERNEL_DISPLAY_ZERO_BUFFER_COPY_MODE; display_params.pipeId = 2; display_params.outWidth = SV_DISPLAY_WIDTH; display_params.outHeight = SV_DISPLAY_HEIGHT; display_params.posX = 0; display_params.posY = 0; obj->disp_config = vxCreateUserDataObject(obj->context, "tivx_display_params_t", sizeof(tivx_display_params_t), &display_params); status = vxGetStatus((vx_reference)obj->disp_config); obj->displayObj.disp_node = tivxDisplayNode(obj->graph, obj->disp_config, obj->out_img); vxSetNodeTarget(obj->displayObj.disp_node, VX_TARGET_STRING, TIVX_TARGET_DISPLAY1); vxSetReferenceName((vx_reference)obj->displayObj.disp_node, "Display_node");
Share the latest research information: it has a certain relationship with the screen parameter settings. Change the opMode parameter of the display node from TIVX_KERNEL_DISPLAY_ZERO_BUFFER_COPY_MODE to TIVX_KERNEL_DISPLAY_BUFFER_COPY_MODE, the splash screen problem is solved, but the rendering slows down. In other words: using TIVX_KERNEL_DISPLAY_ZERO_BUFFER_COPY_MODE will render faster, but the screen will flick; using TIVX_KERNEL_DISPLAY_BUFFER_COPY_MODE will not flicker, but the rendering will be slower. But this is not enough, rendering is too slow. TDA2 also uses the TIVX_KERNEL_DISPLAY_ZERO_BUFFER_COPY_MODE parameter, which renders quickly without flickering. I still feel that there is a problem, you can continue to research in this direction, and I will continue to research at the same time.
Hello, Thank you for confirming that and sorry for not getting back sooner. We of course need the zero copy mode. Because the copy mode is working fine, I tend to agree that it could be the display side of things that could be out of sync. I will check this internally and get back. In the meanwhile, if there are any updates, please let us know. Regards Hemant
Thanks for the reply. But how to solve this problem? Need help urgently~ Please~ Another more urgent problem is encountered: After AVM is started (GPU rendering), it may cause communication blocking between its own process and the processes of other modules. This is a newly discovered problem.
Just to rule something out - can you confirm that you have a glFinish at "each" stage of the offscreen and on screen rendering. With three frame buffers, this would mean three glFinish (at least for verifying - ideally, glFinish at the very end should be fine). I am trying to replicate this behavior here on Linux and also discussing with display experts. Regards Hemant
I confirm that there is glFinish in "every" phase. This problem of off-screen rendering causing splash screen is one of the problems; Another newly discovered problem is that after AVM rendering, it will affect the IPC process communication. This is also explained in another e2e post of mine. Please help and solve it. Thank you, and look forward to your prompt reply.
Hello, is there any progress now? It's anxious, please. Thanks~