Year 2010 has ended so its nice to check the couple of interesting OSS Graphics components have evolved during 2010. With the interesting ones meaning Mesa, XServer and the one that everyone is discussing about, Wayland. Surely along these components there has been a lot of activity on the Kernel side from graphics point of view by moving the logic to the Kernel side (DRI drivers, the kernel side GEM scheduler and kernel mode setting) plus there has also been a lot of activity around the toolkits but as said now sticking with these three.
So what has happened,
With Mesa we have:
157 people committing
and those people pushing in 12816 commits (of different sizes)
(where as in 2009 the figures were, 118 people pushing in 9719 commits)
With XServer we have:
99 people committing
and those people pushing in 1305 commits (of different sizes)
(where as in 2009 the figures were, 109 people pushing in 2057 commits)
With Wayland the figures are especially interesting as it has received a _lot_ of publicity lately (Unity, Fedora). Now during the year 2010 there were already close to 20 contributors for the project where as a year ago there were only two.
So a lot of things happening in the head of mainline. If we check these commits on daily basis - Mesa having average of 35 commits happening every single day and XServer having 3.5 commits on daily basis. And not to even mention the Kernel which has over 100 commits per day.
Starting to deviate from this with an custom build behind the closed doors will mean an big maintenance and development effort for the instances deciding to do so. On the other hand this is sometimes mandatory. When discussing about an commercial company which is still aiming at to make profit you are bound to keep something behind the closed doors.
So balancing between Open Sourcing code and potentially exposing the bits and pieces from the latest and greatest can get tricky and really needs to be thought carefully.
PS. with MeeGo the problem is tackled by doing the XServer development with the git head - see.
Showing posts with label Mesa. Show all posts
Showing posts with label Mesa. Show all posts
Thursday, 6 January 2011
Sunday, 9 May 2010
GLES1.1/2.0 on Mesa DRI and a bit about Gallium
Mesa has had GLES 1.1/2.0 already since since last year through Gallium state trackers. What this means is that Gallium based drivers are capable of providing support GLES support for end users. Now there is also an activity ongoing to get the Mesa GLES1/2 support to work with DRI drivers and along that to expose multiple GL APIs without separate state trackers on Gallium side.
This work on GLES 1.1/2.0 on DRI made by Kristian received good feedback also Gallium driver developer and is now merged to Mesa.
The discussion about classic Mesa vs. Mesa Gallium State Tracker in general has not lately been this productive (see the Mesa thread). Intel guys are clearly wanting to stay with the classic drivers, and whom could actually blame after all the work that Intel has place to get their drivers to perform. Currently Nouveau camp is the only one that is really utilising Gallium3D and the RedHat guys are going to ship the latest free software NVIDIA bits with the upcoming Fedora 13.
This work on GLES 1.1/2.0 on DRI made by Kristian received good feedback also Gallium driver developer and is now merged to Mesa.
The discussion about classic Mesa vs. Mesa Gallium State Tracker in general has not lately been this productive (see the Mesa thread). Intel guys are clearly wanting to stay with the classic drivers, and whom could actually blame after all the work that Intel has place to get their drivers to perform. Currently Nouveau camp is the only one that is really utilising Gallium3D and the RedHat guys are going to ship the latest free software NVIDIA bits with the upcoming Fedora 13.
Thursday, 11 March 2010
DRI2 driver for Mesa EGL
Couple of weeks ago there was an announcement that Wayland would be moving to Mesa EGL and drop its dependencies to its own Wayland specific Eagle EGL stack. The Eagle is a non-conformant EGL loader for the DRI drivers originally develped by Kristian Høgsberg as an "side product" of his DRI2 work. Eagle as an lightweight and with its way of integrating EGL directly to KMS/DRM, was the solution for Wayland - this at least until recently.
Major reason to allow Wayland to jump to Mesa EGL is Kristian's work for the work behind the DRI2 driver for EGL and to get the Eagle EGL parts as officially to Mesa. This work - EGL on DRI2 is firstly aiming to implement this support through X, but the longer term goal seems to be that the implementation would be standalone - working directly with KMS/DRM and making it suitable for Wayland purposes.
Current plan is that the DRI2 parts for the Mesa EGL would be integrated to the upcoming Mesa 7.8 - planned to be release during this month. This is good news especially for Wayland. Along the Mesa integration the Wayland enablers are now even more mainlined. This move will most definitely make Wayland it self more attractive to outside world.
Major reason to allow Wayland to jump to Mesa EGL is Kristian's work for the work behind the DRI2 driver for EGL and to get the Eagle EGL parts as officially to Mesa. This work - EGL on DRI2 is firstly aiming to implement this support through X, but the longer term goal seems to be that the implementation would be standalone - working directly with KMS/DRM and making it suitable for Wayland purposes.
Current plan is that the DRI2 parts for the Mesa EGL would be integrated to the upcoming Mesa 7.8 - planned to be release during this month. This is good news especially for Wayland. Along the Mesa integration the Wayland enablers are now even more mainlined. This move will most definitely make Wayland it self more attractive to outside world.
Subscribe to:
Posts (Atom)