Location, Dates, and Times | Mobile World Congress 2013

Event

From 31st of January to 10th of February I participated in openSUSE 12.3 Marketing Hackathon.   The Hackathon took place in SUSE Headquarters [Nuremberg,Germany] from 4/02 to 10/02. Before that we participated in FOSDEM by promoting to the crowd the openSUSE Project and the oSC13 as well. Our participation in FOSDEM was really successful cause people asked a lot of questions around the upcoming release of openSUSE and expressed their interest for this year’s openSUSE Conference.  Thanks to Carlos we spread out and informed a lot of people about the oSC13.

Apart from that this year I spent more time in joining presentations. I admit that I liked more FOSDEM 2013 than FOSDEM 2012 because I found the presentations (Developer rooms especially) more interesting.

After FOSDEM we travelled to Nuremberg for the Marketing Hackathon . On the way back to Nuremberg I was impressed by the fact that openSUSE development continued even on the bus  with various hackers (SUSE Employees)  sitting behind their laptops, building packages. Apart from software development we drunk a lot of  openSUSE beers. 

Arriving to Nuremberg , after FOSDEM , we begun to work in the 12.3 RC1 release. SUSE Employees helped us by providing all the necessary equiqment [ok , coffee , meeting rooms etc]  since we worked in the SUSE offices. Interacting with people from the company was really interesting , and i admit that during a release there is a lot of work to be done (bug fixing , artwork, ,writing , promotion , etc) .

Apart from the release we enjoyed a presentation by the SUSE Documentation team  , where we tested  a demo of the new ActiveDoc tool.ActiveDoc is used for the documentation of openSUSE and SUSE as well. Furthermore we had visits from company management , from Ralf Flaxa, VP of engineering, and Roland Haidl. During these meetings we discussed about issues  around openSUSE Project , and how the project can be improved. Ralf Flaxa and Roland Haidl thanked us for our work and they confirmed their willing to help the openSUSE Project as much as they can.

As the KDE 4.10 released during the Marketing Hackathon we all joined the KDE 4.10 release party (in Wednesday). KDE president Cornelius Schumacher and Klaas Freitag, (ownCloud Senior Developer) joined us to the party. We had really interesting discussions about various aspects (KDE , ownCloud ,oSC13 etc).

Work

Here i give a brief summary of my work

– 12.3 Screenshots (Screenshots and related wiki page) [although my laptop was broken for a while]

– 12.3 Package list and Feature (the last days)

–  12.3 Social Media messages for RC1 (and the final release as well)

– 12.3 “We are Hispanohablantes”  , a new project begun , willing to centralize the Spanish speaking communities in openSUSE. Here you can find the English [1] and Spanish [2] version of the wiki page. [if you come from a Spanish spoken country , you can add stuff in the “Information Table”.]

Conclusion

I could blog about this experience for years , but i prefered to write a resume of what i have in my mind
.  Obviously i would like to thank the following people (participants and SUSE Employees) :

Participants :

Kostas , Bruno (tigerfoot – “Champignon”) , Carlos (victorck), Carlos (CarlosRibeiro), Izabel (IzabelleValverde), Marcel (tux93 or “Silent Power”), Richard (ilmehtar), Michal (|miska|).

SUSE Employees:

Jos, Henne , Ralf, Roland,  James, Jan, Ludwig, Cornelius, Suzanne Augustin, Will, Christopher, Adrian, , Jurgen, Kenneth, Cassio, Alberto,
(if I forget someone ,please let me know )

And yes we all love Vietnam

You can find the photos of the event here and here as well.

And don’t forget!!

See you in oSC13 [18-22 July , Thessaloniki , Greece]  . As the Cfp is open don’t forget to register yourself and why not submit your presentation [or workshop]!!

A lot of Geekings to everybody,

“Power to the Geeko”

[1] https://en.opensuse.org/We_are_Hispanohablantes

[2] https://es.opensuse.org/Somos_hispanohablantes

Next week a part of the ownCloud team will meet in Nürnberg for a creative time and we thought a little meetup would be cool. Join us for a relaxed evening where we will give short talks about current state of ownCloud, new features and the near future.

Let’s meet Wednesday, February 27th, 6:00 PM at the Nuremberg Coworking Space.

Talks (short, don’t be afraid!):

• ownCloud overview by Holger Dyroff
• The updated ownCloud 5 User Interface by Jan-Christoph Borchardt
• Next steps for the ownCloud Desktop Clients by Daniel Molkentin

The evening closes with a get-together, your chance to meet the team and discuss in a relaxed atmosphere.

Everybody is welcome!

Quake 3 Arena code.

I pushed out the Quake 3 Arena code used for demoing limare and for benchmarking.

You can build it on your linux-sunxi with

    make ARCH=arm

or, for the limare version (which will not build without the matching limare driver, which i haven't pushed out yet :))

    make ARCH=arm USE_LIMARE=1

for the GLESv2 version (with the broken lamps due to missing alphatest):

    make ARCH=arm USE_GLES2=1

Get a full Quake 3 Arena version first though, and stick all the paks in ~/ioquake3/baseq3. Add this to demofour.cfg in the same directory:

    cg_drawfps 1
    timedemo 1
    set demodone  "quit"
    set demoloop1 "demo four; set nextdemo vstr demodone"
    vstr demoloop1

To run the timedemo then run the quake binary with +exec demofour.cfg

For your own reverse engineering purposes, to build the GLESv1 version with logging included, edit code/egl/egl_glimp.c, and remove the // before:

    //#define QGL_LOG_GL_CALLS 1

But be aware, you are not free to spread that dumped data. That is ID Software data, albeit in a raw form.

I'd be much obliged if anyone hacks up input support, or re-adds sound. Or even adds the missing GLES2 shaders (color as a uniform for instance). That would make this code playable from the console, and should make it easier for me to provide playable limare code.

As you all can see, we have nothing to hide. The relevant differences between GLES1 and limare is in the GL implementation layer. I did shortcut vertex counting, this to ease logging, but this only has limited effect on CPU usage. The lesser CPU usage of limare is not significant or interesting as we do less checking than a full driver anyway. In simpler tests (rotating cubes), our scheduling results in a much higher CPU usage though (like 50% more, from 10% to 15% :)), even if we are not significantly faster. As said in my previous, i am not sure yet whether to keep this, or to find some improvements. Further tests, on much more powerful hardware, will tell.

Connors Compiler Work.

Connor had a massive motivation boost from FOSDEM (and did not suffer from the bug that was going round which so many of us in the last week). Earl from zaReason is sending him an A13 tablet, which should spur him on even further.

He has been coding like a madman, and he is now close to being able to compile the relatively simple shaders used in the Quake 3 Arena demo. He still has to manually convert the ESSL of the vertex shader to his own GP_IR first though, but that's already massive progress which gets us very close to our goals.

I am going to add MBS loading (Mali Binary Shader format) to limare to be able to forgo the binary compiler and load pre-compiled shaders into our programs. Since MBS is also spit out by the open-gpu-tools, we can then distribute our own compiled MBS files directly, and provide a fully open source Q3A implementation on mali.

How cool is that!

The very near future.

With my post purely about Q3A and its numbers, the reactions were rather strange. Seems like a lot of people were hung up exclusively on us being only 2% faster or because we were using this "ancient" game. The blog entry itself explained fully why this ancient game was actually a very good choice, yet only very few read it. Very few realized what a massive milestone an almost pixel-perfect Quake 3 Arena is for a reverse engineered driver.

As for performance... When i started investigating the mali, i had postulated that we would be happy to have only 75% of the performance of the binary driver. I assumed that, even with performance per watt being mighty important in the mobile space, 75% was the threshold at which the advantages of an open source driver would outweight the loss of performance. This would then lead to only ARMs big partners would end up shipping ARMs own binaries. And for projects like CyanogenMod and proper linux distributions there would be no question about what to ship.

With Q3A, and with the various rotating cubes, we now have proven that we can have a 100% match in performance. Sometimes we can even beat performance. All of this is general, no Q3A specific tricks here!

This is absolutely unique, and is beyond even the wildest dreams of a developer of any reverse engineered driver.

Absolutely nothing stops us now from delivering an open source driver that broadly matches the binary driver in performance! And this is exactly what we will be doing next!

Hey ARM!

We are not going away, we are here to stay. We cannot be silenced or stopped anymore, and we are becoming harder and harder to ignore.

It is only a matter of time before we produce an open source graphics driver stack which rivals your binary in performance. And that time is measured in weeks and months now. The requests from your own customers, for support for this open source stack, will only grow louder and louder.

So please, stop fighting us. Embrace us. Work with us. Your customers and shareholders will love you for it.

-- libv.

(c) S. Delcroix 2013

I'm quite pleased to announce the availability of Chipmunk bindings for monotouch. I started that last year, and bound just enough of it to get a sample working, added some constraints lately in order to place labels, and completed it since for the beauty of the task. The image next to this is a screenshot from a system using a motor, a gear joint, pivot joints and some more.

At this point in time, the ~2000 lines of manually crafted lines of code can be found in this pull request, but you probably won't have to wait long before it's merged in the monotouch-bindings repository.

What's missing ?

Mainly queries, plus a few function calls here and there.

Integrate with cocos2d

Memory management