[Soc-2014-dev] Weekly Report #7 Viewport FX III

[Jason Wilkins]

This is probably where I'm confused.  I'm not totally sure what I need to
do to officially start a review.  I had Campbell review some code I just
committed a couple of weeks ago, so I thought that would be enough.

Do I need to make a separate patch and then point you guys at it?  If so
I'll do that asap.

The X11 code has gotten to a point that it works, at least for me, but I'm
not sure if there are situations where it might fail.
On Jul 11, 2014 4:42 PM, "Sergey Sharybin" <sergey.vfx at gmail.com> wrote:

> Even so GLX might take some time still, i don't see any reason why not to
> send current patch (which as i understand works on OSX?) to the code review
> system? Sooner all involved developers starts giving a feedback on the
> changes sooner you'll be able to commit stuff to master branch. Doubt
> reviewing such a larger changes would be reviewed sooner than week or so.
>
>
> On Wed, Jul 9, 2014 at 10:52 PM, Antony Riakiotakis <kalast at gmail.com>
> wrote:
>
>> Great, I will make sure to check it out on my linux box too when ready.
>>
>>
>> On 9 July 2014 17:12, Jason Wilkins <jason.a.wilkins at gmail.com> wrote:
>>
>>> It took a bit more time than I expected but I have a GLX implementation
>>> now.  I actually got it to work on OSX, so no need for me to setup a Linux
>>> box. (It didn't take much work to use x11 on osx actually)
>>>
>>> I'll be committing it later today after cleaning it up.
>>>
>>> This is a heads up for Antony since he indicated he wanted to look at
>>> the GLX context class.  It actually works on OSX but there may be a
>>> surprise on Linux so that would be a good idea.
>>>
>>> On Sunday, July 6, 2014, Jason Wilkins <jason.a.wilkins at gmail.com>
>>> wrote:
>>>
>>>> Beside GLX support I just need to get feedback.
>>>>
>>>> On Sunday, July 6, 2014, Antony Riakiotakis <kalast at gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It's not entirely clear to us what the state of the project is. We had
>>>>> agreed before GSOC to have GHOST initialization reviewed and merged as soon
>>>>> as possible, so that we could at least have the basis on which to port the
>>>>> new vertex streaming code.
>>>>>
>>>>> As far as I know this is not achieved yet.
>>>>>
>>>>> I would really rather one target is finished, reviewed and merged
>>>>> first, then move on to other targets.
>>>>> Not doing concentrated work will surely result again in unfinished
>>>>> work and the code in an uncertain state.
>>>>> Let's avoid that this time.
>>>>>
>>>>>
>>>>>
>>>>> On 5 July 2014 16:36, Jason Wilkins <jason.a.wilkins at gmail.com> wrote:
>>>>>
>>>>>> I set a few modest goals last week and I was a little disappointed
>>>>>> that that is about all I was able to do.  Then I realized I lost a couple
>>>>>> of days due to having to go home early one day (a pipe burst) and of
>>>>>> course, the July 4th holiday.
>>>>>>
>>>>>> This week:
>>>>>>
>>>>>> * Extension Shims - This is just a way of reducing the amount of
>>>>>> conditional compilation and branches that can happen due to the different
>>>>>> possible OpenGL APIs that may be available.
>>>>>>
>>>>>> * State Policy - Reducing the number of OpenGL API calls by choosing
>>>>>> a "policy" for each state that results in the fewest calls.  For example I
>>>>>> eliminated a few dozen calls to glBlendFunc by just assuming that the state
>>>>>> is GL_ALPHA/GL_ONE_MINUS_SRC_ALPHA.
>>>>>>
>>>>>> At this point I regretted that I ignored the Game Engine last year
>>>>>> because I'm not completely sure that all my state policies can hold across
>>>>>> all of Blender, BlenderPlayer, and the embedded Game Engine without more
>>>>>> testing.
>>>>>>
>>>>>> Next Week:
>>>>>>
>>>>>> One reason I was conservative about goals last week was that I wanted
>>>>>> to think about my next move, since it wasn't completely clear to be at the
>>>>>> time, but I think I figured it out.
>>>>>>
>>>>>> There is a module called "gpu_immediate" that is meant as a
>>>>>> replacement for immediate mode.  Not a great name since it is more like a
>>>>>> vertex buffer builder and is capable of saving vertex buffers for reuse.
>>>>>>  My goal for this week is to get that module into a reviewable state.
>>>>>>
>>>>>> There is some overlap between it and gpu_buffers and some of the
>>>>>> cases where Blender uses vertex arrays instead of immediate mode that
>>>>>> should be combined to remove the redundancy.  Also I've been meaning to use
>>>>>> vertex array objects for over a year now and I want to get to that.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Soc-2014-dev mailing list
>>>>>> Soc-2014-dev at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/soc-2014-dev
>>>>>>
>>>>>>
>>>>>
>>> _______________________________________________
>>> Soc-2014-dev mailing list
>>> Soc-2014-dev at blender.org
>>> http://lists.blender.org/mailman/listinfo/soc-2014-dev
>>>
>>>
>>
>> _______________________________________________
>> Soc-2014-dev mailing list
>> Soc-2014-dev at blender.org
>> http://lists.blender.org/mailman/listinfo/soc-2014-dev
>>
>>
>
>
> --
> With best regards, Sergey Sharybin
>
> _______________________________________________
> Soc-2014-dev mailing list
> Soc-2014-dev at blender.org
> http://lists.blender.org/mailman/listinfo/soc-2014-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2014-dev/attachments/20140711/f9ce6974/attachment-0001.htm