Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Desktop compositing latency is real

lofibucket.com

Post reply on HN
Print view View original

281–290 of 306 posts

Re: Desktop compositing latency is real

#281

Post by Const-me »

roel_v wrote: post #267
CyberDildonics wrote: post #168

Earlier quoted context omitted.

> So you trade a frame of latency for lots of overdraw, which is a tradeoff I'm not really comfortable making. I would jump at the chance to make that trade. My 8 year old CPU is rarely taxed by normal usage. What's the point in having a faster computer if it feels slower?

Overdraw doesn't just use some CPU. If that would be all, it'd be an easy problem to solve. It causes extra data to be transferred over various buses, extra stops in a pipeline of operations that is already cramped trying to provide a frame every few ms, and probably other problems that I don't know about. This problem isn't as easy as 'throw some more CPU at it'.

I think it’s only that complex and taxing for GUI frameworks that mix CPU and GPU rendering. Like Win32 GDI or GTK+.

For modern GUI frameworks that were designed for GPU, like MS WPF/XAML or Mozilla WebRender, overdraw just use some GPU resources, but that’s it. GPUs are designed for much more complex scenes. In-game stuff like particles, lights, volumetric effects, and foliage involve tons of overdraw. In comparison, a 2D GUI with overdraw is very light workload for the hardware.

Re: Desktop compositing latency is real

#282

Post by CyberDildonics »

roel_v wrote: post #267
CyberDildonics wrote: post #168

Earlier quoted context omitted.

> So you trade a frame of latency for lots of overdraw, which is a tradeoff I'm not really comfortable making. I would jump at the chance to make that trade. My 8 year old CPU is rarely taxed by normal usage. What's the point in having a faster computer if it feels slower?

Overdraw doesn't just use some CPU. If that would be all, it'd be an easy problem to solve. It causes extra data to be transferred over various buses, extra stops in a pipeline of operations that is already cramped trying to provide a frame every few ms, and probably other problems that I don't know about. This problem isn't as easy as 'throw some more CPU at it'.

That seems like a dubious claim to me. In my experience maxing out memory or pcie bandwidth is rarely a bottleneck, and extremely unlikely / impossible with low CPU usage.

Do you have a link or more detail about 'already cramped pipelines'?

Re: Desktop compositing latency is real

#283

Post by mark-r »

thesmok wrote: post #272
mark-r wrote: post #178

Earlier quoted context omitted.

I don't understand why someone hasn't come out with a dedicated keyboard chip yet. If it's cheap enough you don't need to run all the keys to a single chip, you could have multiple chips that all talk over a serial bus to one that it designated the master.

Another layer of serial interfaces would make it even slower.

Depends on the speed/latency of the interface. Although you could probably say the same about the scanning matrix too.

Re: Desktop compositing latency is real

#284

Post by lucaspiller »

aduitsis wrote: post #32
ino wrote: post #29

Earlier quoted context omitted.

I have the same monitor and it's pretty good. The only thing I don't quite like is the pixel size, it's a bit small for native scaling. I kind of wish i had gone for the 27". I went with two 25" because two 27" were a bit too big for me.

P2715Q user here. One of the best monitors currently available, excellent color reproduction, top of the line quality. The 4K resolution however is a major problem when you are using Windows 7. Some applications will not play correctly when you try to scale up and at the end you get a mess. Windows 10 is better, but not perfect.

I have a LG 27UD68-P (and just ordered a second one) and have found it pretty good for programming. Here in Europe they come with a swivel stand. The only real disadvantage compared to the Dell is they don't have DisplayPort daisy-chaining, but they support HDMI 2.0 so you can use that for 4k60.

Re: Desktop compositing latency is real

#285

Post by floatboth »

nwah1 wrote: post #47

I wonder if any compositing window managers support FreeSync. That could help significantly, for any v-sync related latency. Vulkan rendering would help as well.

FreeSync only helps when you're running a GPU heavy game that can't keep up with the monitor's refresh rate (dips below 60/120/144/whatever Hz). All desktop compositors definitely can and do render at your monitor's refresh rate :)

Vulkan wouldn't help much. It has less overhead (no validation in production, etc.), but GL/GLES are plenty fast for any compositing tasks. The difference might be completely negligible.

Re: Desktop compositing latency is real

#286

Post by BoorishBears »

abiox wrote: post #239
p1esk wrote: post #189

Earlier quoted context omitted.

Why not go with 5k 27" monitor? http://www.dell.com/en-us/work/shop/cty/pdp/spd/dell-up2715k... Sure, it's over $1k, but if you're making $10k/mo writing code on it, then you should be able to afford it.

> if you're making $10k/mo writing code on it hah... if only the world was silicon valley.

I mean, even in SV after taxes is that really a common salary?

Re: Desktop compositing latency is real

#287

Post by pcwalton »

Const-me wrote: post #281
roel_v wrote: post #267

Earlier quoted context omitted.

Overdraw doesn't just use some CPU. If that would be all, it'd be an easy problem to solve. It causes extra data to be transferred over various buses, extra stops in a pipeline of operations that is already cramped trying to provide a frame every few ms, and probably other problems that I don't know about. This problem isn't as easy as 'throw some more CPU at it'.

I think it’s only that complex and taxing for GUI frameworks that mix CPU and GPU rendering. Like Win32 GDI or GTK+. For modern GUI frameworks that were designed for GPU, like MS WPF/XAML or Mozilla WebRender, overdraw just use some GPU resources, but that’s it. GPUs are designed for much more complex scenes. In-game stuff like particles, lights, volumetric effects, and foliage involve tons of overdraw. In comparison…

Overdraw actually matters quite a bit for integrated GPUs, especially on HiDPI. On high-end NVIDIA or AMD GPUs, sure, 2D overdraw doesn't matter too much. But when power is a concern, you don't want to be running on the discrete GPU, so it's worth optimizing overdraw.

Re: Desktop compositing latency is real

#288

Post by pcwalton »

CyberDildonics wrote: post #282
roel_v wrote: post #267

Earlier quoted context omitted.

Overdraw doesn't just use some CPU. If that would be all, it'd be an easy problem to solve. It causes extra data to be transferred over various buses, extra stops in a pipeline of operations that is already cramped trying to provide a frame every few ms, and probably other problems that I don't know about. This problem isn't as easy as 'throw some more CPU at it'.

That seems like a dubious claim to me. In my experience maxing out memory or pcie bandwidth is rarely a bottleneck, and extremely unlikely / impossible with low CPU usage. Do you have a link or more detail about 'already cramped pipelines'?

2D rendering on GPUs is almost entirely memory bound.

Source: I've been working on GPU 2D rendering full time for years now.

Re: Desktop compositing latency is real

#289

Post by Retric »

CyberDildonics wrote: post #171
Jasper_ wrote: post #116

Earlier quoted context omitted.

Right, the issue is that 60Hz is ridiculously slow. Ethernet hardware is multiple orders of magnitude faster. It's just because of broadcast TV and CRT legacy. G-Sync / FreeSync allow up to 240Hz, which is ~4ms latency.

No, the issue was that he was using a display with a crazy amount of buffering because they were doing so much filtering and doing it poorly.

It's not just monitors even keyboards can have 40+ms worth of delay and it all adds up.

Re: Desktop compositing latency is real

#290

Post by Retric »

astrodust wrote: post #190
frik wrote: post #119

Earlier quoted context omitted.

Actually not a bad idea. Ethernet speed is one gigabit per second. And there are high throughput devices like LIDARs (eg Velodyne LiDAR known from Google/Waymo self-driving cars) that are connected via Ethernet rather than USB. Having 1 GBit Ethernet LAN network since 2004, I would prefer the possibility to upgrade to 10Gbit home Ethernet in near future.

It's a terrible idea. USB-3 is faster than 1Gbit/s. and there's no way you can drive a 5K monitor with any current or near future Ethernet standard, the bandwidth demands are too punishing. Ethernet isn't optimized around short-haul signals, like computer to screen over a few metres at most, it's for 100m+ runs in datacentres. The signals have to be a lot more durable.

5120 * 2880 * 32bits * 60FPS is only 28.3 Gbit and both 40Gbit and 100Gbit are well established standards.

Granted 40GB cards are running 50$ and 100Gbit cards are running ~700$, but that's most from the low volumes involved.

Really though the larger issue is Ethernet connectors are not designed to be plugged in and removed regularly.

Post reply on HN