Language Selection

English French German Italian Portuguese Spanish

Graphics/Benchmarks

Toshiba RC100 NVMe SSD Ubuntu Linux Benchmarks

Filed under
Graphics/Benchmarks

Back in June Toshiba introduced the RC100 NVMe solid-state drive as a new low-end offering. The RC100 is now a bit blindsided by Intel's just-launched 660p SSD that delivers incredible storage capacities per dollar, and I'll have some Intel 660p Linux benchmarks in a few days, but for those curious about the RC100 here are some Ubuntu Linux benchmark results for this low-cost NVMe SSD.

The Toshiba RC100 is a Ball Grid Array (BGA) SSD with the controller and flash memory on a single package. With that the RC100 NVMe SSDs are single-sided and fit on an M.2 2242 PCB rather than the longer and more common M.2 2280 NVMe SSDs. But with being M.2 2242 is limited to PCI Express x2 lanes rather than x4 bandwidth. The RC100 doesn't have any DRAM cache but does support NVMe Host Memory Buffer (HMB) and the drive uses 64 layer BiCS3 3D TLC NAND flash memory.

Read more

X.Org Server 1.20.1

Filed under
Graphics/Benchmarks
  • xorg-server 1.20.1

    This bugfix release fixes several issues in RANDR, Xwayland, glamor, the modesetting driver, and elsewhere. Everyone is encouraged to upgrade. Thanks to all who contributed to this release!

  • X.Org Server 1.20.1 Released With Many Bug Fixes

    As the first point release to X.Org Server 1.20 that debuted in May, xorg-server 1.20.1 is available today with dozens of fixes.

    X.Org Server 1.20.1 is quite a big point release to address the initial fall-out from X.Org Server 1.20 after that release was in development for more than one year and shipped with a ton of changes and new features.

  • X.Org Server 1.20.1 Point Release Addresses Many Bugs including XWayland and Mesa

    The first point release for X.Org Server 1.20 has been released today (xorg-server 1.20.1) and it is chock full of fixes.

    X.Org Server 1.20 was in development for more than a year, but its initial release in May was not exactly smooth, as there were numerous bug fallouts and things that needed adjusting. Fortunately, X.Org Server 1.20.1 is the first point release to address a myriad of issues that were effecting the initial release – which is great news, as this point release is just in time to hopefully make it into the various Linux distros that utilize X.Org Server (Ubuntu 18.10, Fedora 29, etc).

Graphics: Filament and Sway 1.0 Alpha 5

Filed under
Graphics/Benchmarks
  • Google Open-Sources "Filament" PBR Engine Using Vulkan/OpenGL

    Filament is a physically-based rendering engine that has now been open-sourced by Google for Android, Linux, macOS, and Windows systems.

    This physically-based rendering engine is designed to be as small and efficient as possible so that it can scale down and run with ease on Android-based systems. Filament is written in C++ and requires the use of the LLVM/Clang compiler, supports OpenGL 4.1+ / OpenGL ES 3.0+ / Vulkan 1.0 for rendering back-ends, supports a wide range of rendering capabilities, and all-around looks like quite an exciting PBR engine.

  • Sway 1.0 Alpha 5 Brings Multi-GPU Support, Virtual Keyboard Protocol

    The i3-inspired Sway Wayland compositor had already introduced many features ahead of Sway 1.0 while with today's fifth alpha release are yet more new features to advertise.

    Sway 1.0 Alpha 5 was released today and while it's just a few weeks past the alpha 4 milestone, there are more than 250 changes and a number of new features.

Graphics: X.Org Server, RadeonSI, OpenChrome, VKGL, ADriConf/Advanced DRI Configurator

Filed under
Graphics/Benchmarks
  • X.Org Server 1.20 Branch Created, Latest EGLStreams Patches Added

    X.Org Server 1.20 was released back in May while now the "server-1.20-branch" was created at last to allow for X.Org Server 1.21 development to happen on master while letting the point releases to be worked out on the branched code.

    The server-1.20-branch is where the latest code is being staged ahead of the eventual X.Org Server 1.20.1 point release. The branch was just created and has staged some patches so far.

  • RadeonSI Gets Patches For AMD_framebuffer_multisample_advanced (EQAA)

    Last month AMD's Marek Olšák sent out a new extension for the OpenGL registry, AMD_framebuffer_multisample_advanced, and with the latest Mesa patches he has published this week the RadeonSI Gallium3D driver wires in support for this GL extension.

    AMD_framebuffer_multisample_advanced ends up implementing AMD's EQAA: Enhanced Quality Anti-Aliasing. Merged a few months back was EQAA for RadeonSI that is part of Mesa 18.2 but that initial implementation which is activated via an environment variable is just used in place of OpenGL applications otherwise trying to use multi-sample anti-aliasing (MSAA). With AMD_framebuffer_multisample_advanced is now a means for OpenGL games/applications wanting to explicitly target this advanced anti-aliasing mode.

  • OpenChrome DRM Driver To Go Through A GEM/TTM Code Rewrite

    With the OpenChrome DRM/KMS driver for vintage VIA x86 graphics likely to be mainlined in its current code state, the sole developer left working on this driver is going to next rewrite the TTM/GEM memory management code that he also hopes will help in his new ATI RAGE 128 driver initiative.

    The OpenChrome DRM driver that's been struggling for years doesn't look like it will be mainlined in 2018. While it's been sent off for review a few matters have been blocking it from going mainline: the principal challenges are OpenChrome DRM not supporting the modern atomic mode-setting APIs but rather than legacy KMS interfaces and there being a lot of unfinished code left in the driver. When it comes to the unfinished code, the hardware acceleration isn't complete and the upstream DRM driver developers would want that removed before this driver would be hypothetically mainlined.

  • VKGL: An Effort For OpenGL Core Profile Support Over Vulkan

    A few days ago we wrote about GLOVE being open-sourced as OpenGL ES over Vulkan and we were then pointed out to another project: VKGL.

    GLOVE currently is working for OpenGL ES 2.0 over Vulkan with plans for supporting not only newer versions of OpenGL ES but also to achieve at least some desktop OpenGL support. Think Silicon's GLOVE project is quite promising and is cross-platform. Now there is also VKGL that seems to be the project of just one independent developer for getting desktop OpenGL (using a core profile context) over Vulkan.

  • Advanced DRI Configuration Picking Up New Features

    It's been a while since having anything to report on ADriConf but fortunately this graphical utility for configuring some open-source Linux graphics driver features is progressing.

    ADriConf, The Advanced DRI Configurator, is a GUI utility for the configuring open-source graphics drivers that aims to be modern and more featureful compared to the long-standing DriConf. Recent work to ADriConf includes new shortcuts in the menu, build issue fixes/improvements, new test cases added, and proper handling as well with the closed-source graphics drivers.

Graphics: AMDVLK and Mesa

Filed under
Graphics/Benchmarks
  • AMDVLK Radeon Vulkan Driver Updated With 8-Bit Storage Support

    Another weekly code drop has occurred for the "AMDVLK" open-source AMD Radeon Vulkan Linux driver with its XGL/PAL/LLPC.

    On the Vulkan front, the XGL code drop on Friday now exposes the VK_KHR_8bit_storage extension for allowing 8-bit types in uniform/storage buffers and push constant blocks. The updated XGL code also has some fixes and other minor work but the 8-bit storage support is the main addition.

  • EGL Device Support Coming Together For Mesa

    Emil Velikov's latest Mesa work is on implementing support for EGL Device extensions for enumerating and using EGLDevices.

    The extensions Emil has implemented in patch form include EGL_EXT_device_base, EGL_MESA_device_software, EGL_EXT_device_drm, and EGL_platform_device. The EGLDevice extensions allows for bringing up EGL without any underlying/native windowing system API.

  • Adreno A6xx Gallium3D Support Coming Together

    For the past number of months there's been Adreno A600 series support coming together within the MSM DRM kernel driver in large part thanks to Qualcomm / Code Aurora contributing code themselves. Quietly coming together as well is the A6xx Gallium3D support for allowing OpenGL acceleration.

    When it comes to the latest-generation Adreno A6xx hardware, most of the open-source talk has been on the MSM Direct Rendering Manager driver front but it's great to see the Gallium3D/OpenGL driver support being pieced together too. A Phoronix reader pointed out that this work is being staged via this wip/a6xx branch.

A Look At The Clear Linux Performance For July 2018

Filed under
Graphics/Benchmarks

Given our fascination with Intel's Clear Linux performance in the plethora of performance benchmarks we frequently run at Phoronix and this open-source operating system being maintained in a rolling-release style, here's a look at how the performance for this x86_64 Linux distribution evolved over the past month.

For those curious about the performance of Intel's Clear Linux for July 2018, here are benchmarks of its state as of 1 July 2018 to where it was at in ending out the month on 31 July. Tests were done on nine different Intel systems from desktop systems to Xeon workstations/servers.

Clear Linux began July with build 23370 that was using the Linux 4.17 kernel, GCC 8.1.1, and Python 3.6.5 as some of the important versions to point out for this testing. At the end of July they were up to build 24090 with the Linux 4.17.11 kernel, GCC 8.2.0, and Python 3.7, among many other package upgrades and changes throughout the month.

Read more

Mesa Graphics News

Filed under
Graphics/Benchmarks
  • Mesa 18.2 Branched, Mesa 18.3 Enters Development

    As expected, the Mesa 18.2 feature development is now over with the code having branched. Now open on Git master is Mesa 18.3-devel.

    Mesa 18.2 is anticipated for release before the end of August assuming no major release blockers. The first release candidate of Mesa 18.2 should be out shortly and there should be a few more over the month of August.

  • kms_swrast: A hardware-backed graphics driver

    Presenting kms_swrast, a new, hardware-backed, software graphics driver, built upon the Mesa gallium driver framework, which uses kernel kms drm nodes for memory allocation.

  • Collabora's Work On KMS_SWRAST For Android Graphics Fallback

    Robert Foss at Collabora has recently been working on supporting the "kms_swrast" code under Android.

    KMS_SWRAST is a Gallium component that supports utilizing DRM nodes for the memory allocation but for the actual OpenGL rendering still falls back to LLVMpipe (or Softpipe).

Writing a Wayland compositor with wlroots: shells

Filed under
Graphics/Benchmarks

I apologise for not writing about wlroots more frequently. I don’t really enjoy working on the McWayface codebase this series of blog posts was originally about, so we’re just going to dismiss that and talk about the various pieces of a Wayland compositor in a more free-form style. I hope you still find it useful!

Today, we’re going to talk about shells. But to make sure we’re on the same page first, a quick refresher on surfaces. A basic primitive of the Wayland protocol is the concept of a “surface”. A surface is a rectangular box of pixels sent from the client to the compositor to display on-screen. A surface can source its pixels from a number of places, including raw pixel data in memory, or opaque handles to GPU resources that can be rendered without copying pixels on the CPU. These surfaces can also evolve over time, using “damage” to indicate which parts have changed to reduce the workload of the compositor when re-rendering them. However, making a surface and filling it with pixels is not enough to get the compositor to show them.

Shells are how surfaces in Wayland are given meaning. Consider that there are several kinds of surfaces you’ll encounter on your desktop. There are application windows, sure, but there are also tooltips, right-click menus and menubars, desktop panels, wallpapers, lock screens, on-screen keyboards, and so on. Each of these has different semantics - your wallpaper cannot be minimized or dragged around and resized, but your application windows can be. Likewise, your application windows cannot cover the entire screen and soak up all input like your lock screen can. Each of these use cases is fulfilled with a shell, which generally takes a surface resource, assigns it a role (e.g. application window), and returns a handle with shell-specific interfaces for manipulating it.

Read more

Also: Wayland Shells From The Perspective Of WLROOTS

Graphics: GLOVE, Armada DRM Drive, Mesa

Filed under
Graphics/Benchmarks
  • GLOVE: OpenGL ES Over Vulkan As Open-Source

    Think Silicon announced this morning they have open-sourced GLOVE, a middleware layer that implements OpenGL ES over Vulkan.

    GLOVE allows for OpenGL ES to be implemented on top of Vulkan drivers for Android, Linux, and Windows platforms. This allows for OpenGL ES support to be mapped over Vulkan just as DXVK maps Direct3D 11 to Vulkan or MoltenVK maps Vulkan on top of Apple's Metal API. With modern OpenGL ES sharing much in common with OpenGL, it provides much of what's needed by core OpenGL too, albeit not complete OpenGL 4 desktop. In the future they plan to support more desktop OpenGL as well as safety-critical OpenGL (OpenGL SC).

  • Armada DRM Driver Wires In Atomic Mode-Setting For Linux 4.19

    Adding to the big list of DRM driver changes for Linux 4.19 is atomic mode-setting for the Armada DRM driver.

    The Armada DRM driver doesn't get talked about much but it's for Marvell SoCs and just supports kernel mode-setting and memory management but without any built-in acceleration code. The driver is for the "LCD" controllers on the Marvell Armada SoCs.

  • ASTC Gallium Bits Land, VirGL Already Hits OpenGL 4.3 + GLES 3.2

    The mad rush to land last minute work ahead of the Mesa 18.2 branching has continued. The branching is set to happen today but there's been several notable last minute additions hitting Git.

    First up, Marek's work around ASTC compression support for all Gallium3D drivers, has landed. This work is now in place for RadeonSI and the other Gallium drivers to expose Adaptive Scalable Texture Compression (ASTC) even if the GPU doesn't natively support it by uncompressing it to a supported format prior to uploading the texture to the GPU if necessary. With the ASTC support in place for RadeonSI, that takes the driver's OpenGL ES support to version 3.2.

Linux, Linux Foundation and Mesa

Filed under
Graphics/Benchmarks
Linux
  • WireGuard Now Under Review, First Step Towards Getting Included In The Linux Kernel

    After being in development the past few years, the first version of WireGuard has hit the kernel mailing list for review on its path to being included in the mainline Linux kernel.

  • The 4.18 kernel release will be delayed a week

    For those waiting on the edges of their seats for the release of the 4.18 kernel: it looks like Linus will be pushing it back one week (to August 12) in response to some late-discovered problems. "I _prefer_ just the regular cadence of releases, but when I have a reason to delay, I'll delay."

  • Join Interactive Workshop on Cloud-Native Network Functions at Open Source Summit

    ONAP and Kubernetes – two of the fastest-growing Linux Foundation projects – are coming together in the next generation of telecom architecture.  

    ONAP provides a comprehensive platform for real-time, policy-driven orchestration and automation of physical and virtual network functions, and Kubernetes is an open source system for automating deployment, scaling, and management of containerized applications. Telcos are now examining how these virtual network functions (VNFs) could evolve into cloud-native network functions (CNFs) running on Kubernetes.

  • Mesa's VirGL Now Has OpenGL 4.2 Support To Offer Guest VMs

    In the mad rush to land last minute features into Mesa 18.2 prior to its code branching and release candidate phase beginning, David Airlie has settled OpenGL 4.2 support for the VirGL stack.

    Airlie's VirGL work continues for offering guest OpenGL acceleration to virtual machines that in turn is rendered by the host's driver/GPU. It's also through this year's Google Summer of Code 2018 (GSoC 2018) that Vulkan VirGL is a work-in-progress for virtual machines with VirtIO-GPU.

Syndicate content

More in Tux Machines

Software: Virtlyst 1.2.0, Blender 2.8 Plan, Dropbox Gets Worse and DaVinci Resolve 15 Targets GNU/Linux

  • Virtlyst 1.2.0 released
    Virtlyst – a Web Interface to manage virtual machines build with Cutelyst/Qt/C++ got a new release. This new release includes a bunch of bug fixes, most importantly probably being the ability to warn user before doing important actions to help avoid doing mistakes. Most commits came from new contributor René Linder who is also working on a Bootstrap 4 theme and Lukas Steiner created a dockerfile for it. This is especially cool because Virtlyst repository now has 4 authors while Cutelyst which is way older has only 6.
  • Blender 2.8 Planning Update
    At this point we will not have a feature complete Beta release ready in August as we had hoped. Instead, we invested most of our time improving the features that were already there and catching up with the bug tracker. This includes making the viewport and EEVEE work on more graphics cards and platforms. The Spring open movie team is also using Blender 2.8 in production, which is helping us ensure the new dependency graph and tools can handle complex production scenes.
  • Blender 2.80 Now Coming In Early 2019 With Many Improvements
    The Blender 3D modeling software is facing a slight set-back in their release schedule for the big Blender 2.80 release, but it's moving along and they intend to have it ready by early next year.
  • Dropbox will only Support the Ext4 File System In Linux in November
    Dropbox has announced that starting on November 7th 2018, only the ext4 file system will be supported in Linux for synchronizing folders in the Dropbox desktop app. Those Linux users who have synch on other file systems such as XFS, ext2, ext3, ZFS, and many others will no longer have working Dropbox synchronization after this date. This news came out after Linux dropbox users began seeing notifications stating "Dropbox Will Stop Syncing Ext4 File Systems in November." You can see an example of this alert in Swedish below.
  • Dropbox scares users by shrinking synching options
    Dropbox has quietly announced it will soon stop synching files that reside on drives tended by some filesystems. The sync ‘n’ share service’s desktop client has recently produced warnings that the software will stop syncing in November 2018. Those warnings were sufficiently ambiguous that Dropbox took to its support forums to explain exactly what’s going on, namely that as of November 7th, 2018, “we’re ending support for Dropbox syncing to drives with certain uncommon file systems.”
  • DaVinci Resolve 15 Video/Effects Editor Released With Linux Support
    DaVinci Resolve 15 has been released by Blackmagic Design as the company's professional-grade video editing, visual effects, motion graphics, and audio post-production software.

How to display data in a human-friendly way on Linux

Not everyone thinks in binary or wants to mentally insert commas into large numbers to come to grips with the sizes of their files. So, it's not surprising that Linux commands have evolved over several decades to incorporate more human-friendly ways of displaying information to its users. In today’s post, we look at some of the options provided by various commands that make digesting data just a little easier. Read more

today's howtos

KDE and GNOME GSoC: Falkon, WikiToLearn, Nautilus and Pitivi

  • The Joy of GSoC :)
    Wooo... this is the last day of coding phase of GSoC. I am writing this blog to share my experience and work done in the coding phase. I want to specially thank my mentor David Rosca for his help, suggestions and reviews. This was my first exposure to the KDE community and I am proud that it was great. I really enjoyed the whole program from proposal submission - intermediate evals - then now this final evaluation. Also, I had learned a lot working on my project. Frankly speaking, I didn't knew about i18n and l10n much but with the help of my mentor now I have a quite good understanding of how these works and are implemented. I can truly say this was one of my best summer vacations.
  • What’s next for WikiToLearn?
    Google Summer of Code is finishing and many things have been done on WikiToLearn since previous post. A little recap is needed. Talking with mentors has been crucial because they told me to focus on finishing CRUD interaction with API backend instead of working on “history mode” viewer.
  • GSoC 2018 Final Evaluation
    As GSoC is coming to an end, I am required to put my work altogether in order for it to be easily available and hopefully help fellow/potential contributors work on their own projects.  [...] At its prestige, through this project we will have tests both for most critical and used operations of Nautilus, and for the search engines we use. Further on, I’ll provide links for all of my merge requests and dwell a bit on their ins and outs while posting links to my commits:
  • GTK+ 4 and Nautilus </GSoC>
    Another summer here at GNOME HQ comes to an end. While certainly eventful, it unfortunately did not result in a production-ready Nautilus port to GTK+ 4 (unless you don’t intend to use the location entry or any other entry, but more on that later).
  • Pitivi Video Editor Gains UI Polish, Video Preview Resizing
    The latest Google Summer of Code 2018 is allowing some excellent work to be done on some excellent open source projects. Among them Pitivi, the non-linear video editor built using GTK and Gstreamer and offering up a basic video editing feature set. Over the past few months, Harish Fulara, a Computer Science student, has worked on improving the application’s greeter dialog and on adding support dynamic resizing of the video preview box.