Nouveau - Oct 2017 - Project ideas for GSoC/EVoC

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

* 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?)

* initial Vulkan driver

* OpenCL
** finishing up what we already have
** pass the CTS

* experimental nir support (why not if somebody wants to spend time on this?)

* some super difficult compiler optimizations
** which ones indeed?

* random reclocking stuff
** big enough for an entire GSoC/EVoC project?
** Roy, Ben: Status on Fermi/Tesla

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.

Many thanks,

Karol

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.
> 
> * 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!
> 
> * 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 ;)
> 
> * 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
> 
> 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!

Martin

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