Menu
Home
Forums
New posts
Search forums
What's new
Featured content
New posts
New media
New media comments
New resources
Latest activity
Media
New media
New comments
Search media
Resources
Latest reviews
Search resources
Nyuuz
Jinaral kantent
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Menu
Log in
Register
Install the app
Install
Home
Forums
Labrish
Nalij
Jinaral kantent
QHD 360Hz pushes DisplayPort 1.4 past raw limits
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
[QUOTE="Shamiso, post: 92538, member: 160"] A 2560 × 1440 RGB image at 360Hz carries 31.85Gbps of active 8-bit pixel data before blanking or link overhead. Push the signal to 10-bit color and the active image alone rises to 39.81Gbps. Those numbers matter because DisplayPort 1.4 at its fastest HBR3 rate provides 25.92Gbps of usable payload bandwidth. Even the leaner 8-bit QHD 360Hz signal is already beyond that ceiling. Timing overhead still has to fit too. The [B][URL='https://goldmidi.com/community/threads/tcl-listed-the-25p2a-pro-qhd-360hz-mini-led-monitor-in-china.77892/']TCL 25P2A Pro connection layout[/URL][/B] gives you two HDMI 2.1 ports and one DisplayPort 1.4 input. Port names look reassuring, but they do not yet tell you which color depth, link mode, or compression setting TCL uses for the full 360Hz mode. [HEADING=2]Raw bandwidth is the real 360Hz gate[/HEADING] DisplayPort 1.4 cannot carry uncompressed 2560 × 1440 at 360Hz in full RGB at 8 bits per color when HBR3 is the link limit. The active pixels need about 31.85Gbps, while the interface has 25.92Gbps available for payload. The math runs out before blanking enters the picture. Display Stream Compression is the obvious route. DSC compresses the display stream before transmission and reconstructs it at the monitor, letting a DP 1.4 connection move modes that would otherwise outrun the link. This is not the same thing as a game rendering at a lower resolution and then being upscaled. Your GPU can still produce the full 2560 × 1440 frame, while DSC works on the finished display stream being sent across the cable. A [B][URL='https://sid.onlinelibrary.wiley.com/doi/pdf/10.1002/sdtp.11838']large-scale DSC visibility test[/URL][/B] evaluated the codec using a standardized subjective method designed for nearly lossless image coding. DSC is described as visually lossless rather than mathematically lossless, which is an important distinction, but it is built specifically for display links where bandwidth is tight, and latency has to stay low. The practical wrinkle is support at both ends. Your graphics card has to encode DSC, the monitor has to decode it, and the selected input mode has to expose the right combination of refresh rate, bit depth, chroma format, HDR, and variable refresh behavior. All three pieces have to line up. [HEADING=2]HDMI 2.1 does not settle the issue[/HEADING] HDMI 2.1 can reach much higher bandwidth than DisplayPort 1.4 when a device implements the full 48Gbps Fixed Rate Link configuration. A full-rate implementation has enough raw link capacity to make QHD 360Hz much less cramped than HBR3, especially at 8-bit color. The awkward part is the label. A product can be marketed as HDMI 2.1 without supporting every feature or the maximum 48Gbps rate. Seeing HDMI 2.1 beside a socket does not tell you whether it uses FRL, which FRL rate is available, or whether the monitor caps a particular resolution and refresh combination. You can see the problem on existing QHD 360Hz monitors. Some models expose 360Hz through DisplayPort while their HDMI input tops out far lower, even though the HDMI socket is still described as HDMI 2.1. TCL's current public material confirms QHD at 360Hz and promotes the monitor's high-refresh connection path, but it does not publish enough input-timing detail to pin down the exact transport mode for every port. Until a proper timing table or manual spells it out, assuming both HDMI ports deliver 1440p at 360Hz would be guesswork. Version numbers are not a substitute for a timing table. [HEADING=2]Color depth can move the bandwidth goalposts[/HEADING] Eight-bit RGB needs 24 bits for every active pixel, which produces the 31.85Gbps figure at QHD 360Hz. Ten-bit RGB needs 30 bits per pixel, lifting the active-picture requirement by 25 percent to roughly 39.81Gbps before blanking and transport overhead. HDR can make this relevant because a PC may switch to a 10-bit output mode when HDR is enabled. A connection that handles 360Hz cleanly at one color setting can therefore need compression or a different timing arrangement once you change bit depth. Small settings changes can push the link into a different transport mode. Chroma subsampling can also reduce bandwidth, but it is not an attractive default for desktop use. Fine colored text and interface edges can lose clarity when full chroma resolution is traded away. A proper PC monitor mode should be judged on what it can carry without quietly sacrificing desktop sharpness. The useful check is simple once final documentation appears. Look for 2560 × 1440 at 360Hz, the supported bit depth, full RGB output, DSC status, HDR support, VRR compatibility, and which physical input exposes the complete mode. For the 25P2A Pro, DisplayPort 1.4 needs DSC or another bandwidth-saving mode to carry full-RGB QHD at 360Hz because the active image alone exceeds HBR3 payload capacity. HDMI has more potential breathing room, but the version badge still cannot confirm the actual mode. [/QUOTE]
Insert quotes…
Name
Post reply
Home
Forums
Labrish
Nalij
Jinaral kantent
QHD 360Hz pushes DisplayPort 1.4 past raw limits
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Accept
Learn more…
Top