Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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?pag...SoC-Idea-Storm

  • Pecisk
    replied
    Originally posted by unixfan2001 View Post

    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

    Leave a comment:


  • unixfan2001
    replied
    Originally posted by curaga View Post
    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.

    Leave a comment:


  • xpue
    replied
    Originally posted by curaga View Post
    single-threaded
    When python calls native code, global interpreter lock is disabled.

    Originally posted by curaga View Post
    to reduce cpu usage from actually usable languages
    To reduce cpu overhead from driver.

    Leave a comment:


  • curaga
    replied
    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.

    Leave a comment:


  • uid313
    replied
    Vulkan bindings for Python, anyone?

    Leave a comment:


  • Deavir
    replied
    Originally posted by jf33 View Post
    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.

    Leave a comment:


  • jf33
    replied
    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?

    Leave a comment:

Working...
X