[garbear]

@da-anda @garbear
I don't currently have enough free time to create any soft shader and proposal before the GSoC deadline, and i am sort of overworked from creating proposals and working on demos the whole past week.
I am, however, willing to contribute to this feature in my free time after the following week (uni exams), to get some more experience with C++ and explore the rendering pipeline of Kodi.

guess who started hacking on kodi and stuck with it after a rejected GSoC proposal?

[FREEZX]

@da-anda @garbear
I don't currently have enough free time to create any soft shader and proposal before the GSoC deadline, and i am sort of overworked from creating proposals and working on demos the whole past week.
I am, however, willing to contribute to this feature in my free time after the following week (uni exams), to get some more experience with C++ and explore the rendering pipeline of Kodi.

guess who started hacking on kodi and stuck with it after a rejected GSoC proposal?

Oh, cool.
I generally contribute to projects i'm regularly using and i find interesting.

I submitted my proposal and i'll post here once i do the soft "shader" demo.

[da-anda]

FREEZX - you wrote something about nVidia shader models on Melange. These are not exclusive to nVidia GPUs, are they? Because whatever we add has to be as generic as possible.

As for the integration into Kodi for your project. It would be cool if your retroplayer specific implementation would already use our GUI engine to do it. So ideally apply the shader to the GUI component that's related to the video/game rendering (via some skin param etc). Or for things like simple overlay shaders (overlaying an old TV or arcade controlers etc) there could be a separate overlay GUI element. Just some ideas that might work.

[FREEZX]

@da-anda

No, Cg is just a language made by Nvidia to easily create shaders that work both with Directx and OpenGL. They work with everything that supports OpenGL and Directx.

I had that in my mind, as i have noted that there are already some shaders here https://github.com/xbmc/xbmc/tree/2228e7...em/shaders , some of which are GUI-related.
And overlays could definetely be done by using plain GUI elements rather than shaders, but i am mainly concentrating on shaders because they are more complex and thus problematic.

[sarbes]

we will need to identify where in the rendering pipeline to inject our transformations (probably multiple places and for multiple [directx/gl] APIs), and then build an API around this for shader/overlay add-ons. In concept this is very similar to audio DSP add-ons. I haven't read through the code in that branch yet, but it might offer some insights.

I would love an easy to use modular rendering pipeline. I would code it right away if my C++ was better.


The basic pipeline should look like this:
YUV pre-processing > YUV to RGB conversion > RGB (pre-)processing > Scaling > Post-processing

The shader system should support the in- and output of textures and variables. A bonus would be the possibility to access the next and the previous frame(s).


@FREEZX: I would support this project as good as I can.

[Maxoo]

So.. Has this project been accepted ?
If not, do you still plan on doing it ? Or could you add blur support to the skinning engine ? It needs shader knowledge, and has been requested many times by skinners. It would bring all new possibilities to XBMC skins !

[natethomas]

So.. Has this project been accepted ?
If not, do you still plan on doing it ? Or could you add blur support to the skinning engine ? It needs shader knowledge, and has been requested many times by skinners. It would bring all new possibilities to XBMC skins !

It has not, but that's partly because it was withdrawn by the time we were accepting projects. Not sure why.

[Maxoo]

Hum... I'll get we'll see how this plays out then