Here is an update to the project ideas list for GSoC/EVoC. If there
are no complains within the next few days, I just go ahead and add
them to the wiki page. Many thanks for reviewing and suggesting
changes!
Instruction Scheduler
Difficulty: Difficult
Skills Required: C++
Useful skills: Compilers
Hardware/Software required: NVIDIA Fermi or later
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: Write an instruction scheduling pass for basic blocks in
the nouveau codegen compiler. Create scheduling policies that improve
performance.
Maxwell Accelerated Video Decoding
Difficulty: Medium
Skills Required: C
Useful skills: Reverse Engineering, Video formats
Hardware/Software required: NVIDIA Maxwell GM107 / GM108 chip
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: RE the mechanism for video decoding in VP6 (the video
engine iteration used in GM10x chips). Implement support for driving
the engine.
Kepler Accelerated Video Encoding
Difficulty: Medium-Difficult
Skills Required: C
Useful skills: Reverse Engineering, Video formats
Hardware/Software required: NVIDIA Kepler GKxxx chip
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: RE the video encoding component of Kepler chips and
produce sufficient documentation for an open source implementation
(while reusing blob firmware). A stretch goal would be to integrate
something into nouveau to be able to drive the engine, and a toy
user-space application to encode a video.
Dynamic Reclocking
Difficulty: Medium-Difficult
Skills Required: C
Useful skills: Modeling, control systems, and statistics
Hardware/Software required: A Kepler NVIDIA GPU with a super-reliable
reclocking support and a power sensor
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: Create a performance test rig that will test different
use-cases we want to support for our dynamic reclocking.
This setup will need to be replicable and will serve as a benchmark
for both power consumption and performance. The next step will be to
experiment with different heuristics in the userspace that will poll
the performance counters, and dynamically change the clocks to achieve
the highest possible performance, at the lowest power consumption
possible and with the simplest possible heuristic.
Enabling performance analysis on frameretracer
Difficulty: Medium
Skills Required: C, C++
Useful sills: Qt, OpenGL, Apitrace
Hardware/Software required: Any NVIDIA Tesla or newer
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: Frameretracer is a wonderful tool to find and debug
performance bottlenecks. However, it has been designed for Intel GPUs
and requires changes in both Frameretracer and Nouveau in order to get
the maximum out of the tool. The project would be to make the
necessary changes in both Nouveau and Frameretracer to enable
performance analysis on Nouveau.
Initial Nouveau Vulkan driver
Difficulty: Very Difficult
Skills Required: C, C++, Python
Useful sills: Vulkan
Hardware/Software required: Any NVIDIA Kepler or newer
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: Write an initial vulkan driver, which should pass the
most basic tests from the khronos CTS.
Helping out with Nouveau OpenCL driver
Difficulty: Very Difficult
Skills Required: C++
Useful sills: OpenCL
Hardware/Software required: Any NVIDIA Tesla or newer
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: Helping Pierre Moreau to get his current OpenCL Nouveau
code to a usable state. This will include working a lot on the Nouveau
compiler and improving the OpenCL Gallium state tracker Clover.
experimental NIR support
Difficulty: Medium-Difficult
Skills Required: C, C++
Useful sills: Compiler, Nir
Hardware/Software required: Any NVIDIA Tesla or newer
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: Make it possible for Nouveaus codegen to consume NIR in
addition to TGSI. In the end it should be assessed if using NIR or
spending time on improving the current compiler brings a bigger
benefit to Nouveau in longterm.
Adding new compiler optimization Passes to Codegen
Difficulty: Easy to Difficult
Skills Required: C++
Useful sills: Compiler Optimizations
Hardware/Software required: Any NVIDIA Tesla or newer
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: Add new passes to Nouveaus codegen to improve the current
generated code. This can mean adding a lot of trivial passes or a few
complex one.
Fixing outstanding reclocking issues on already reclockable GPUs
Difficulty: Medium-Difficult
Skills Required: C
Useful sills: Reverse Engineering
Hardware/Software required: Any NVIDIA Tesla, Kepler or Maxwell GPU
Where to ask questions: nouveau at lists.freedesktop.org, #nouveau on
irc.freenode.net
Description: We already support a handful of chipsets quite well.
Fixing last outstanding issues on those would take us a step forward
to actually having dynamic reclocking enabled by default (which we
don't implement yet though)
On Mon, Oct 16, 2017 at 11:43 AM, Karol Herbst <karolherbst at gmail.com>
wrote:> On Mon, Oct 16, 2017 at 12:15 AM, Martin Peres <martin.peres at
free.fr> wrote:
>> On 15/10/17 22:13, Karol Herbst wrote:
>>> Hi everybody,
>>>
>>> currently on the Xorg Wiki page [1] there are only three projects
>>> ideas, two being quite similiar:
>>> 1. Instruction scheduling
>>> 2. Maxwell Video Accel Decoding
>>> 3. Kepler Video Accel Encoding
>>> and also the reference to our Trello board.
>>>
>>> Because I don't expect any student interested in a GSoC/EVoC
project
>>> to read our wiki or trello, I am sure to attract more students, we
>>> should give more project examples, best if those are all in
different
>>> areas of the driver.
>>>
>>> I am fine with writing and adding new ideas on the wiki, but it
would
>>> be nice if you come up with interesting projects as well, so that I
>>> can work on those and add them to the wiki.
>>>
>>> My spontaneous ideas are:
>>>
>>> * Better handling of OOM situations:
>>> ** more swapping to system memory
>>> ** memory usage reporting to userspace
>>
>> That sounds way over the scope of a GSoC.
>
> I talked with Ilia about that a bit on IRC, and it sounded like that
> at least on Fermi, it should be simple enough to reference memory
> inside system memory in draw calls, where we always use vram for now.
> Apparently drm stuff already gets moved out into sysram if not used
> for a draw call or something, maybe not. Needs investigation, but I
> got the impression it would be totally doable, because it wouldn't
> even need to land all at once. But yeah, I see that it could be one of
> the more challenging ones depending on the current situation.
>
>>>
>>> * Performance analysis:
>>> ** what are Noveaus most hit bottlenecks
>>> ** how easy is it to figure those out
>>> ** improve/write tools and nouveaus support for those to figure
those
>>> out (maybe more counters needed, something else?)
>>
>> Yes, this is definitely more doable! Being able to run frameretracer on
>> nouveau would be ideal, as it is an impressive tool to debug
performance
>> issue on Intel platforms (and it may already somewhat work).
>>
>>>
>>> * initial Vulkan driver
>>>
>>> * OpenCL
>>> ** finishing up what we already have
>>> ** pass the CTS
>>
>> Well, I know you are optimistic, but that sounds impossible to someone
>> who is not already a contributor!
>
> The goal shouldn't be to get a 100% passing test. But the CTS is
> something we could measure progress in. And it breaks that splitting
> work into specification/implementation/testing pattern. If for example
> we pass 50% before and 70% after the project, it would be already a
> big help.
>
> Vulkan on the other hand would be too big, right. I still would like
> to put it on the list, because I can imagine there are several people
> interested in vulkan and even if we can't use the results directly the
> student could learn quite a lot and continue with the work if still
> interested. It could be wasted time in the end though.
>
>>
>>>
>>> * experimental nir support (why not if somebody wants to spend time
on this?)
>>
>> Yes, that could be a good one. This is a pretty self-contained project.
>> Not sure this is what we want to be working towards, but anything we
can
>> do to reduce our workload is appreciated :)
>>
>>>
>>> * some super difficult compiler optimizations
>>> ** which ones indeed?
>>
>> I would rather go for implementing a lot of simple ones, and hope that
>> the student will stay long enough to get to the useful ones ;)
>
> fair enough. I think best would be to have a decent mix in the
> proposal. Maybe the student is capable of doing the tricky ones, maybe
> not. I would keep it open and we can adapt in case somebody wants to
> work on that.
>
>>
>>>
>>> * random reclocking stuff
>>> ** big enough for an entire GSoC/EVoC project?
>>> ** Roy, Ben: Status on Fermi/Tesla
>>
>> Big enough? It is big-enough for a decade apparently given how slow we
>> have been :s
>>
>
> yeah... but our problem is time, not that it is super hard and that's
> why we don't finish it. It is still hard, but getting the GPU to run
> faster might be a good motivator for some. At least it was for me.
>
>>>
>>> And because I don't just go ahead and add those things, I also
would
>>> like to get your feedback on the ideas I mentioned here. In the end
I
>>> would like to get 10 or more ideas written down somewhere, maybe
even
>>> on the Xorg wiki page, but then it would be like 50% Nouveau, but
this
>>> shouldn't be our problem.
>>
>> Thanks for doing this, we need to get more contributors, and this is
the
>> first step!
>>
>
> yeah, we really have to.
>
>> Martin
