Re: [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Thu, 27 Feb 2020 22:27:04 +0100 Daniel Vetter said: Might I suggest that given the kind of expenses detailed here, literally buying 1 - 4 reasonably specced boxes and hosting them at OSUOSL would be incredibly cheaper? (we (enlightenment.org) have been doing so for years on a single box). We farm out CI to travis via gihub mirrors as it's not considered an essential core service (unlike mailing lists, git, phabricator whch nwe still run - we can live without CI for a while and find other ways). The cost is the odd HDD replacement every few years and maybe every 10y or so a new box. That's a massively lower cost than you are quoting below. OSUOSL provide bandwidth, power, rack space etc. for free. They have been fantastic IMHO and the whole "no fat bills" is awesome and you get a full system to set up any way you like. You just bring the box. That should drop cost through the floor. It will require some setup and admin though. > 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. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > xorg-de...@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Unable to find a matching EGL config on Wayland
On Fri, 31 Jan 2020 14:48:29 +0530 "Devashish Tiwari" said: Hi Devashish. That fact you have "SGX" for demos hints to me that you have some hardware with an Imagination based GPU and drivers provided by them. Their drivers provide EGL and and the implementation of eglChooseConfig() under the hood. You should contact whoever provided you with your drivers for help as Daniel suggested. It very likely is a set of proprietary drivers that Wayland as a project and set of developers who work on and with it have nothing to do with. We can't help with something we didn't build nor even can see the insides of because it's a proprietary binary blob. If you were using Mesa based drivers (I suspect you are not given the above) which are open source and have a lot of common development happen hand in hand with wayland, then we may be able to. > Hi Daniel, > > My application, as I described, requires a display protocol to run. And it is > using wayland. > > Because if I stop weston and run my application, it throws me following error: > > Error- Unable to init SDL: No available video device > > Also, I just checked $WAYLAND_DISPLAY environment variable and it is already > set to 'wayland-0'. > > The fact that eglinfo works perfectly after stopping weston makes me think > that my application uses SDL_EGL_ChooseConfig() to set some EGL > parameters/attributes and then calls _this->egl_data->eglChooseConfig() to > see if it matches any available egl configurations but is not able to match > with configurations returned by this function. And in my opinion, the reason > behind this is _this->egl_data->eglChooseConfig() somehow calls eglinfo it > doesn't return available egl configurations on the EVM and hence matching > fails and egl surface is not created. > > Please check and revert. > > On Fri, 31 Jan 2020 08:27:50 +, Daniel Stone wrote > > Hi Devashish, > It sounds like your application, as well as eglinfo, are not even > trying to use Wayland. Maybe they are autodetecting the platform > incorrectly and trying to use GBM instead. This could perhaps be > solved by setting the $WAYLAND_DISPLAY environment variable to the > name of the socket Weston uses (usually 'wayland-0'). However you > should probably contact The Qt Company for support in using Qt, and > you should contact TI (or your BSP vendor) for support with the > proprietary Imagination EGL/GLES driver. > > Cheers, > Daniel > > On Fri, 31 Jan 2020 at 08:12, Devashish Tiwari wrote: > > > > Hello, > > > > > > I have built a simple application using QT & SDL that has a button which > > opens a preview on clicking, whenever camera (system/usb) is connected to > > the EVM. > > > > My app successfully receives correct parameters related to camera > > (resolution, frame rate, frame format) and I have verified it using debug > > prints. However, when I click on preview button, it crashes and throws > > error related to EGL. > > > > > > On executing it with gdb, I found out that it is not able to get a valid > > EGL configuration. The eglChooseConfig function (in SDL_egl.c) doesn't > > find a matching EGL config and it fails to create a surface and open the > > preview. > > > > Also, I do not get any "EGL 1.4 Initialised" prints when my app executes. > > This print, on the contrary, is visible when I run OGLES2ChameleonMan > > in /usr/bin/SGX/demos/Wayland. > > > > > > On digging further, I found that the "eglinfo" command displays the egl > > configurations on the terminal. > > > > However, when it returns EGL_BAD_ALLOC on my EVM, if I run it without > > stopping weston. It runs successfully only after stopping weston. I am > > assuming this is the reason why my application is not able to find a > > matching EGL config because it runs over weston. > > > > > --- > > > > > root@am57xx-evm:/mnt# eglinfo > > > > eglGetConfigs(): > > == > > ** EGL config number: 0 EGL vendor string: > > Imagination Technologies EGL version string: 1.4 build 1.14@3699939 (MAIN) > > EGL extensions: EGL_IMG_client_api_ogl EGL_KHR_image EGL_KHR_image_base > > EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image > > EGL_KHR_gl_renderbuffer_image EGL_KHR_vg_parent_image EGL_IMG_cl_image > > EGL_KHR_fence_sync EGL_IMG_context_priority EGL_IMG_hibernate_process > > EGL_IMG_image_plane_attribs EGL_KHR_surfaceless_context EGL_KHR_wait_sync > > EGL_KHR_create_context EGL_WL_bind_wayland_display > > EGL_EXT_image_dma_buf_import EGL client APIs are: OpenGL_ES EGL config > > Attributes: EGL_CONFIG_ID = 0x1 EGL_BUFFER_SIZE = 0x20 EGL_RED_SIZE = 0x8 > > EGL_GREEN_SIZE = 0x8 EGL_BLUE_SIZE = 0x8 EGL_LUMINANCE_SIZE = 0x0 > > EGL_ALPHA_SIZE = 0x8 EGL_ALPHA_MASK_SIZE = 0x0 EGL_BIND_TO_TEXTURE_RGB = > > 0x1
Re: [Mesa-dev] [PATCH RFC 2/2] dri: Pass a __DRIcontext to ->set_damage_region()
On Thu, 29 Aug 2019 13:54:16 +0200 Boris Brezillon
said:
These 2 do improve things, but once you start doing BindFramebuffer()'s as part
of the render cycle ... its back to rendering artifacts. I am not quite sure
exactly what yet. I need to capture some output and traces to get a better idea
of what is going on.
> So we can call st_validate_state() from dri2_set_damage_region() in
> order to update the BACK_LEFT attachement before using it. If we don't
> do that, the resource passed to pipe_screen->set_damage_region() might
> be wrong.
>
> Signed-off-by: Boris Brezillon
> ---
> Hi,
>
> I honestly don't know if this is the right thing to do. Passing a
> context for somethings that we decided to bind to a surface (and
> the underlying resources attached to it) seems wrong, but at the same
> time I don't see any other option to sync the gallium drawable state
> with the EGL DRI surface one.
>
> Any ideas/suggestions?
>
> Regards,
>
> Boris
> ---
> include/GL/internal/dri_interface.h | 5 +++--
> src/egl/drivers/dri2/egl_dri2.c | 7 +--
> src/gallium/state_trackers/dri/dri2.c | 11 ++-
> 3 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/include/GL/internal/dri_interface.h
> b/include/GL/internal/dri_interface.h index 4c60d349ddd5..e04bed689219 100644
> --- a/include/GL/internal/dri_interface.h
> +++ b/include/GL/internal/dri_interface.h
> @@ -527,12 +527,13 @@ struct __DRI2bufferDamageExtensionRec {
> *
> * Used to implement EGL_KHR_partial_update.
> *
> +* \param ctx context
> * \param drawable affected drawable
> * \param nrects number of rectangles provided
> * \param rectsthe array of rectangles, lower-left origin
> */
> - void (*set_damage_region)(__DRIdrawable *drawable, unsigned int nrects,
> - int *rects);
> + void (*set_damage_region)(__DRIcontext *_ctx, __DRIdrawable *drawable,
> + unsigned int nrects, int *rects);
> };
>
> /*@}*/
> diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
> index ea8ae5d44c56..797a76dab13c 100644
> --- a/src/egl/drivers/dri2/egl_dri2.c
> +++ b/src/egl/drivers/dri2/egl_dri2.c
> @@ -1812,11 +1812,14 @@ dri2_set_damage_region(_EGLDriver *drv, _EGLDisplay
> *disp, _EGLSurface *surf, {
> struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
> __DRIdrawable *drawable = dri2_dpy->vtbl->get_dri_drawable(surf);
> + _EGLContext *ctx = _eglGetCurrentContext();
> + __DRIcontext *dri_ctx = ctx ? dri2_egl_context(ctx)->dri_context : NULL;
>
> - if (!dri2_dpy->buffer_damage || !
> dri2_dpy->buffer_damage->set_damage_region)
> + if (!dri2_dpy->buffer_damage || !
> dri2_dpy->buffer_damage->set_damage_region ||
> + !dri_ctx)
>return EGL_FALSE;
>
> - dri2_dpy->buffer_damage->set_damage_region(drawable, n_rects, rects);
> + dri2_dpy->buffer_damage->set_damage_region(dri_ctx, drawable, n_rects,
> rects); return EGL_TRUE;
> }
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c
> b/src/gallium/state_trackers/dri/dri2.c index 11ce19787249..bab503046510
> 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -36,6 +36,7 @@
> #include "util/u_format.h"
> #include "util/u_debug.h"
> #include "state_tracker/drm_driver.h"
> +#include "state_tracker/st_atom.h"
> #include "state_tracker/st_cb_bufferobjects.h"
> #include "state_tracker/st_cb_fbo.h"
> #include "state_tracker/st_cb_texture.h"
> @@ -1869,9 +1870,17 @@ static const __DRI2interopExtension
> dri2InteropExtension = {
> * \brief the DRI2bufferDamageExtension set_damage_region method
> */
> static void
> -dri2_set_damage_region(__DRIdrawable *dPriv, unsigned int nrects, int *rects)
> +dri2_set_damage_region(__DRIcontext *_ctx, __DRIdrawable *dPriv,
> + unsigned int nrects, int *rects)
> {
> struct dri_drawable *drawable = dri_drawable(dPriv);
> + struct st_context *st = (struct st_context *)dri_context(_ctx)->st;
> +
> + /* Make sure drawable->textures[ST_ATTACHMENT_BACK_LEFT] is up-to-date
> +* before using it.
> +*/
> + st_validate_state(st, ST_PIPELINE_UPDATE_FRAMEBUFFER);
> +
> struct pipe_resource *resource =
> drawable->textures[ST_ATTACHMENT_BACK_LEFT]; struct pipe_screen *screen =
> resource->screen; struct pipe_box *boxes = NULL;
> --
> 2.21.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
