Planning Starts For Mesa/Wayland/X.Org Projects This Summer

[phoronix]

Phoronix: Planning Starts For Mesa/Wayland/X.Org Projects This Summer

Upstream projects associated with the X.Org Foundation should begin thinking of possible summer project ideas for GSoC 2016 while students can begin figuring out their proposals if wanting to get involved with open-source graphics/compute development over the summer...

http://www.phoronix.com/scan.php?page=news_item&px=XOrg-2016-GSoC-Idea-Storm

[jf33]

I'm sure there is a lot of useful things that could be done during GSoC 2016. Unfortunately, I don't have time to apply this summer. Anyway, here is an idea, which I'd like to throw in:

The proprietary driver of Nvidia is damn fast. Partly because they use application profiles. Unfortuately, it's a lot of work to optimize a driver for every single AAA game and time would better be invested in general optimizations, bugfixing or more GL features.

But what if there was a way to (almost) automatically generate application profiles? Let's say you have an apitrace (or many) of a game. Now you could write a program which analyses the trace and generates an application profile out of it. The analyzer should automatically answer questions like: Which are the best compiler parameters to optimal shader code? Which error checks are unnecessary?
Still, there would be the need to manually verify that the generated profile doesn't break anything. However this is a task which could be done by people from the community, who are not even programmers (like gamers). Provided there is a public database where anyone can upload his profiles (and rate profiles from others), of course.

What do you think?

[Deavir]

I'm sure there is a lot of useful things that could be done during GSoC 2016. Unfortunately, I don't have time to apply this summer. Anyway, here is an idea, which I'd like to throw in:

The proprietary driver of Nvidia is damn fast. Partly because they use application profiles. Unfortuately, it's a lot of work to optimize a driver for every single AAA game and time would better be invested in general optimizations, bugfixing or more GL features.

But what if there was a way to (almost) automatically generate application profiles? Let's say you have an apitrace (or many) of a game. Now you could write a program which analyses the trace and generates an application profile out of it. The analyzer should automatically answer questions like: Which are the best compiler parameters to optimal shader code? Which error checks are unnecessary?
Still, there would be the need to manually verify that the generated profile doesn't break anything. However this is a task which could be done by people from the community, who are not even programmers (like gamers). Provided there is a public database where anyone can upload his profiles (and rate profiles from others), of course.

What do you think?

Do they even have a way to do profiles now? I would think that would be a project by itself.

I would like to see any OpenGL extension implemented or re-implemented in Vulkan to test case what benefits would be expected and challenges to be overcome.

[uid313]

Vulkan bindings for Python, anyone?

[curaga]

Vulkan bindings for Python

Triple facepalm. Yeah, you totally want to use a single-threaded, very cpu heavy language with an API designed to be extremely low-level to reduce cpu usage from actually usable languages.

[xpue]

single-threaded

When python calls native code, global interpreter lock is disabled.

to reduce cpu usage from actually usable languages

To reduce cpu overhead from driver.

[unixfan2001]

Triple facepalm. Yeah, you totally want to use a single-threaded, very cpu heavy language with an API designed to be extremely low-level to reduce cpu usage from actually usable languages.

Huh? Python isn't single threaded.
Some implementations of it (CPython, for one) may have limited concurrency due to GIL, but that's it. The language itself isn't restricted in any way, in that regard.

And Python bindings for Vulkan absolutely make sense. Python is one of the easiest to understand and most widely used languages out there.
Even if there were no performance benefits, it would be a great learning tool.

[Pecisk]

Huh? Python isn't single threaded.
Some implementations of it (CPython, for one) may have limited concurrency due to GIL, but that's it. The language itself isn't restricted in any way, in that regard.

And Python bindings for Vulkan absolutely make sense. Python is one of the easiest to understand and most widely used languages out there.
Even if there were no performance benefits, it would be a great learning tool.

This. JavaScript and Python bindings are a must - those are two most popular prototyping languages used in market, even for graphics things. As Vulkan API is C and uses objects it shouldn't be that hard to wrap it for Python and JS to use. Gstreamer project already did it for their usage using GLib object