6 ms·

BeOS and Haiku allowed exposure to kernel graphics buffers decades ago (https://www.haiku-os.org/legacy-docs/bebook/BDirectWindow.html https://www.haiku-os.org/

• pjmlp 3y ago
  Like most OSes where the desktop APIs are part of the whole developer experience, and not yet another pluggable piece.
• tmountain 3y ago
  BeOS was truly ahead of its time. It’s a shame that it didn’t get more traction.
  • ris 3y ago
    There must be a name for the logical fallacy I see whenever someone pines over a past "clearly superior" technology that wasn't adopted or had its project cancelled, but I can never grasp it. I guess the closest thing to it is an unfalsifiable statement. The problem comes from people remembering all of the positive traits (often just promises) of a technology but either forgetting all the problems it had or the technology never being given enough of a chance for people to discover all the areas in which it is a bit crap. BeOS? Impressive technology demo. Missing loads of features expected in a modern OS, even at that time. No multi-user model even! This is also a big phenomenon in e.g. aviation. The greatest fighter jet ever is always the one that (tragically!) got cancelled before anyone could discover its weaknesses.
    • darkwater 3y ago
      This, plus nostalgia pink glasses plus rooting for the underdog (who lost) plus my niche tech is better than your mainstream one.
    • AshamedCaptain 3y ago
      > There must be a name for the logical fallacy I see whenever someone pines over a past "clearly superior" technology that wasn't adopted or had its project cancelled, but I can never think of it. I guess the closest thing to it is an unfalsifiable statement. You can run Haiku today, so it's hardly unfalsifiable, nor an effect of nostalgia or whatever way you want to phrase it. > BeOS? Impressive technology demo. Missing loads of features expected in a modern OS, even at that time. No multi-user model even! "Even at that time" is just false. multi-user safe OSes abound in the 90s?
      • dihrbtk 3y ago
        Windows NT...?
      • ris 3y ago
        > You can run Haiku today, so it's hardly unfalsifiable Excellent, so let's falsify it: how come 20 years later the best thing people really have to say about BeOS/Haiku is that is has smooth window dragging? > multi-user safe OSes abound in the 90s? Windows NT. Linux and at least two other free unixes. Countless proprietary unixes. VMS. The widespread desktop OSs in the 90s were not considered serious OSs even then, more accidents of backward-compatibility needs.
        • tialaramex 3y ago
          The thing about Haiku is that their plan (initially as "OpenBeOS") was since they're just re-doing BeOS and some of BeOS is Open Source they'll just get some basics working then they're right back on the horse and in a few years they'll be far ahead of where BeOS was. Over two decades later they don't have a 1.0 release.
    • cmrdporcupine 3y ago
  • timetraveller26 3y ago
    I was greatly impressed with BeOS filesystem SQL'esque indexing and querying.
• fulafel 3y ago
  You can bypass the compositor with X11 hw acceleration features too. But what about Wayland? I thought apps always go through the compositor there. As shown eg in the diagram at https://www.apertis.org/architecture/wayland_compositors/ https://www.apertis.org/architecture/wayland_compositors/ Drawing directly from app to kernel graphics buffers (or hw backed surfaces) and participating in composition are orthogonal I think. The compositor may be compositing the kernel or hw backed surfaces.
  • arghwhat 3y ago
    Bypassing composition is a key feature in Wayland. The protocols are all written with zero-copy in mind. The X11 tricks are already there, forwarding one clients buffers straight to hardware, while the end-game with libliftoff is offloading multiple subsurfaces directly to individual planes at once. The compositor is the entire display server in Wayland, and is also the component responsible for bypassing composition when possible.
    • fulafel 3y ago
      In my meager understanding which I'm happy to be corrected about: In a windowed scenario (vs fullscreen), in both the X direct-rendering and Wayland scenarios the application provides a (possibly gpu backed) surface that the compositor uses as a texture when forming the full screen video output. In a full-screen case AFAIK it's possible to skip the compositing step with X11, and maybe with Wayland too. "Zero copy" seems a bit ambiguous term in graphics because there's the kind of copying where whole screen or window sized buffers are being copied about, and then there are compositing operations where various kinds of surfaces are inputs to the final rendering, where also pixels are copied around possibly several times in shaders but there aren't necessary extra texture sized intermediate buffers involved.
      • arghwhat 3y ago
        > In a full-screen case AFAIK it's possible to skip the compositing step with X11, and maybe with Wayland too. This is the trivial optimization all Wayland compositors do. The neater trick is to do this for non-fullscreen content - and even just parts of windows - using overlay planes. Some compositors have their own logic for this, but libliftoff aims to generalize it. Zero-copy is not really ambiguous, but to clarify: Wayland protocols are designed to maximize the cases where a buffer rendered by a client can be presented directly by the display hardware as-is (scanned out), without any intermediate operations on the content. Note "maximize" - the content must be compatible with hardware capabilities. Wayland provides hints to stay within capabilities, but a client might pick a render buffer modifier/format that cannot be scanned out by the display hardware. GPUs have a lot of random limitations.
• AshamedCaptain 3y ago
  To this day, moving a Haiku window under a 5k unaccelerated EFI GOP framebuffer still feels _significantly_ faster than doing the same under Windows 11, and everything KWin's X/Wayland has to offer on the same hardware (AMD Navi 2 GPU). > BeOS and Haiku allowed exposure to kernel graphics buffers decades ago In any case, X also allowed this for ages, with XV and XShm and the like. Of course then everyone got rid of this in order to have the GPU in the middle for fancier animations and whatnot, and things went downhill since.
  • baybal2 3y ago
    Android has horrific UI latency despite heavily employing hardware acceleration. Enlightenments EFL was exclusively software for a long time, but is buttery smooth despite largely using redraw most of the time. Hardware acceleration does not compensate for the lack of hard computer science knowledge about efficient memory operations, caching, and such
    • ElectricalUnion 3y ago
      Hardware acceleration in this case is to draw less power doing day-to-day operations and not melt the user's hand. In the general case most effective hardware acceleration uses are supposed to increase latency. Let's take another example for the analogy: you can run your LLM straight in the CPU and it will have awesome latency and very poor throughput; or you can take your sweet time to load the weights into your GPU/NPU/TPU/memory-in-compute device and run it hardware accelerated at lower energy cost and higher throughput.
  • play_ac 3y ago
    >In any case, X also allowed this for ages, with XV and XShm and the like. No, XShm doesn't do that and the way XV does it is completely dependent on drivers. If you're using Glamour then XV won't use overlays at all. XShm uses a buffer created in CPU memory allocated by the client that the X server then has to copy to the screen. > Of course then everyone got rid of this in order to have the GPU in the middle for fancier animations No, for video, the GPU is used in the middle so you can do post-processing without copying everything into main memory and stalling the whole pipeline. I'd like to see an actual benchmark for how a fullscreen 5k video with post-processing plays on Haiku without any hardware acceleration.
• DonHopkins 3y ago
  That's also how SunView worked on SunOS in 1982, and Sun's later GX graphics accelerated framebuffer driver worked in the 90's. The kernel managed the clipping list, and multiple processes shared the same memory, locking and respecting the clipping list and pixel buffers in shared memory (main memory, not GPU memory!), so multiple process could draw on different parts of the screen efficiently, without incurring system calls and context switches. https://en.wikipedia.org/wiki/SunView https://en.wikipedia.org/wiki/SunView Programmers Reference Manual for the Sun Window System, rev C of 1 November 1983: Page 23, Locking and Clipping: http://bitsavers.trailing-edge.com/pdf/sun/sunos/1.0/800-1092-01_Programmers_Reference_Manual_for_the_Sun_Window_System_Nov83.pdf http://bitsavers.trailing-edge.com/pdf/sun/sunos/1.0/800-109... But GPUs change the picture entirely. From what I understand by reading the article, GTK uses GL to render in the GPU then copies the pixels into main memory for the compositor to mix with other windows. But in modern GPU-first systems, the compositor is running in the GPU, so there would be no reason to ping-pong the pixels back and forth between CPU and GPU memory after drawing 3D or even 2D graphics with the GPU, even when having different processes draw and render the same pixels. So I'm afraid Wayland still has a lot of catching up to do, if it still uses a software compositor, and has to copy pixels back from the GPU that it drew with OpenGL. (Which is what I interpret the article as saying.) More recently (on an archeological time scale, but for many years by now), MacOS, Windows, iOS, and Android have all developed ways of sharing graphics between multiple processes not only in shared main CPU memory, but also on the GPU, which greatly accelerates rendering, and is commonly used by web browsers, real time video playing and processing tools, desktop window managers, and user interface toolkits. There are various APIs to pass handles to "External" or "IO Surface" shared GPU texture memory around between multiple processes. I've written about those APIs on Hacker News frequently over the years: https://news.ycombinator.com/item?id=13534298 https://news.ycombinator.com/item?id=13534298 DonHopkins on Jan 31, 2017 | parent | context | favorite | on: Open-sourcing Chrome on iOS It's my understanding that only embedded WKWebViews are allowed to enable the JIT compiler, but not UIWebViews (or in-process JavaScriptCore engines). WKWebView is an out-of-process web browser that uses IOSurface [1] to project the image into your embedding application and IPC to send messages. So WKWebView's dynamically generated code is running safely firewalled in a separate address space controlled by Apple and not accessible to your app, while older UIWebViews run in the address space of your application, and aren't allowed to write to code pages, so their JIT compiler is disabled. Since it's running in another process, WkWebView's JavaScriptEngine lacks the ability to expose your own Objective C classes to JavaScript so they can be called directly [2], but it does include a less efficient way of adding script message handlers that call back to Objective C code via IPC [3]. [1] https://developer.apple.com/reference/iosurface https://developer.apple.com/reference/iosurface [2] https://developer.apple.com/reference/javascriptcore/jsexport/ https://developer.apple.com/reference/javascriptcore/jsexpor... [3] https://developer.apple.com/reference/webkit/wkusercontentcontroller/1537172-addscriptmessagehandler?language=objc https://developer.apple.com/reference/webkit/wkusercontentco... https://news.ycombinator.com/item?id=18763463 https://news.ycombinator.com/item?id=18763463 DonHopkins on Dec 26, 2018 | parent | context | favorite | on: WKWebView, an Electron alternative on macOS/iOS Yes, it's a mixed bag with some things better and others worse. But having a great JavaScript engine with the JIT enabled is pretty important for many applications. But breaking up the browser into different processes and communicating via messages and sharing textures in GPU memory between processes (IOSurface, GL_TEXTURE_EXTERNAL_OES, etc) is the inextricable direction of progress, what all the browsers are doing now, and why for example Firefox had to make so many old single-process XP-COM xulrunner plug-ins obsolete. IOSurface: https://developer.apple.com/documentation/iosurface?language=objc https://developer.apple.com/documentation/iosurface?language... https://shapeof.com/archives/2017/12/moving_to_metal_episode_iii.html https://shapeof.com/archives/2017/12/moving_to_metal_episode... GL_TEXTURE_EXTERNAL_OES: https://developer.android.com/reference/android/graphics/SurfaceTexture https://developer.android.com/reference/android/graphics/Sur... http://www.felixjones.co.uk/neo%20website/Android_View/ http://www.felixjones.co.uk/neo%20website/Android_View/ pcwalton on Dec 27, 2018 | prev [–] Chrome and Firefox with WebRender are going the opposite direction and just putting all their rendering in the chrome process/"GPU process" to begin with. DonHopkins on Dec 27, 2018 | parent [–] Yes I know, that's exactly what I meant by "breaking up the browser into different processes". They used to all be in the same process. Now they're in different processes, and communicate via messages and shared GPU memory using platform specific APIs like IOSurface. So it's no longer possible to write an XP/COM plugin for the browser in C++, and call it from the renderer, because it's running in a different process, so you have to send messages and use shared memory instead. But then if the renderer crashes, the entire browser doesn't crash. https://news.ycombinator.com/item?id=20313751 https://news.ycombinator.com/item?id=20313751 DonHopkins on June 29, 2019 | parent | context | favorite | on: Red Hat Expecting X.org to “Go into Hard Maintenan... Actually, Electron (and most other web browsers) on the Mac OS/X and iOS use IOSurface to share zero-copy textures in GPU memory between the render and browser processes. Android and Windows (I presume, but don't know name of the API, probably part of DirectX) have similar techniques. It's like shared memory, but for texture memory in the GPU between separate heavy weight processes. Since simply sharing main memory between processes wouldn't be nearly as efficient, requiring frequent uploading and downloading textures to and from the GPU. Mac OS/X and iOS IOSurface: https://developer.apple.com/documentation/iosurface?language=objc https://developer.apple.com/documentation/iosurface?language... http://neugierig.org/software/chromium/notes/2010/08/mac-accelerated-rendering.html http://neugierig.org/software/chromium/notes/2010/08/mac-acc... https://github.com/SimHacker/UnityJS/blob/master/notes/IOSurface.txt https://github.com/SimHacker/UnityJS/blob/master/notes/IOSur... Android SurfaceTexture and GL_TEXTURE_EXTERNAL_OES: https://developer.android.com/reference/android/graphics/SurfaceTexture https://developer.android.com/reference/android/graphics/Sur... https://www.khronos.org/registry/OpenGL/extensions/OES/OES_EGL_image_external.txt https://www.khronos.org/registry/OpenGL/extensions/OES/OES_E... https://docs.google.com/document/d/1J0fkaGS9Gseczw3wJNXvo_r-O5-SZmTlDvbgn56pdQI https://docs.google.com/document/d/1J0fkaGS9Gseczw3wJNXvo_r-... https://github.com/SimHacker/UnityJS/blob/master/notes/ZeroCopy.txt https://github.com/SimHacker/UnityJS/blob/master/notes/ZeroC... https://github.com/SimHacker/UnityJS/blob/master/notes/SurfaceTexture.txt https://github.com/SimHacker/UnityJS/blob/master/notes/Surfa... https://news.ycombinator.com/item?id=25997356 https://news.ycombinator.com/item?id=25997356 DonHopkins on Feb 2, 2021 | parent | context | favorite | on: VideoLAN is 20 years old today >Probably do a multi-process media player, like Chrome is doing, with parsers and demuxers in a different process, and different ones for decoders and renderers. Knowing that you probably need to IPC several Gb/s between them. Chrome and other browsers and apps, and drivers like virtual webcams, and libraries like Syphon, can all pass "zero-copy" image buffers around between different processes by sharing buffers in GPU memory (or main memory too of course) and sending IPC messages pointing to the shared buffers. That's how the browser's web renderer processes efficiently share the rendered images with the web browser user interface process, for example. And how virtual webcam drivers can work so efficiently, too. Check out iOS/macOS's "IOSurface": https://developer.apple.com/documentation/iosurface https://developer.apple.com/documentation/iosurface >IOSurface Share hardware-accelerated buffer data (framebuffers and textures) across multiple processes. Manage image memory more efficiently. >Overview: The IOSurface framework provides a framebuffer object suitable for sharing across process boundaries. It is commonly used to allow applications to move complex image decompression and draw logic into a separate process to enhance security. And Android's "SurfaceTexture" and GL_TEXTURE_EXTERNAL_OES: https://developer.android.com/reference/android/graphics/SurfaceTexture https://developer.android.com/reference/android/graphics/Sur... >The image stream may come from either camera preview or video decode. A Surface created from a SurfaceTexture can be used as an output destination for the android.hardware.camera2, MediaCodec, MediaPlayer, and Allocation APIs. When updateTexImage() is called, the contents of the texture object specified when the SurfaceTexture was created are updated to contain the most recent image from the image stream. This may cause some frames of the stream to be skipped. https://source.android.com/devices/graphics/arch-st https://source.android.com/devices/graphics/arch-st >The main benefit of external textures is their ability to render directly from BufferQueue data. SurfaceTexture instances set the consumer usage flags to GRALLOC_USAGE_HW_TEXTURE when it creates BufferQueue instances for external textures to ensure that the data in the buffer is recognizable by GLES. And Syphon, which has a rich ecosystem of apps and tools and libraries: http://syphon.v002.info http://syphon.v002.info >Syphon is an open source Mac OS X technology that allows applications to share frames - full frame rate video or stills - with one another in realtime. Now you can leverage the expressive power of a plethora of tools to mix, mash, edit, sample, texture-map, synthesize, and present your imagery using the best tool for each part of the job. Syphon gives you flexibility to break out of single-app solutions and mix creative applications to suit your needs. Of course there's a VLC Syphon server: https://github.com/rsodre/VLCSyphon https://github.com/rsodre/VLCSyphon
• play_ac 3y ago
  No, that isn't allowing exposure to kernel graphics buffers. That's allowing clients to draw to the main framebuffer with no acceleration at all. If you're memory mapping pixels into user space and drawing with the CPU then you're necessarily leaving kernel space. Around the same time X11 had an extension called DGA that did the same thing. It was removed because it doesn't work correctly when you have hardware acceleration. So the optimization only makes sense for a machine like yours with no native drivers. With any kind of GPU acceleration it will actually make things much slower. GTK doesn't do this because it would only be useful for that kind of machine running around 25 years ago.
  • DonHopkins 3y ago
    Shared kernel graphics buffers in main or memory mapped framebuffer device memory are one thing (common in the early 80's, i.e. 1982 SunView using /dev/fb), but does it expose modern shared GPU texture buffers to multiple processes, which are a whole other ball game, and orders of magnitude more efficient, by not requiring ping-ponging pixels back and forth between the CPU and GPU when drawing and compositing or crossing process boundaries?
  • AshamedCaptain 3y ago
    > With any kind of GPU acceleration it will actually make things much slower. GTK doesn't do this because it would only be useful for that kind of machine running around 25 years ago. Precisely one of the points of TFA is be able to use the "25 year old" hardware overlay support whenever possible (instead of the GPU) in order to save power, like Android (and classic Xv) does.
    • play_ac 3y ago
      1. The hardware overlay support is implemented on the GPU. It's not "instead of the GPU". 2. The provided code in Haiku doesn't appear to support overlays. 3. Yes, it's upsetting that a real API wasn't available for this until recently. But, it was of limited practical use without the entire display pipeline being moved to the GPU and without Wayland being established (X11 never had the API quite like this, classic XV is too limited to do what this is doing)
• ris 3y ago
  > After 25 years, GTK joins the party … I mean.. shall we start a list of ways in which BeOS/Haiku have yet to "join the party" that the linux desktop has managed? Juggling the various needs of one hell of a lot more users across a lot more platforms, with a lot more API-consuming apps to keep working on systems which are designed with a lot more component independence is a much harder problem to solve.
  • CyberDildonics 3y ago
    Are you mixing up number of users with technical sophistication?
• pengaru 3y ago
  Wasn't this one of the main security issues with the BeOS architecture? It's not the same thing as what's being done here via Wayland. BeOS is more YOLO style direct access of the framebuffer contents, without solving any of the hard problems (I don't think it was really possible to do properly using the available hardware at the time).
• deleted 3y ago
  [deleted]