Profile

Cover photo
X.Org Foundation
721 followers|243,598 views
AboutPostsYouTube

Stream

X.Org Foundation

Shared publicly  - 
 
Another excellent +LWN.net article from XDC2016, explaining the situation with Graphics Memory allocation and the result of a lot of discussions that happened during the conference.

For NVIDIA users, this will mean wayland support with the proprietary driver. For everyone else, it will mean faster performance due to optimally selecting the buffer type that brings the most performance for all the consumers of the buffer.
15
4
Add a comment...

X.Org Foundation

Shared publicly  - 
 
Radv, the community radeon driver for AMD GPUs, can now run Talos principle!

Congrats to +Dave Airlie and +Bas Nieuwenhuizen!
 
yay radv and Talos working!

The answer is YES!! I fixed the last bug with instance rendering and Talos renders great on radv now. Also with the semi-interesting branch vkQuake also renders, there are some upstream bugs that needs fixing in spirv/nir that I'm awaiting and upstream resolution on, but I've included some prelim…
4 comments on original post
7
Vincent Beers's profile photo
 
Good work!
Add a comment...

X.Org Foundation

Shared publicly  - 
4
Add a comment...

X.Org Foundation

Shared publicly  - 
 
The XDC has started and so has the livestream!
7
Add a comment...

X.Org Foundation

Shared publicly  - 
1
Add a comment...

X.Org Foundation

Shared publicly  - 
 
LWN attended the XDC and already released some articles about the talks:

Google's ARC++ (Android Runtime for Chrome): https://lwn.net/Articles/701964/
Anatomy of a vulkan driver: https://lwn.net/Articles/702021/
Mainlining android explicit fences: https://lwn.net/SubscriberLink/702339/824eb353e632b642/
Discussions around High Dynamic Range displays for Linux: https://lwn.net/SubscriberLink/702563/8d0f1bee71fb1ba1/
A libinput update: https://lwn.net/SubscriberLink/702998/9eedff9aed5a9bd5/
12
4
Add a comment...

X.Org Foundation

Shared publicly  - 
 
A nice overview of the current state of the Vulkan ecosystem. Thanks +Jason Ekstrand.
 
PSA: Just because a Vulkan application works ok on one driver (or version of a driver) and not on another doesn't mean that driver is broken.

This is something I hear all the time: "The Intel driver is broken because X app doesn't work". In my experience debugging these issues, I have see about as many (maybe more?) application bugs than bugs in our driver. Frequently, there are bugs on both sides that have to get fixed before an application will work. How does this happen? Part of the reason is that Vulkan is a new API and things are still maturing, but there's more to it than that.

One of the things about Vulkan that's different from GL is that it requires the application to pass in a lot of redundant or possibly unneeded information. No Vulkan implementation needs 100% of the information the client provides so some of it will get thrown away. If the application is missing some of this information or if it is inconsistent in any way, this can easily cause the application to fail on one driver and work on another without either driver having a bug. The solution to this is a set of validation layers that application developers are supposed to use when developing their application. These layers cross-check the information provided by the application and try to ensure that they provide all of the needed information and that it's consistent. Unfortunately, those layers are somewhat incomplete and application bugs of this type still leak through. The layers are constantly improving, but there are still bits and pieces missing.

There are also driver bugs. Our driver, I'm sure, still has a lot of them. In order to try and improve driver quality and keep the bugs down, the Khronos group has been developing a test suite called the Vulkan CTS. Driver writers are expected to run and pass these tests if they want to ship a driver and call it conformant. Unfortunately, the test suite still has a lot of coverage holes and driver bugs can easily go unnoticed. With GL, the situation is a bit different. There are a multiple test suites out there and also a huge number of applications that are exercising many driver paths that the tests don't. With Vulkan, there are only a few of Vulkan applications that run on Linux so we basically have to rely on the CTS for ensuring that our driver works correctly.

So how do all of these applications run on AMD and NVIDIA out-of-the box? If the driver and validation situation is so bad, how does anything work? Well, first off, it's not that bad, and it's improving every day. But the real answer is, "lost of testing." Most applications (especially games) are primarily developed and tested against AMD and NVIDIA's implementations (and sometimes Quallcom because they support Android) so they naturally work there. Also, all of the driver teams are pulling applications and testing them to try and find bugs in the applications and their drivers and get them fixed as quickly as possible. Some driver teams have more time available for this sort of preemptive debugging than others.

What can you do as an app developer or user? First, if you find bugs, report them. We are dedicated to making our Vulkan driver as good as it can be but we can't fix bugs we don't know about. One of the most frustrating things for me as a driver developer is to see users complaining on internet forums about how our driver is crap because it has some bug and doesn't run their favorite app but they've never bothered to report it. Second, have patience and update regularly. When we come across applications that don't work, we try to get the bugs, whether in our driver or in the application, resolved as quickly as we can. However, it takes time to get the bugs resolved and for driver and application updates to get pushed out.

Finally, please use our driver! The more Vulkan applications that are out there and the more people we have running them on our driver, the better it will be.
8 comments on original post
3
Add a comment...

X.Org Foundation

Shared publicly  - 
 
Hey everyone,

If you attended the XDC 2016 in Helsinki or watched the livestream, we would appreciate if you could send us your feedback.

As organizers, we do not have the same view at all of the event, and since there were so many new comers, we would really love to get axes of improvement for next year's XDC!

Please answer to this thread or send a private email to board@foundation.x.org.

Thanks a lot!
6
Add a comment...

X.Org Foundation

Shared publicly  - 
2
Trevor Woerner's profile photoMartin Peres's profile photo
4 comments
 
You're welcome ;)
Add a comment...

X.Org Foundation

Shared publicly  - 
4
Add a comment...

X.Org Foundation

Shared publicly  - 
4
2
Add a comment...

X.Org Foundation

Shared publicly  - 
 
XDC 2016 is about 1 week away now and, today, we passed the three digits for the number of attendees!

This is about twice as many attendees as a typical XDC, but is also smashing the previous record holder (XDC 2014) which had 81 attendees.

We are very happy about this, as it will allow us to meet new faces and will improve collaboration across companies and individuals, which is one of the main purpose of the X.Org Foundation.

See you in Helsinki!
XDC2016 Attendees. Please add yourself to this list along with your employer, ordered by surname (aka 'family name'). If you do not have an employer or if it isn't affiliated to the Graphics Stack, write your topic of interest or the project you work on. Please subscribe to events@lists.x.org ...
11
Add a comment...
Story
Tagline
Non-profit foundation supporting the development & promotion of the free graphics software stack (X11, Mesa, DRI, Wayland, etc.).
Introduction
The goal of this page is to keep you up to date with the X.org Foundation state and all the projects it is managing.

We'll try to link you to the videos related to X.org/DRM/Mesa/Wayland, talks and articles. Don't hesitate to suggest us links to share!
Contact Information
Contact info
Email