xiaoxiang781216 commented on PR #19911: URL: https://github.com/apache/nuttx/pull/19911#issuecomment-5383912226
> > > > @JorgeGzm why not chain Vinc (user space->upperhalf->vnc lowerhalf->stm lowerfhalf? > > > > > > > > > That is what this does, one level up: fb_updatearea already sees everything the stm lower half is given. > > > A vnc lower half would put the socket back in a kernel thread: 150 KB/s against 2300 KB/s, measured. linum:vnc here is your case already, real LTDC panel mirrored over VNC with the panel driver untouched. > > > > > > but why not fix the kernel implementation to improve the performance directly? I don't see any technology reason make the kernel performance lower than userspace implementation. > > That was @acassis initial request too, so we tried it first: mirror mode was implemented inside drivers/video/vnc and worked, but was abandoned for being about 70% slower sending the same rectangles. > > The cause we hit was in the send path. With the server's socket in a kernel thread, enabling CONFIG_NET_TCP_WRITE_BUFFERS asserted in iob_clone_partial, so we ran it without write buffering and sending became stop-and-wait: 123-187 KB/s measured, against 1017 KB/s from user space on the same board and link. > it's strange that the kernel version can't achieve the same performance as userspace, since sendmsg/recvmsg is a simple wrapper of psock_sendmsg/psock_recvmsg. > We never root-caused that assert, and I am not claiming it is a design limit. If it is a bug worth fixing, that is a change in net/. I propose that the first step would measure the performance of pure vnc driver. If the same problem happens, we can fix it first and apply the similar change to new driver. If not, we can compare the difference between two version and then find the root cause. > > Two structural points on top of that: > > * The server allocates its own framebuffer and registers it as /dev/fbN. There is no interface for serving a framebuffer that already exists, which is what this PR is for. Yes, that's why I suggest that we create a new VNC driver which accept a `fb_vtable_s *` instance from hardware driver and return a new `fb_vtable_s *` to fb driver framework: The new fb_btable_s vnc implementation could intercept all userspace<->driver interaction and forward to vnc protocol. > * The pixel format is chosen at compile time (CONFIG_VNCSERVER_COLORFMT_*), so the server cannot honour the > SetPixelFormat a client sends at run time. > but why not improve the kernel code directly? so, both pure vnc case and vnc/hardware hybird case could get the benefit together. > The driver is used by four configurations, all SAMv7 or sim. We have none of that hardware, so reworking its threading model without being able to validate it on a board would be risky. we can create a new vnc driver, but reuse all vnc protocol code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
