Re: gitlab.fd.o financial situation and impact on services
On Fri, Feb 28, 2020 at 12:00 AM Daniel Stone wrote: > > Hi Matt, > > On Thu, 27 Feb 2020 at 23:45, Matt Turner wrote: > > We're paying 75K USD for the bandwidth to transfer data from the > > GitLab cloud instance. i.e., for viewing the https site, for > > cloning/updating git repos, and for downloading CI artifacts/images to > > the testing machines (AFAIU). > > I believe that in January, we had $2082 of network cost (almost > entirely egress; ingress is basically free) and $1750 of cloud-storage > cost (almost all of which was download). That's based on 16TB of > cloud-storage (CI artifacts, container images, file uploads, Git LFS) > egress and 17.9TB of other egress (the web service itself, repo > activity). Projecting that out gives us roughly $45k of network > activity alone, so it looks like this figure is based on a projected > increase of ~50%. > > The actual compute capacity is closer to $1150/month. Could we have the full GCP bill posted? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: gitlab.fd.o financial situation and impact on services
On Thu, Feb 27, 2020 at 1:27 PM Daniel Vetter wrote: > > Hi all, > > You might have read the short take in the X.org board meeting minutes > already, here's the long version. > > The good news: gitlab.fd.o has become very popular with our > communities, and is used extensively. This especially includes all the > CI integration. Modern development process and tooling, yay! > > The bad news: The cost in growth has also been tremendous, and it's > breaking our bank account. With reasonable estimates for continued > growth we're expecting hosting expenses totalling 75k USD this year, > and 90k USD next year. With the current sponsors we've set up we can't > sustain that. We estimate that hosting expenses for gitlab.fd.o > without any of the CI features enabled would total 30k USD, which is > within X.org's ability to support through various sponsorships, mostly > through XDC. > > Note that X.org does no longer sponsor any CI runners themselves, > we've stopped that. The huge additional expenses are all just in > storing and serving build artifacts and images to outside CI runners > sponsored by various companies. A related topic is that with the > growth in fd.o it's becoming infeasible to maintain it all on > volunteer admin time. X.org is therefore also looking for admin > sponsorship, at least medium term. > > Assuming that we want cash flow reserves for one year of gitlab.fd.o > (without CI support) and a trimmed XDC and assuming no sponsor payment > meanwhile, we'd have to cut CI services somewhere between May and June > this year. The board is of course working on acquiring sponsors, but > filling a shortfall of this magnitude is neither easy nor quick work, > and we therefore decided to give an early warning as soon as possible. > Any help in finding sponsors for fd.o is very much appreciated. Some clarification I got from Daniel in a private conversation, since I was confused about what the money was paying for exactly: We're paying 75K USD for the bandwidth to transfer data from the GitLab cloud instance. i.e., for viewing the https site, for cloning/updating git repos, and for downloading CI artifacts/images to the testing machines (AFAIU). I was not aware that we were being charged for anything wrt GitLab hosting yet (and neither was anyone on my team at Intel that I've asked). This... kind of needs to be communicated. A consistent concern put forth when we were discussing switching to GitLab and building CI was... how do we pay for it. It felt like that concern was always handwaved away. I heard many times that if we needed more runners that we could just ask Google to spin up a few more. If we needed testing machines they'd be donated. No one mentioned that all the while we were paying for bandwidth... Perhaps people building the CI would make different decisions about its structure if they knew it was going to wipe out the bank account. What percentage of the bandwidth is consumed by transferring CI images, etc? Wouldn't 75K USD would be enough to buy all the testing machines we need and host them within Google or wherever so we don't need to pay for huge amounts of bandwidth? I understand that self-hosting was attractive so that we didn't find ourselves on the SourceForge-equivalent hosting platform of 2022, but is that risk real enough to justify spending 75K+ per year? If we were hosted on gitlab.com or github.com, we wouldn't be paying for transferring CI images to CI test machines, etc, would we? So what do we do now? Have we painted ourselves into a corner? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [ANNOUNCE] wayland 1.15.0
On Mon, Apr 9, 2018 at 10:57 AM, Derek Foreman wrote: > Wayland 1.15.0 is now out. > > Some highlights: > Compositor writers take note - wl_subcompositor.get_subsurface is now > documented to be double buffered. It wasn't clearly specified to be so > before (this change should be non breaking in practice and merely remove > the opportunity for a render glitch in the compositor.) > > New API, wl_display_destroy_clients() has been added to help some > compositors clean up clients before destroying their display. > > wayland-scanner can now generate either public or private symbols, and > the old command line option "code" will emit a warning. It also has a > new --strict option to immediately exit on DTD validation failure. > > libwayland-egl is now part of libwayland, and will presumably be removed > from mesa in the not too distant future. Since there doesn't seem to have been any announcement or guidance on the Mesa side for what distros are supposed to do, I'll ask here: Are distros supposed to stop passing "wayland" to Mesa's --with-platforms= configure option? ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] XDC 2017 feedback
On Wed, Sep 27, 2017 at 10:07 PM, Rob Clark wrote: > If you had known of the khr dates, and brought it up in Feb (or really > somewhat earlier, given that XDC is roughly same time each year +/- > few weeks), that *might* have been early enough to move things. That's unfair. It's part of the X.Org board's responsibilities to plan conferences and that means being aware of potential conflicts. In February, six of the eight members of the X.Org board worked for companies with Khronos access (that's not including Keith who I suspect has access as well). I replied to the 2017-03-02 minutes and noted the conflict, but as you say that was too late. Unfortunately that was the first time a date was publicly announced, so I'm not really sure what could have been done from outside the X.Org board. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH 3/3] tests: add wl_resource tests
On Wed, Sep 18, 2013 at 8:29 AM, Marek Ch wrote:
> ---
> tests/Makefile.am | 4 +-
> tests/resources-test.c | 167
> +
> 2 files changed, 170 insertions(+), 1 deletion(-)
> create mode 100644 tests/resources-test.c
>
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 3806cb6..9c673ae 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -11,7 +11,8 @@ TESTS = \
> sanity-test \
> socket-test \
> queue-test \
> - signal-test
> + signal-test \
> + resources-test
>
> check_PROGRAMS = \
> $(TESTS)\
> @@ -34,6 +35,7 @@ sanity_test_SOURCES = sanity-test.c $(test_runner_src)
> socket_test_SOURCES = socket-test.c $(test_runner_src)
> queue_test_SOURCES = queue-test.c $(test_runner_src)
> signal_test_SOURCES = signal-test.c $(test_runner_src)
> +resources_test_SOURCES = resources-test.c $(test_runner_src)
>
> fixed_benchmark_SOURCES = fixed-benchmark.c
>
> diff --git a/tests/resources-test.c b/tests/resources-test.c
> new file mode 100644
> index 000..d7a428a
> --- /dev/null
> +++ b/tests/resources-test.c
> @@ -0,0 +1,167 @@
> +/*
> + * Copyright © 2013 Marek Chalupa
> + *
> + * Permission to use, copy, modify, distribute, and sell this software and
> its
> + * documentation for any purpose is hereby granted without fee, provided that
> + * the above copyright notice appear in all copies and that both that
> copyright
> + * notice and this permission notice appear in supporting documentation, and
> + * that the name of the copyright holders not be used in advertising or
> + * publicity pertaining to distribution of the software without specific,
> + * written prior permission. The copyright holders make no representations
> + * about the suitability of this software for any purpose. It is provided
> "as
> + * is" without express or implied warranty.
> + *
> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> SOFTWARE,
> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF
> USE,
> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> PERFORMANCE
> + * OF THIS SOFTWARE.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "wayland-server.h"
> +#include "test-runner.h"
> +
> +TEST(create_resource_tst)
> +{
> + struct wl_display *display;
> + struct wl_client *client;
> + struct wl_resource *res;
> + struct wl_list *link;
> + int s[2];
> + uint32_t id;
> +
> + assert(socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, s) == 0);
> + display = wl_display_create();
> + assert(display);
> + client = wl_client_create(display, s[0]);
> + assert(client);
> +
> + res = wl_resource_create(client, &wl_display_interface, 4, 0);
> + assert(res);
> +
> + /* setters/getters */
> + assert(wl_resource_get_version(res) == 4);
> +
> + assert(client == wl_resource_get_client(res));
> + id = wl_resource_get_id(res);
> + assert(wl_client_get_object(client, id) == res);
> +
> + link = wl_resource_get_link(res);
> + assert(link);
> + assert(wl_resource_from_link(link) == res);
> +
> + wl_resource_set_user_data(res, (void *) 0xbee);
> + assert(wl_resource_get_user_data(res) == (void *) 0xbee);
> +
> + wl_resource_destroy(res);
> + wl_client_destroy(client);
> + wl_display_destroy(display);
> + close(s[1]);
> +}
> +
> +static void
> +res_destroy_func(struct wl_resource *res)
> +{
> + assert(res);
> +
> + _Bool *destr = wl_resource_get_user_data(res);
> + *destr = 1;
> +}
> +
> +static _Bool notify_called = 0;
> +static void
> +destroy_notify(struct wl_listener *l, void *data)
> +{
> + assert(l && data);
> + notify_called = 1;
> +}
> +
> +TEST(destroy_res_tst)
> +{
> + struct wl_display *display;
> + struct wl_client *client;
> + struct wl_resource *res;
> + int s[2];
> + unsigned id;
> + struct wl_list *link;
> +
> + _Bool destroyed = 0;
> + struct wl_listener destroy_listener = {
> + .notify = &destroy_notify
> + };
> +
> + assert(socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, s) == 0);
> + display = wl_display_create();
> + assert(display);
> + client = wl_client_create(display, s[0]);
> + assert(client);
> +
> + res = wl_resource_create(client, &wl_display_interface, 4, 0);
> + asse
Re: Things that killed my motivation to play with wayland
On Wed, Jun 12, 2013 at 12:40 AM, wrote: > On 12/06/2013 02:49, dar...@chaosreigns.com wrote: >> >> 1) This mesa bug: https://bugs.freedesktop.org/show_bug.cgi?id=61919 >> make fails without C_INCLUDE_PATH set. It pretty much destroyed my build >> testing setup (I was build testing 46 related repos every few hours). >> I never managed to work out the obvious workaround of just setting >> C_INCLUDE_PATH for mesa builds (which I had working for another repo). >> I included the commit where the problem started. Three months ago. >> (Build test script I wrote: http://www.chaosreigns.com/code/buildtest/ ) > > > I provided a patch on this one, and even if I didn’t test it, it should work > in your case. If not, I’m willing to help, just ask me for another patch > with some relevant logs. Indeed. Let me know if the new patch fixes things for you and I'll commit it. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [Mesa-dev] Very low framerate when recording desktop content in Weston using mesa git on Radeon 5770 (glReadPixels slow path)
On Tue, Mar 26, 2013 at 2:44 PM, Bengt Richter wrote:
> uint32_t
> component_delta2(uint32_t next, uint32_t prev)
> {
> return next&0xff00ff)-(prev&0xff00ff)+0x100)&0xff00ff)+
> (((next&0xff00)-(prev&0xff00))&0xff00));
> }
Does removing all the spaces make it faster? ;)
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Weston doesn't work with gl enabled cairo on radeon
On Fri, Aug 10, 2012 at 6:54 PM, Nerdopolis wrote: > IIt's a bug in Mesa. Try reverting mesa to commit > 102617bc5206e459bb1743d2d72341dbfe77bc58 > That's what I had to do. It's not a bug. The name of the EGL extension that Cairo uses was changes, basically. Cairo just needs to be updated, which is now has been: http://cgit.freedesktop.org/cairo/commit/?id=f59b0914f4ddbff0d116c918343a6726d5f4317b ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Graphics memory management in ARM/Embedded Linux
2011/4/20 Tom Cooksey : > So while I agree re-inventing something just for the sake of it is bad, > that's not what's happening. > In fact, I think there's a good chance TTM will > be ripped out, stuck into its own driver (with its own device node /dev/ttm) > and extended to meet everyone's requirements. I'm having a hard time understanding how these two seemingly contradictory sentences fit one after another. Are you saying that this new project will be modifying TTM and sticking it in its own driver with its own device node? Thanks, Matt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: wayland screen locker and security in general
2011/4/6 Michal Suchanek : > 2011/4/6 Joakim Sindholt : >> On Wed, 2011-04-06 at 11:42 +0200, Michal Suchanek wrote: >>> 2011/4/5 Vinícius dos Santos Oliveira : >>> >>> >> How will apps like mplayer/vlc/browsers-playing-videos tell the >>> >> compositor >>> >> that they are "busy" drawing and that the lock should NOT be engaged even >>> >> though there hasn't been any keyboard/mouse activity for long stretches? >>> >> As >>> >> compared to "default" apps that just paint "im bored" over and over >>> >> again, >>> >> where the idle lock should get switched on... >>> > >>> > Take a look at >>> > http://lists.freedesktop.org/archives/xdg/2009-April/010317.html >>> > >>> >>> So is dbus absolutely required part of wayland then? >>> >>> Thanks >>> >>> Michal >> >> No, but as it is a standard desktop component for IPC it seems fitting >> to use it. The specification is intentionally vague on the subject. >> > > JFYI I have a desktop environment running completely without dbus. > That does not mean that dbus cannot or should not be used. It is just > not as standard as the two most bloated desktop environments might > make it seem. AFAICT dbus is just a replacement for a directory tree > with unix sockets under /tmp. Either is equally functional. Congratulations, you appear to have made 1990sLinuxUser's twitter feed. http://twitter.com/1990sLinuxUser ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Future desktop on dumb frame buffers?
On Mon, Mar 21, 2011 at 9:20 PM, Alan Cox wrote: >> 1) inertia: fbdev has been around a lot longer, and provides most of >> what embedded devices need anyway >> 2) feature set: why bother doing a full KMS driver if you're not >> going to use any of the additional features it would provide (output >> management, memory management, execution management) > > 3) its got documentation My summer of code project's purpose was to create something of a tutorial for writing a KMS driver. The code, split out into something like 15 step-by-step patches, and accompanying documentation are available from Google's website. http://code.google.com/p/google-summer-of-code-2010-xorg/downloads/detail?name=Matt_Turner.tar.gz My repository (doesn't include the documentation) is available here: http://git.kernel.org/?p=linux/kernel/git/mattst88/glint.git;a=summary There's a 'rebased' branch that contains API changes required for the code to work with 2.6.37~. It's nothing fantastic, but I've had a number of people tell me that it was useful for them. Thanks, Matt ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
