18 Aug 2017

feedPlanet KDE

2017 for Qt Contributors

This is a good year to be a Qt contributor.

There was Qt Day Italy in June. From what I hear, the event was a success. The talks were great and everything worked. This was the sixth Qt Day Italy, so there is tradition behind this event!

Even though it is not a Qt event, KDE Akademy is worth mentioning. Akademy is the annual world summit of KDE, one of the largest Free Software communities in the world. It is a free, non-commercial event organized by the KDE Community. This year Akademy was in Almeria Spain, in late July, 22nd to 27th. KDE has over the years brought many excellent developers to Qt, and they are definitely the biggest open source project using Qt.

Starting now is the QtCon Brasil event in Rio de Janeiro on August 18th to 20th. Taking inspiration from last years QtCon in Berlin, QtCon Brasil the first Qt community event in Brasil. The speaker list is impressive and there is an optional training day before the event. For South-American Qt developers right now is the time and place to be in Rio!

This year Qt Contributors' Summit is being organised as a pre-event to Qt World Summit, and we are calling it Qt Contributors' Days. As is tradition, the event will be run in the unconference style with the twist that topics can be suggested beforehand on the schedule wiki page. Qt Contributors' Days gathers Qt contributors to the same location to discuss where Qt is and what direction it is heading in. The discussions are technical with the people implementing the actual features going into details of their work.

You can register to Qt Contributors' Days at the Qt World Summit site, the nominal fee is to cover the registration expense, if it is an issue, please contact me.

The late summer and autumn are shaping up to be great times for Qt contributors!

The post 2017 for Qt Contributors appeared first on Qt Blog.

18 Aug 2017 10:59am GMT

QtWebEngine on FreeBSD

It's been a long time coming ..

Tobias and Raphael pushed the button today to push QtWebEngine into FreeBSD ports. This has been a monumental effort, because the codebase is just .. ugh. Not meant for third-party consumption, let's say. There are 76 patches needed to get it to compile at all. Lots of annoying changes to make, like explaining that pkg-config is not a Linux-only technology. Nor is NSS, or Mesa, while #include <linux/rtnetlink.h> is, in fact, Linux-only. Lots of patches can be shared with the Chromium browser, but it's a terrible time-sink nonetheless.

This opens the way for some other ports to be updated - ports with QtWebEngine dependencies, like Luminance (an HDR-image-processing application).

The QtWebEngine parts have been in use for quite some time in the plasma5/ branch of Area51, so for users of the unofficial ports, this announcement is hardly news. Konqueror with QtWebEngine underneath is a fine and capable browser; my go-to if I have Plasma5 available at all on FreeBSD.

18 Aug 2017 10:24am GMT

17 Aug 2017

feedPlanet KDE

Plasma 5.11 Wallpaper

Well, it's that time of the year again where I talk about wallpapers!

For those who watched the livestream of the beach wallpaper, you'll notice this isn't what I had been working on. Truth be told after the stream I hit a few artistic blocks which brought progress to a grinding halt. I plan to finish that wallpaper, but for this release I created something entirely different while I decide what to do with it. I enjoyed this "wireframe" effect, and will probably experiment with it again.

This wallpaper is named "Opal", specifically after wood opal resulting from when water carrying mineral deposits will petrify wood it runs across. Wood opal is pretty special stuff, and often it can often look straight out of a fairy tale.


The Plasma 5.11 wallpaper "Opal" is available on the KDE Store.

17 Aug 2017 10:14pm GMT

16 Aug 2017


Simon McVittie: DebConf 17: Flatpak and Debian

The indoor garden at Collège de Maisonneuve, the DebConf 17 venue
Decorative photo of the indoor garden

I'm currently at DebConf 17 in Montréal, back at DebConf for the first time in 10 years (last time was DebConf 7 in Edinburgh). It's great to put names to faces and meet more of my co-developers in person!

On Monday I gave a talk entitled "A Debian maintainer's guide to Flatpak", aiming to introduce Debian developers to Flatpak, and show how Flatpak and Debian (and Debian derivatives like SteamOS) can help each other. It seems to have been quite well received, with people generally positive about the idea of using Flatpak to deliver backports and faster-moving leaf packages (games!) onto the stable base platform that Debian is so good at providing.

A video of the talk is available from the Debian Meetings Archive. I've also put up my slides in the DebConf git-annex repository, with some small edits to link to more source code: A Debian maintainer's guide to Flatpak. Source code for the slides is also available from Collabora's git server.

The next step is to take my proof-of-concept for building Flatpak runtimes and apps from Debian and SteamOS packages, flatdeb, get it a bit more production-ready, and perhaps start publishing some sample runtimes from a cron job on a Debian or Collabora server. (By the way, if you downloaded that source right after my talk, please update - I've now pushed some late changes that were necessary to fix the 3D drivers for my OpenArena demo.)

I don't think Debian will be going quite as far as Endless any time soon: as Cosimo outlined in the talk right before mine, they deploy their Debian derivative as an immutable base OS with libOSTree, with all the user-installable modules above that coming from Flatpak. That model is certainly an interesting thing to think about for Debian derivatives, though: at Collabora we work on a lot of appliance-like embedded Debian derivatives, with a lot of flexibility during development but very limited state on deployed systems, and Endless' approach seems a perfect fit for those situations.

[Edited 2017-08-16 to fix the link for the slides, and add links for the video]

16 Aug 2017 8:50pm GMT

14 Aug 2017


Dave Airlie (blogspot): radv on SI and CIK GPU - update

I recently acquired an r7 360 (BONAIRE) and spent some time getting radv stable and passing the same set of conformance tests that VI and Polaris pass.

The main missing thing was 10-bit integer format clamping for a bug in the SI/CIK fragment shader output hardware, where it truncates instead of clamps. The other missing piece was code for handling f16->f32 conversions according to the vulkan spec that I'd previously fixed for VI.

I also looked at a trace from amdgpu-pro and noticed it was using a ds_swizzle for the derivative calculations which avoided accessing LDS memory. I wrote support to use this path for radv/radeonsi since LLVM supported the intrinsic for a while now.

With these fixed CIK is pretty much in the same place as VI/Polaris.

I then plugged in my SI (Tahiti), and got lots of GPU hangs and crashes. I fixed a number of SI specific bugs (tiling and MSAA handling, stencil tiling). However even with those fixed I was getting random hangs, and a bunch of people on a bugzilla had noticed the same thing. I eventually discovered adding a shader pipeline and cache flush at the end of every command buffer (this took a few days to narrow down exactly). We aren't 100% sure why this is required on SI only, it may be a kernel bug, or a command processor bug, but it does mean radv on SI now can run games without hanging.

There are still a few CTS tests outstanding on SI only, and I'll probably get to them eventually, however I also got an RX Vega and once I get a newer BIOS for it from AMD I shall be spending some time fixing the radv support for it.

14 Aug 2017 3:16am GMT

Eric Anholt: 2017-08-14

This week was spent almost entirely on the VC5 QPU instruction scheduler. This is what packs together the ADD and MUL instruction components and the signal flags (LDUNIF, LDVPM, LDTMU, THRSW, etc.) into the final sequence of 64-bit instructions.

I based it on the VC4 scheduler, which in turn is based on i965's. Being the 5th of these I've worked on, it would sure be nice if it felt like less copy and paste, but it's almost all very machine-dependent code and I haven't come up with a way to reduce the duplication.

The initial results are great:

instructions in affected programs:     116269 -> 71677 (-38.35%)

but I've still got a handful of regressions to fix.

Next up for scheduling is to fill the thrsw and branch delay slots. I also need to pack more than 2 things into one QPU instruction - right we pick two of ADD, MUL, LDUNIF, and LDVPM, but we could do an ADD, MUL, LDVPM, and LDUNIF all together. That should be a small change from here.

Other bits this week:

14 Aug 2017 12:30am GMT