On Tue, Sep 24, 2013 at 4:48 AM, Chris Cappuccio <ch...@nmedia.net> wrote:
> Paul de Weerd [we...@weirdnet.nl] wrote: > > > > Probably the updates to your (now graphical) terminal. Time is spent > > updating the frame buffer. Consider it a feature: you can now > > (better) read along with what's happening ;) > > > > A workaround is to start processes that produce lots of output in a > > shell that isn't constantly outputting to the actual display (e.g. in > > a VT but switch away after starting, or in tmux but switch to another > > window after starting...) > > > > On most hardware, the text console under KMS really shouldn't > be bad at all. Hardware that is very old but still supported > by inteldrm will be much slower. It might be worth discussing > text/VT console slowdowns with KMS on misc if you're using > something newer than an intel 828xx video setup. Text mode > performance is within the domain of the kernel's video code. > Mark Kettenis tried some tricks that made text quite fast, but > hung some chips, so the OpenBSD code was reverted to match Linux. > > Under X, KMS performance should be faster on a lot of > hardware. The whole point of KMS is to bring modern, better > supported drivers to OpenBSD (and get rid of the crappy X > security model). If something performs worse under X+KMS, > that may be worth discussing too. X performance depends on > both the kernel and the X video driver. There are constant > iterations happening here. It's nice to see regular updates of > vendor-supported graphics code going into the tree. > > This stuff will keep evolving before the 5.5 release. > > KMS also gives people a chance to play with stuff like Wayland. > Wayland which attempts to get rid of the inefficiencies of the > X protocols. > > This "may" help in long run for Nvidia graphics http://lists.freedesktop.org/archives/nouveau/2013-September/014480.html
