Speed issue with Intel GM45

[towolf]

following up issue #17:

Regarding speed: What graphics card are you using? gltex should be way faster than any other renderer if you have a modern graphics card.

Intel GM45 on a ThinkPad X301. I think this called gen4.

On low-end machines (like my Intel-Atom N450 with integrated i915) the bblit renderer is still faster, indeed. The reasons why kernel-console or other consoles are faster is probably that they use partial-update-renderers (what I call them). That is, they redraw only the part of the screen that changed. kmscon however, always redraws the whole screen.

This cannot be the whole story. So I compare kmscon and fbterm. fbterm is faster in all respects. time dmesg is 0.26s on kmscon and 0.13s on fbterm, twice as fast. It’s quite striking for full-screen thingies that draw every character. There’s a package called caca-utils, that has cacademo and cacafire, which should be instructive. Mplayer also has a caca output module.
This is superslow in kmscon, it pegs one core only for kmscon.

Since fbterm works like the dumb fallback of kmscon it should not be so much faster.

Also the fbcon standard console is faster in one respect: for fullscreen drawing with character addressing. For normal scrolling like dmesg it is indeed slower: time dmesg is 1.9s

The reason is, that this ensures that I can realiably measure delays. In other words, the console will never be slower under any circumstances. If I implement partial-redraws (which I do intend!) I can never be sure that under other use-cases the terminal may be slower.

But the massive slowdown happens when every character is updated anyway, not for linear scrolling.

[dvdhrm]

I have pushed a small pty speed improvement which should fix some of the problems you see. And then I have added a FPS limit. Could you give it a try? The "time dmesg" thing should now be pretty fast. I haven't checked the other use-cases yet.

I will do this later this afternoon. I will also check your other issues. Thanks!

[towolf]

Yeah, time dmesg is much faster now indeed. But scrolling in vim is still a slightly jerky, i.e., the updates seem irregularly spaced, and the cacademo is still quite sluggish and there is prominent tearing. I find this odd because fbterm and kmscon use the same amount of CPU now: 99% for cacademo and about 20% for kmscon and fbterm. fbterm just looks much smoother.

But in the end I don’t know if this benchmark matters at all.

[dvdhrm]

You have to take into account that terminal applications do not do double-buffering or vsync. That is, imagine vim redraws the screen, then it often clears it first and then draws the new content. If the terminal redraws the framebuffer in between these calls, you will see incomplete screens. xterm suffers from the same problems, btw. And there is no way to avoid this.

However, most terminals added a lot more escape-sequences that allow applications to redraw only parts of the screen so they do not have to clear it etc.

Still, redrawing takes about 70ms on my machine which is way to slow and this is why scrolling or fast animations still look horrible on slower machines. I will try to improve this, but I don't think partial-redraws are a good solution for this.

[dvdhrm]

Could you actually retry with my newest changes? The "bbulk" renderer (which is now default) should improve performance by approx. 30% and the improvements to uterm-video backends should improve it by like 50%. It takes 10-15ms to render on my slow Intel Atom N450. Which is very impressive, I think.

You can use "--dumb" to select the dumb video backend, "--fbdev" to select the fbdev backend, "--render-timing" in combination with "--debug" to print timing information for every frame, "--render-engine=" to select the render engine. Available engines are: "bblit", "bbulk" and "gltex".

Make sure to pass "--dumb" or "--fbdev" if you use the "bblit" or "bbulk" renderers. Otherwise, the 3D accelerated video backend will be used which is horribly slow with these renderers. The 3D accelerated video backend should only be used with the "gltex" backend.

Thanks!
David

[dvdhrm]

I consider this "fixed" now. If there are still speed-problems then please reopen this. But everything works fine on my machine now. Thanks!

[towolf]

You’re right. It’s much better now. I fashioned a test with a function in vim that scrolls complex syntax highlighted buffers up and down and that is really butter smooth now.