10-13-2020 02:16 AM
I use DP1.4 rxss as sink to receive video stream from source,
the block design refers to dp1.4 example as following,
and in vpss, I convert color format into RGB.
DP1.4 rxss --> frame crc --> vid_remap --> vpss --> vdma --> memory
Our flow is :
1. output RGB color bar from the source
2. write rx receiving frames into memory
3. read frames from memory and save as bmp file
when color format is RGB or YCbCr444, the bmp file shows all the pixels are correct
(because the bmp file looks exactly the same as we output from source)
but when it's YCbCr422, apparently most of the pixels are wrong.
I also use ILA to check raw data, it's not quite the same in every line since dp rxss video streaming.
I'm not sure what cause this problem, please help. thanks
10-14-2020 03:16 AM
We tried to reproduce this issue with QD780E and Samsung U28E590D monitor with KCU105 board based DP14 passthrough example design.
We see color change when YUV422 video data type is selected from QD780E graphics source. We have reported this issue to development team.
YUV422 from source:
Can you please let me know you video source and sink details?
Which Vivado version and Xilinx FPGA board you are using?
Run following test and share UART log with us:
Please capture snapshot of your observation throughout the test.
10-14-2020 10:26 PM
Hi @bpatil ,
Following are some information:
- vivado 2020.1
- dp rxss version is v2.1(Rev. 2)
- device part is xczu6eg-ffvc900-2-i (we implement dp functions in Microblaze)
- sink: NV P3200, source: dell UP3216Q monitor
Attach log for six different cases for your reference.
But throughout the test, I think it's because of the issue, when in pass-through mode, YCbCr422 format, the monitor shows nothing.
May I know when will this issue be fixed?
10-28-2020 10:49 PM
Our development team is working on this issue. It will take some time resolve this issue.
I will keep you updated on progress.
11-01-2020 11:16 PM
I am not sure, if this issue gets fixed in 2020.2. Possibility seems to be lesser, as currently 2020.2 is in release phase.
In our earlier tests, we haven't observed this issue with ZCU102 based example design. So, for now you can refer to ZCU102 based example design for your design.
11-02-2020 05:11 AM
Hi @bpatil ,
I tried to run pass-through example again with both ZCU102 and KCU105 with a laptop and Dell P2317H monitor, it’s indeed that ZCU102 has no problem with 422, however, I can’t reproduce the color bias situation as you did with KCU105, instead, it shows nothing on the monitor. I’m wondering if it depends on different sink and source?
11-02-2020 10:45 PM - edited 11-02-2020 11:07 PM
Which video source you are using?
I also suspect KCU105 DP14 example design issue with YUV422 data type changes with Video source. We have tested it multiple sources and results were different. We have also observed blank display for one of the tested video source, while with Nvidia RTX4000 and AMD Radeon graphics source we observed blurry outline output.
11-19-2020 09:54 PM - edited 11-19-2020 10:01 PM
Not yet. I will certainly update you once this issue resolved.
As I mentioned earlier, we have reported this issue to development team already. Development team is working on this issue but there is no significant progress for now (getting delayed due to 2020.2 release as well as some other high priority task with development team). ZCU102 example design working well with YUV422 data type shows, this signifies there is no issue with Xilinx DisplayPort IP's. We suspect there is issue with video pipeline data handling. Moreover, issue with YUV422 data type for DisplayPort 1.4 IP passthrough example design changes with change in Video source; this makes it more difficult to debug.
Right now, I believe it will take while to fix this issue 3-4 weeks or more. Till that time, we recommend to follow ZCU102 DisplayPort 1.4 example design.
01-04-2021 04:22 AM
The attached kcu105_pt_src.zip folder contains updated source files for kcu105 passthrough 2020.1 application.
The application is updated for 422 component format.
Earlier the value of component format being passed for 422 was incorrect which lead to color shift being visible. Also retraining support is added if color component format is changed.
Please note that there is one case below where memory write to a register will be needed >> It’s been observed that for 8k30 422, Nvidia trains our Rx at 5.4x4 and thus our Tx also trains either at 5.4x4(mostly) or 8.1x4. In such case the video on the sink would be corrupted. This is due to linereset issue on our Rx. To resolve this please set the Rx linereset disable register using memory write. For eg: mwr -force 0xXXXXXXXX(Rx base address + XDP_RX_LINE_RESET_DISABLE (0x008) reg address) 0x1.
This issue is known and would be resolved for 2021.1 release.
Kindly check example design with attached application code.
01-14-2021 01:12 AM
Hi @bpatil ,
After modifying source code refer to your attached files, pass-through 422 function works fine, but it only solve the pass-though problem.
In our design, we also transfer video streaming into vpss to convert it to RGB, and the problem is still there :
when we convert 422 to RGB, the output RGB streaming looks abnormal.
DP1.4 rxss --> frame crc --> vid_remap ----input streaming----> vpss ----output streaming----> vdma --> memory
(1) when input streaming format is RGB or YCbCr444, after convert to RGB by vpss, all data looks fine
(2) when input streaming format is YCbCr422, after convert to RGB by vpss, it fails
Any idea what would cause this? How to check if vpss convert streaming correctly?
Attached our vpss source code
01-19-2021 01:44 AM - edited 01-19-2021 01:44 AM
I need to check on it. Please spare me some time.