of this seems to warrant a new major release, so here we are.
There's also a bunch of bugs fixed, many related to the still-quite-new
Meson build system. So this seems like a good time to upgrade!
On Wed, 2023-03-22 at 16:12 +0100, Erik Faye-Lund wrote:
> Alexandros Frantzis (1):
> egl: Add t
is always not-null.
Erik Faye-Lund (97):
meson: disable annoying msvc-warnings
meson: suppress a few msvc warnings
meson: suppress more annoying warnings
wglutil.c: clean up size-wrangling
glinfo_common.c: add int-casts
glinfo_common.c: do not shadow variable i
Hi, and welcome to the community!
In case you're not already familiar, we have #dri-devel on OFTC, as
mentioned here: https://docs.mesa3d.org/lists.html#irc
This is where most day-to-day communication happens, as well as on our
project on gitlab.fdo.
There's also some technical docs on
ith Erik, we've
> > decided that
> > zink will no longer require any rb/ab/etb tags to be applied to
> > patches in
> > MRs.
> > Following in Turnip's footsteps, any MR that receives sufficient
> > reviewage
> > in gitlab comments can be merged directly wit
://gitlab.freedesktop.org/mesa/demos/-/merge_requests/74
If I don't hear any objections in a few weeks, I plan on merging that
change.
On Fri, 2022-05-13 at 11:14 +0200, Erik Faye-Lund wrote:
> OK, so I think enough time has passed. I have heard a few voices in
> support, and no voices against,
Airlie (1):
glad: regenerate glad files from glad upstream
Eric Engestrom (1):
gitlab-ci: add cmake & autotools builds
Erik Faye-Lund (128):
wglgears: do not include unistd.h on MSVC
wglgears: change window-title
wglgears: make usage and error-handling similar to glxg
OK, so I think enough time has passed. I have heard a few voices in
support, and no voices against, so my plan is to go ahead and merge
this early next week (probably Monday), if I don't hear anyone speak up
soon.
On Wed, 2022-05-04 at 18:38 +0200, Erik Faye-Lund wrote:
> Because we've lan
Thoughts? Objections?
--
Erik Faye-Lund
Principal Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United
Kingdom
Registered in England & Wales, no. 5513718
support in Zink is happening slowly, driven by those who need
it.
--
Erik Faye-Lund
Principal Engineer
Collabora Ltd.
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, United
Kingdom
Registered in England & Wales, no. 5513718
On Fri, 2021-03-26 at 18:22 +0100, Erik Faye-Lund wrote:
> On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote:
> > TLDR; I'm proposing to standardize on US English in our public-
> > facing
> > documentation.
> >
> > I proposed an MR a while back
On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote:
> TLDR; I'm proposing to standardize on US English in our public-facing
> documentation.
>
> I proposed an MR a while back that changed the only occurrence of the
> UK English spelling "optimisation" fo
On Mon, 2021-03-15 at 10:54 -0700, Ian Romanick wrote:
>
> If anyone doesn't feel comfortable speaking out publicly about this,
> please feel free to contact Erik or me privately.
Just thought I'd mention; I've gotten a vote against the proposal
through other channels. Because I haven't gotten
of the forks in the road we follow
trying to clean things up ;)
On Mon, 2021-03-15 at 13:44 +0100, Erik Faye-Lund wrote:
> TLDR; I'm proposing to standardize on US English in our public-facing
> documentation.
>
> I proposed an MR a while back that changed the only occurrence of the
On Tue, 2021-03-16 at 10:06 +, Daniel Stone wrote:
> On Mon, 15 Mar 2021 at 20:54, Jason Ekstrand
> wrote:
> > Three comments:
> >
> > 1. +1
> > 2. Khronos has generally standardized on American English in their
> > specs so I guess that provides some sort of prior art or something.
> >
TLDR; I'm proposing to standardize on US English in our public-facing
documentation.
I proposed an MR a while back that changed the only occurrence of the
UK English spelling "optimisation" for the US English spelling
"optimization", which is already used 34 times in the docs. I've done
similar
AFAIK, anisitropic filtering is almost uselessly underspecified, so
pretty much anything should pass the CTS tests.
But visual quality does affect applications, so we should probably aim
for something reasonable.
On Thu, 2021-01-07 at 19:41 +1000, Dave Airlie wrote:
> On Thu, 7 Jan 2021 at
On Thu, 2020-11-19 at 10:36 -0800, Dylan Baker wrote:
>
> Erik Faye-Lund (3):
> softpipe: correct signature of get_compiler_options
> mesa/main: add missing include in glformats.h
> zink: more accurately track supported blits
>
I just want to point out th
On Mon, 2020-08-03 at 12:48 -0500, Jason Ekstrand wrote:
> On Mon, Aug 3, 2020 at 12:42 PM Erik Faye-Lund
> wrote:
> > On Mon, 2020-08-03 at 10:30 -0500, Jason Ekstrand wrote:
> > > All,
> > >
> > > I'm sure by now you've all seen the articles, LKML mail
On Mon, 2020-08-03 at 10:30 -0500, Jason Ekstrand wrote:
> All,
>
> I'm sure by now you've all seen the articles, LKML mails, and other
> chatter around inclusive language in software. While mesa doesn't
> provide a whole lot of documentation (hah!), we do have a website, a
> code-base, and a
I second the request :-)
Jul 31, 2020 16:15:05 Mike Blumenkrantz :
> Hi,
>
> I'd like to request marge access for the piglit and mesa gitlab projects.
> I've been contributing a number of patches here (primarily to zink/gallium),
> and this would be useful in my continued work.
>
> Regards,
> > On Sun, 2020-06-14 at 18:22 +0200, Dieter Nützel wrote:
> > > GREAT work!
> > >
> > > Now, it's working with Konqueror (20.04.1 / Frameworks 5.70.0) -
> > even
> > > if
> > > without 'hovered animation'... ;-)
> > >
> > &
... ;-)
> >
> > Greetings,
> > Dieter
> >
> > Am 14.06.2020 17:25, schrieb Daniel Stone:
> > > Hi,
> > >
> > > On Fri, 29 May 2020 at 10:08, Erik Faye-Lund
> > > wrote:
> > > > In the light of the explanation above, do you stil
On Wed, 2020-05-13 at 15:00 +0200, Erik Faye-Lund wrote:
> On Wed, 2020-05-13 at 06:43 -0600, Brian Paul wrote:
> > On 05/13/2020 03:13 AM, Erik Faye-Lund wrote:
> > > On Tue, 2020-05-12 at 12:17 +0200, Erik Faye-Lund wrote:
> > > > On Thu, 2020-05-07 at
On Wed, 2020-05-13 at 06:43 -0600, Brian Paul wrote:
> On 05/13/2020 03:13 AM, Erik Faye-Lund wrote:
> > On Tue, 2020-05-12 at 12:17 +0200, Erik Faye-Lund wrote:
> > > On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> > > > On 05/07/2020 04:33 AM, Erik Faye-L
On Tue, 2020-05-12 at 12:17 +0200, Erik Faye-Lund wrote:
> On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> > On 05/07/2020 04:33 AM, Erik Faye-Lund wrote:
> > > Hey Brian
> > >
> > > TLDR; are you OK with me moving forward with the rework of
> > &g
On Tue, 2020-05-12 at 15:11 +0200, Erik Faye-Lund wrote:
> On Tue, 2020-05-12 at 06:42 -0600, Brian Paul wrote:
> > On 05/12/2020 04:17 AM, Erik Faye-Lund wrote:
> > > On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> > > > On 05/07/2020 04:33 AM, Erik Faye-L
On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> On 05/07/2020 04:33 AM, Erik Faye-Lund wrote:
> > Hey Brian
> >
> > TLDR; are you OK with me moving forward with the rework of
> > mesa3d.org?
>
> Yes...
>
Cool! We've now set up a repo here:
https://gi
On Thu, 2020-05-07 at 11:03 -0600, Brian Paul wrote:
> On 05/07/2020 04:33 AM, Erik Faye-Lund wrote:
> > Hey Brian
> >
> > TLDR; are you OK with me moving forward with the rework of
> > mesa3d.org?
>
> Yes...
Awesome, thanks!
> > As you hopefully a
On Thu, 2020-05-07 at 16:49 +0200, Eric Engestrom wrote:
> On Thursday, 2020-05-07 16:26:19 +0200, Erik Faye-Lund wrote:
> > On Thu, 2020-05-07 at 16:18 +0200, Eric Engestrom wrote:
> > > On Thursday, 2020-05-07 16:07:00 +0200, Erik Faye-Lund wrote:
> > > > On Thu, 20
On Thu, 2020-05-07 at 16:18 +0200, Eric Engestrom wrote:
> On Thursday, 2020-05-07 16:07:00 +0200, Erik Faye-Lund wrote:
> > On Thu, 2020-05-07 at 09:05 -0500, Jason Ekstrand wrote:
> > > Looks shiny but
> > >
> > > We need to be very careful here. One
ions are
> conformant. That page full of logos makes me concerned that we're
> going to risk getting into trouble. Khronos marketing cares A LOT
> about logos.
As I wrote in the e-mail, I've already clarified the logo-usage with
Khronos. They are happy with it as-is.
> On Thu, M
Hey Brian
TLDR; are you OK with me moving forward with the rework of mesa3d.org?
As you hopefully are aware of, I've been working on a new website for
mesa3d.org, split into a "marketing"-frontpage and a documentation
page.
You can read more about the structure and details here if you haven't
While working on the NIR to DXIL conversion code for D3D12, I've
noticed that we're not exactly doing the best we could here.
First some background:
NIR currently has a few instructions that does kinda the same:
1. nir_op_ufind_msb: Finds the index of the most significant bit,
counting from the
b274b4dd9426205066 as denominated
> .pick_status.json: Mark
> 9fea90ad5170dd64376d22a14ac88c392813c96c as denominated
> bin/gen_release_notes.py: fix commit list command
> .pick_status.json: Update to
> 0103f02acb10dcdea23461ba214307a6827a7772
> gitlab-ci: updat
On Fri, 2020-02-28 at 10:43 +, Daniel Stone wrote:
> On Fri, 28 Feb 2020 at 10:06, Erik Faye-Lund
> wrote:
> > On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> > > Yeah, changes on vulkan drivers or backend compilers should be
> > > fairly
> &g
On Fri, 2020-02-28 at 10:47 +0100, Daniel Vetter wrote:
> On Fri, Feb 28, 2020 at 10:29 AM Erik Faye-Lund
> wrote:
> > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter <
> > > daniel.vet...@ffwl
On Fri, 2020-02-28 at 11:40 +0200, Lionel Landwerlin wrote:
> On 28/02/2020 11:28, Erik Faye-Lund wrote:
> > On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> > > On Fri, 28 Feb 2020 at 07:27, Daniel Vetter <
> > > daniel.vet...@ffwll.ch>
> > > w
On Fri, 2020-02-28 at 13:37 +1000, Dave Airlie wrote:
> On Fri, 28 Feb 2020 at 07:27, 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
Seems like you missed zink
On February 5, 2020 9:36:26 PM GMT+01:00, James Jones
wrote:
>Rather than hard-code a list of all the format
>modifiers supported by any gallium driver in
>the dri state tracker, add a screen proc that
>queries the number of auxiliary planes required
>for a given
On Wed, 2019-12-04 at 01:48 -0500, Marek Olšák wrote:
> On Wed., Dec. 4, 2019, 01:20 Tapani Pälli,
> wrote:
> > Hi;
> >
> > On 12/4/19 2:39 AM, Marek Olšák wrote:
> > > Hi,
> > >
> > > Here are 2 proposals to simplify and better optimize the GL-
> > >Gallium
> > > translation.
> > >
> > > 1)
There's already this one:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2695
On Mon, 2019-11-11 at 16:46 -0700, Brian Paul wrote:
> Trivial.
> ---
> src/compiler/spirv/vtn_variables.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Mon, 2019-11-11 at 10:44 +0200, Martin Peres wrote:
> On 31/10/2019 09:35, Chris Wilson wrote:
> > The system can be disabling HW acceleration unbeknowst to the user,
> > leading to a long debug session trying to work out which component
> > is
> > failing. A quick mention that it is the
; > > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin > > > wrote:
> > > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund
> > > > wrote:
> > > > >
> > > > > On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote:
> > > >
n Fri, Oct 18, 2019 at 4:08 PM Marek Olšák wrote:
> > On Fri, Oct 18, 2019 at 9:07 AM Ilia Mirkin
> > wrote:
> > > On Fri, Oct 18, 2019 at 9:04 AM Erik Faye-Lund
> > > wrote:
> > > >
> > > > On Fri, 2019-10-18 at 08:57 -0400, Ilia Mir
On Fri, 2019-10-18 at 08:57 -0400, Ilia Mirkin wrote:
> On Fri, Oct 18, 2019 at 8:51 AM Erik Faye-Lund
> wrote:
> > On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote:
> > > In the meanwhile (unless you plan on taking up Jason's
> > > suggestion),
> &g
On Thu, 2019-10-17 at 20:55 -0500, Jason Ekstrand wrote:
> On Thu, Oct 17, 2019 at 10:39 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > This is discussed in the merge request thread. Zink currently only
> > support vertex and fragment shaders, so it's the
On Thu, 2019-10-17 at 22:24 -0400, Ilia Mirkin wrote:
> In the meanwhile (unless you plan on taking up Jason's suggestion),
> might I recommend some assert's for the unhandled cases so that there
> are no surprises?
Good idea. I sent a MR for it here:
This is discussed in the merge request thread. Zink currently only support
vertex and fragment shaders, so it's the only place this can occur. If someone
wants to enable this for drivers that supports geometry or tesselation shaders,
they would need to extend this code first. Unless I beat them
;
> + virgl_resource_layout(>u.b, >metadata);
>
> res->hw_res = vs->vws->resource_create_from_handle(vs->vws,
> whandle);
> if (!res->hw_res) {
Whoops! Good catch, sorry for the mess!
Reviewed-by: Erik Faye-Lund
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, 2019-07-10 at 06:24 -0700, Alyssa Rosenzweig wrote:
> Fixes a buggy dEQP test.
>
Maybe you could share which test this fixes, so someone can fix it?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On Wed, 2019-07-10 at 06:24 -0700, Alyssa Rosenzweig wrote:
> Fixes a buggy dEQP test.
>
> Signed-off-by: Alyssa Rosenzweig
> ---
> .../drivers/panfrost/ci/expected-failures.txt | 6 --
> src/gallium/drivers/panfrost/meson.build | 1 +
> .../drivers/panfrost/midgard/compiler.h | 6
to enable PIPE_CAP_VERTEX_SHADER_SATURATE
without enabling the rest. But for now, I leave that up to follow-up
patches.
I'm intentionally sending just the cover-letter here. You can see the
merge request on gitlab here:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1266
Erik Faye-Lund (5):
mesa/st: dro
On Thu, 2019-07-04 at 10:02 +0200, Tomeu Vizoso wrote:
> In that case, ctx->pipe_framebuffer.cbufs[0] can be NULL.
>
> Signed-off-by: Tomeu Vizoso
> Cc: Boris Brezillon
> Fixes: 5375d009be18 ("panfrost: Pass referenced BOs to the SUBMIT
> ioctls")
Nit: this isn't really about off-screen vs
On Wed, 2019-07-03 at 12:33 +0200, Boris Brezillon wrote:
> On Wed, 03 Jul 2019 11:54:29 +0200
> Erik Faye-Lund wrote:
>
> > On Wed, 2019-06-26 at 10:34 -0700, Alyssa Rosenzweig wrote:
> > > Ah-ha, now we're into parts of the stack I can c
On Sat, 2019-06-29 at 00:08 -0400, Ilia Mirkin wrote:
> Ken pointed out on IRC today that there was still a lot of "boolean"
> (vs bool/_Bool) usage in gallium. In fact, many interfaces are
> specified with boolean.
>
> I had it in my mind that I had at some point removed most boolean
> usage,
On Wed, 2019-06-26 at 10:34 -0700, Alyssa Rosenzweig wrote:
> Ah-ha, now we're into parts of the stack I can claim to understand!
> >:)
>
> Reviewed-by: Alyssa Rosenzweig
>
> On Tue, Jun 25, 2019 at 06:37:48PM +0200, Boris Brezillon wrote:
> > From: Daniel Stone
> >
> > Add a
On Tue, 2019-06-25 at 18:37 +0200, Boris Brezillon wrote:
> This is an attempt at resurrecting Daniel's MR [1] which was already
> resurrecting Harish's EGL_KHR_partial_update series [2]. This version
> implements Marek's suggestion to pass the set_damage_region()
> directly
> to the gallium
On Tue, 2019-06-25 at 12:36 -0700, Vasily Khoruzhick wrote:
> On Tue, Jun 25, 2019 at 11:54 AM Alyssa Rosenzweig
> wrote:
>
> Hi Alyssa,
>
> > Rather than using a magic lookup table with no explanations, let's
> > add
> > liberal comments to the code to explain what this tiling scheme is
> >
A while back, Laura and Jean was working on a Sphinx-conversion of the
mesa-documentation. Sadly this work stranded due to it also trying to
move to using GitLab Pages for hosting www.mesa3d.org, and because the
documentation and the websit eis the same thing, this lead to problems
with hosting
On Wed, 2019-06-12 at 14:03 -0400, Adam Jackson wrote:
> On Wed, 2019-06-12 at 10:29 +0200, Erik Faye-Lund wrote:
> > On Wed, 2019-06-12 at 10:25 +0200, Erik Faye-Lund wrote:
> > > On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote:
> > > > On Tue, 2019-06-11
On Wed, 2019-06-12 at 10:25 +0200, Erik Faye-Lund wrote:
> On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote:
> > On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote:
> >
> > > So here's the question: How does people feel about hosting this
On Tue, 2019-06-11 at 12:41 -0400, Adam Jackson wrote:
> On Tue, 2019-06-11 at 11:13 +0200, Erik Faye-Lund wrote:
>
> > So here's the question: How does people feel about hosting this
> > under
> > https://gitlab.freedesktop.org/mesa/ogl-sample/? If people are OK
> &
While looking into dead-links on our website, I noticed that the OpenGL
Sample Implementation that SGI open sourced lacks a proper public
mirror. So I'm looking to fix this.
The tarballs are currently available from here:
On Mon, 2019-05-27 at 13:37 +0200, Erik Faye-Lund wrote:
> On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote:
> > On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund
> > wrote:
> > > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> > > > This ends up embedded
On Mon, 2019-05-27 at 04:23 -0700, Rob Clark wrote:
> On Mon, May 27, 2019 at 2:50 AM Erik Faye-Lund
> wrote:
> > On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> > > This ends up embedded in a for loop expression, ie. the C part in
> > > an
> > > fo
On Sat, 2019-05-25 at 15:44 -0700, Rob Clark wrote:
> This ends up embedded in a for loop expression, ie. the C part in an
> for (A;B;C)
>
> iirc, that means it needs to be a C expr rather than statement.. or
> something roughly like that, I'm too lazy to dig out my C grammar
>
Can't you just
On Wed, 2019-05-22 at 18:06 +0200, Akim Demaille wrote:
> Hi Erik,
>
> > Le 22 mai 2019 à 08:54, Erik Faye-Lund <
> > erik.faye-l...@collabora.com> a écrit :
> >
> > I ended up reverting the change [from-%error-verbose to %define
> > parse.error
On Wed, 2019-05-22 at 20:41 +0200, Akim Demaille wrote:
> > Le 22 mai 2019 à 18:06, Akim Demaille a écrit
> > :
> >
> > Hi Erik,
> >
> > > Le 22 mai 2019 à 08:54, Erik Faye-Lund <
> > > erik.faye-l...@collabora.com> a écrit :
> >
On Wed, 2019-05-22 at 15:21 +0200, Hans Åberg wrote:
> > On 22 May 2019, at 08:54, Erik Faye-Lund <
> > erik.faye-l...@collabora.com> wrote:
> >
> > The problem is that Bison doesn't seem to have any mechanism for
> > doing
> > statements lik
-
processing.
We can cross that bridge when we get there. Perhaps by then the world
looks a bit differently?
On Tue, 2019-05-21 at 15:51 +0200, Erik Faye-Lund wrote:
> Right. I guess with an old enough bison version, this can happen.
> I'll see if I can come up with something better.
>
&g
, GitLab Mirror wrote:
> Module: Mesa
> Branch: master
> Commit: eb85124a9f6e9cb94d0d4a99f91bbae374777e3a
> URL: https://nam04.safelinks.protection.outlook.com/?url=""
>
> Author: Erik Faye-Lund
> Date: Mon May 20 13:29:05 2019 +0200
>
> glsl
On Tue, 2019-04-16 at 01:49 +, Alyssa Rosenzweig wrote:
> This (fairly large) patch continues work surrounding the panfrost_job
> abstraction to improve job lifetime management. In particular, we add
> infrastructure to track which BOs are used by a particular job
> (currently limited to the
Yeah, moving this to the mesa group in gitlab would be great for
visibility.
On Sat, 2019-04-13 at 12:22 +, Jean Hertel wrote:
> Any other mesa developer interested in seeing this move forward?
>
> Kind Regards,
> Jean Hertel
>
> ___
> mesa-dev
Nice move to put the logic in its own function!
Reviewed-by: Erik Faye-Lund
On Mon, 2019-04-08 at 09:39 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason
On Mon, 2019-04-08 at 12:39 +0200, Samuel Pitoiset wrote:
> On 4/8/19 12:32 PM, Erik Faye-Lund wrote:
> > On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> > > This fixes the following LLVM error when using
> > > RADV_DEBUG=checkir:
> > > Intrinsic
On Mon, 2019-04-08 at 11:39 +0200, Samuel Pitoiset wrote:
> This fixes the following LLVM error when using RADV_DEBUG=checkir:
> Intrinsic name not mangled correctly for type arguments! Should be:
> llvm.amdgcn.buffer.atomic.add.i32
> i32 (i32, <4 x i32>, i32, i32, i1)*
On Mon, 2019-04-01 at 12:43 -0700, Lepton Wu wrote:
>
>
> On Tue, Mar 19, 2019 at 4:29 AM Erik Faye-Lund <
> erik.faye-l...@collabora.com> wrote:
> > On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> > > virgl render complains about "Ill
On Mon, 2019-03-18 at 14:44 -0700, Lepton Wu wrote:
> virgl render complains about "Illegal resource" when running
> dEQP-EGL.functional.color_clears.single_context.gles2.rgb888_window,
> the reason is that a zero bind value was given for temp resource.
>
> Signed-off-by: Lepton Wu
> ---
>
On Wed, 2019-03-06 at 13:39 +1000, Dave Airlie wrote:
> On Wed, 6 Mar 2019 at 01:01, Erik Faye-Lund
> wrote:
> > When we try to do a vrend transfer from a renderable texture, we
> > end up
> > using glReadPixels to read the data. However, OpenGL ES has
> > restrictio
When we try to do a vrend transfer from a renderable texture, we end up
using glReadPixels to read the data. However, OpenGL ES has
restrictions on what formats are allowed to be used for glReadPixels.
In partcular, only GL_UNSIGNED_BYTE + GL_RGBA are guaranteed to be
supported (for OpenGL ES 2.0;
Yeah, good move!
Reivewed-by: Erik Faye-Lund
On Mon, 2019-02-25 at 11:57 +, Emil Velikov wrote:
> From: Emil Velikov
>
> Mention the tick-box otherwise only the MR author can rebase the
> series.
>
> Cc: Jordan Justen
> Cc: Dylan Baker
> Cc: Erik Faye-Lu
On Thu, 2019-02-14 at 16:25 +0100, Gert Wollny wrote:
> > > > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > > > tournier.e...@gmail.com> wrote:
> [...]
> > > > > A solution would be to inline the
> > > > > function in GLSL but I'm scared than the following shader
> > > > > will
> > > > >
On Wed, 2019-02-13 at 11:53 -0800, Ian Romanick wrote:
> On 2/13/19 9:59 AM, Juan A. Suarez Romero wrote:
> > On Wed, 2019-02-13 at 09:16 -0800, Ian Romanick wrote:
> > > On 2/13/19 7:53 AM, Juan A. Suarez Romero wrote:
> > > > On Tue, 2019-02-12 at 16:22 -0800, Ian Romanick wrote:
> > > > > On
On Thu, 2019-02-14 at 08:53 +1000, Dave Airlie wrote:
> On Thu, 14 Feb 2019 at 06:04, Stéphane Marchesin
> wrote:
> > On Wed, Feb 13, 2019 at 11:09 AM Elie Tournier <
> > tournier.e...@gmail.com> wrote:
> > >
> > >
> > > On Wednesday, 13 February 2019, Stéphane Marchesin <
> > >
Reviewed-by: Erik Faye-Lund
And just for the record, I think this is the right "compromise" between
checking all possible formats and facilitating fallbacks.
On Tue, 2019-02-12 at 22:40 -0500, Ilia Mirkin wrote:
> If the driver supports PIPE_BIND_BLENABLE on RGBA32F, flip
>
On Tue, 2019-02-05 at 06:26 +, Alyssa Rosenzweig wrote:
> In addition to the DRM interface in active development, for legacy
> kernels Panfrost has a small, optional, out-of-tree glue repository.
> For
> various reasons, this legacy code should not be included in Mesa
> proper,
> but this
systems, one of them used to
> be my main system. Not being able to use meson on those systems
> without this patch is a big deal for me.
This sounds like you have indeed tested on xcb-randr < 1.12, so I
suppose the answer to the question is "yes"? If so, I think it's all
go
On Wed, 2019-01-30 at 12:32 -0500, Marek Olšák wrote:
> ping
>
Probably worth including Keith, who added this line...
But yeah, I tend to think that this makes sense. The autotools-build
doesn't seem to tie this to a specific version, and seems to have been
used without problems for almost a
On Tue, 2019-01-29 at 14:41 +, Roland Scheidegger wrote:
> Am 29.01.19 um 10:10 schrieb Erik Faye-Lund:
> > On Mon, 2019-01-28 at 09:31 -0800, Matt Turner wrote:
> > > Use the trick of adding and then subtracting 2**52 (52 is the
> > > number
> > > of
&
On Mon, 2019-01-28 at 17:20 -0500, Rob Clark wrote:
> On Mon, Jan 28, 2019 at 2:29 PM Ilia Mirkin
> wrote:
> > 2. I've seen a bunch of things land where I would have had comments
> > beforehand. Once the patch is in, I don't really have an easy way
> > to
> > provide feedback. In the past if such
On Mon, 2019-01-28 at 09:31 -0800, Matt Turner wrote:
> Use the trick of adding and then subtracting 2**52 (52 is the number
> of
> explicit mantissa bits a double-precision floating-point value has)
> to
> implement round-to-even.
>
> Cuts the number of instructions on SKL of the piglit test
>
On Mon, 2019-01-28 at 09:22 -0800, Eric Anholt wrote:
> Erik Faye-Lund writes:
>
> > On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote:
> > > Nick Kreeger writes:
> > >
> > > > The OES_texture* extensions for float and half-float are val
On Fri, 2019-01-25 at 13:41 -0800, Eric Anholt wrote:
> Nick Kreeger writes:
>
> > The OES_texture* extensions for float and half-float are valid when
> > GLES2 is present w/ the matching
> > OES_texture_float/OES_texture_half_float extensions. This fix
> > ensures
> > that these formats are
On Wed, 2019-01-23 at 14:47 +, Eric Engestrom wrote:
> On Thursday, 2019-01-17 15:55:44 +0100, Erik Faye-Lund wrote:
> > It could have been made obvious for instance by showing the commit-
> > graph next to the commit-list, decorating it with the branch head
> > in
On Wed, 2019-01-23 at 17:03 +, Emil Velikov wrote:
> Hi all,
>
> In case the patch is still outstanding, feel free to add
> Reviewed-by: Emil Velikov
>
Thanks, pushed.
> On Wed, 23 Jan 2019 at 11:20, Erik Faye-Lund
> wrote:
> > On Wed, 2019-01-23 at 10:42
On Wed, 2019-01-23 at 10:42 +, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 11:21:27 +0100, Erik Faye-Lund wrote:
> > On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote:
> > > Hi,
> > >
> > > On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
On Wed, 2019-01-23 at 10:08 +, Eric Engestrom wrote:
> On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > Sending MRs from the main Mesa repository increase clutter in the
> > repository, and decrease visibility of project-wide branches. So
> > it's
>
On Wed, 2019-01-23 at 10:14 +, Daniel Stone wrote:
> Hi,
>
> On Wed, 23 Jan 2019 at 10:09, Eric Engestrom <
> eric.engest...@intel.com> wrote:
> > On Wednesday, 2019-01-23 10:36:15 +0100, Erik Faye-Lund wrote:
> > > Sending MRs from the main
On Thu, 2019-01-17 at 08:38 +0100, Erik Faye-Lund wrote:
> On Fri, 2019-01-11 at 10:57 -0600, Jason Ekstrand wrote:
> > All,
> >
> > The mesa project has now hit 100 merge requests (36 are still
> > open).
> > I (and I'm sure others) would be curious to h
Sending MRs from the main Mesa repository increase clutter in the
repository, and decrease visibility of project-wide branches. So it's
better if MRs are sent from forks instead.
Let's add a note about this, in case its not obvious to everyone.
Signed-off-by: Erik Faye-Lund
---
docs
1 - 100 of 746 matches
Mail list logo
