u need to file a user verification issue.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
r tests. This
> is pretty much version 0.0.1. i.e. is clean enough to release.
FWIW, GTK4 seems to do a pretty decent job of this (based on casual
experimentation with
GDK_BACKEND=x11 gtk4-demo
i.e. not any kind of scientific investigation).
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
will need to switch e.g. to
the List-Id: header (list:mesa-dev.lists.freedesktop.org in gmail). (I manually
added the prefix to the subject of this mail, so that it'll match subject based
filters)
--
Earthling Michel Dänzer| https://redhat.com
Libre software
rformance trap is
why I think allowing mmap for dma-buf fds was a mistake)
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
uld work.
Did you hit a problem other than psc->driScreenDisplayGPU related code being
skipped (as is expected ATM with different drivers)?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
On 2021-06-01 12:49 p.m., Michel Dänzer wrote:
> On 2021-06-01 12:21 p.m., Christian König wrote:
>
>> Another question is if that is sufficient as security for the display server
>> or if we need further handling down the road? I mean essentially we are
>> moving
On 2021-06-01 3:18 p.m., Michel Dänzer wrote:
> On 2021-06-01 2:10 p.m., Christian König wrote:
>> Am 01.06.21 um 12:49 schrieb Michel Dänzer:
>>> On 2021-06-01 12:21 p.m., Christian König wrote:
>>>> Am 01.06.21 um 11:02 schrieb Michel Dänzer:
>>>>>
; > <mailto:ckoenig.leichtzumer...@gmail.com>> wrote:
> >> Am 01.06.21 um 12:49 schrieb Michel Dänzer:
> >>> On 2021-06-01 12:21 p.m., Christian König wrote:
> >>>> Am 01.06.21 um 11:02 schrieb Michel Dänzer:
> >>>&
On 2021-06-01 2:10 p.m., Christian König wrote:
> Am 01.06.21 um 12:49 schrieb Michel Dänzer:
>> On 2021-06-01 12:21 p.m., Christian König wrote:
>>> Am 01.06.21 um 11:02 schrieb Michel Dänzer:
>>>> On 2021-05-27 11:51 p.m., Marek Olšák wrote:
>>>>> 3
On 2021-06-01 12:21 p.m., Christian König wrote:
> Am 01.06.21 um 11:02 schrieb Michel Dänzer:
>> On 2021-05-27 11:51 p.m., Marek Olšák wrote:
>>> 3) Compositors (and other privileged processes, and display flipping) can't
>>> trust imported/exported fences. They need a
oll semantics as other drivers and high priority GFX contexts via
EGL_IMG_context_priority which can preempt lower priority ones).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
semantics as needed?
Surely there are resource limits for the per-context queues, so the kernel
driver needs to do some kind of virtualization / multi-plexing anyway, or we'll
get sad user faces when there's no queue available for .
I'm probably missing something though, awaiting enlight
On 2021-03-12 7:46 p.m., Quentin SCHIBLER wrote:
> GLVND depends on several X librairies.
Even if you build libglvnd with -Dx11=disabled ?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X develo
sent.
libGL includes GLX APIs, so it cannot be built with -Dglx=false.
If you want to avoid GLX, you can use GLVND's libOpenGL instead.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and
On 2021-02-13 3:15 a.m., Dylan Baker wrote:
I can't speak for anyone else, but a giant pile of vendored code that you're
expected to not update seems like a really bad idea to me.
I agree.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast
On 2021-02-02 5:55 p.m., Michel Dänzer wrote:
On 2021-02-02 6:44 a.m., Dave Airlie wrote:
On Mon, 1 Feb 2021 at 16:50, Dave Airlie wrote:
On Thu, 7 Jan 2021 at 21:11, Andreas Fänger
wrote:
don’t know why the current softpipe/swrast implementation
shouldn’t be conformant.
Interesting I
ual image definitely looks odd,
there's a hard line between the rock patterns.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev m
ing
the data out of the GL texture.
While mmap of a dma-buf file descriptor works in theory, direct CPU
reads from GPU accessible memory can be very slow on some platforms.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | M
On 2021-01-08 6:16 p.m., Michel Dänzer wrote:
On 2021-01-08 5:54 p.m., Chris Rankin wrote:
Hi,
I've just noticed a large drop in FPS (from 60 down to 15) when
playing World of Warcraft with the latest Mesa from Git.
A quick git bisect has identified this commit
4292fb2139282e6906d4ad2a8be2fd81ed7ca8af
Author: Michel Dänzer
Date: Mon Dec 21 15:41:56 2020 +0100
wsi/x11: Use PresentOptionAsync for MAILBOX present mode with Xwayland
This allows Xwayland to forward buffers to the Wayland compositor ASAP
for fullscreen / undecorated windows
breaking.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman
t spam the list, even on
branches (such as 20.3) where MSVC stays broken.
If that doesn't work I can always drop mesa-dev from the list.
Personally I find the failed master jobs on
https://gitlab.freedesktop.org/mesa/mesa/pipelines more annoying.
--
Earthling Michel
a Mesa developer for almost two decades, but I don't really
know any Python.
I'm really excited that people are starting to look into taking
advantage of Rust in Mesa!
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast
ary for Marge or GitLab CI in general. (Failure to adapt
the pages job means the public website wouldn't get updated to reflect
changes in the tree)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa
it of
not having to rebuild the image in the main project as well could change
things though.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
On 2020-06-24 5:19 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> I assume 2. refers to the case of a single late frame, where the
>> next frame hitting the original absolute target would result in a
>> second visible stutter. While writing
>>
https://
ible without either producing visible stutter again,
or de-synced audio/video for a noticeable period of time)
P.S. Have you more formally proposed a Vulkan extension in the
meantime? If so, could you provide a reference to that here?
--
Earthling Michel Dänzer |
o address this is as in
src/loader/loader_dri3_helper.c:dri3_wait_for_event_locked: the first
thread to enter waits for and processes a special event, then wakes up
other threads which have entered in the meantime.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5368 is my
proposed solution
> src/amd/llvm/ac_nir_to_llvm.c any more...
See https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5087 .
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Me
which can
be useful for filtering. E.g. issues have
X-GitLab-Issue-ID:
and MRs have
X-GitLab-MergeRequest-ID:
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-04-23 6:56 p.m., Dylan Baker wrote:
> Quoting Michel Dänzer (2020-04-23 09:24:45)
>> On 2020-04-23 6:19 p.m., Mark Janes wrote:
>>> Michel Dänzer writes:
>>>> On 2020-04-23 5:14 p.m., Mark Janes wrote
nal comment, not
for any edits. Therefore, it's better to only edit comments for minor
fixups)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 2020-04-23 6:19 p.m., Mark Janes wrote:
> Michel Dänzer writes:
>> On 2020-04-23 5:14 p.m., Mark Janes wrote:
>>>
>>> Does anyone have recommendations for how to use Gitlab to verify that
>>> there are no identified-but-unfixed bugs in a pending release?
&
> there are no identified-but-unfixed bugs in a pending release?
I'd say GitLab milestones could be used to address the issues you raised
above: Create a milestone for each release, and only cut the release
once all issues and MRs assigned to it have been dealt wi
and corresponding cost.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org
jobs don't exist at all in the pipeline, so they can't
be triggered by any means. :)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailin
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> pre-merge CI.
Thanks for the suggestion! I implemented something like this for Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
--
Earthling
o back to us, as it always did
> throughout these the past twelve years.
Not for the last year or so, when it's been part of the pre-merge CI
pipeline?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa
apps and compositors don't sync, so
> the driver has to guess when it should sync.
Making implicit sync work correctly is ultimately the kernel driver's
responsibility. It sounds like radeonsi is having to work around the
amdgpu/radeon kernel driver(s) not fully living up to this responsib
ugh with amdgpu)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On 2020-03-16 7:33 p.m., Marek Olšák wrote:
> On Mon, Mar 16, 2020 at 5:57 AM Michel Dänzer wrote:
>> On 2020-03-16 4:50 a.m., Marek Olšák wrote:
>>> The synchronization works because the Mesa driver waits for idle (drains
>>> the GFX pipeline) at the end of command
would make, since the same thing needs to be
done for explicit fences as well, doesn't it?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
red manually instead of automatically on every push.
That would again break Marge Bot.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mai
somewhat more robust:
>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569
>
> I'm not sure it's more robust, but yeah that a useful tool too.
>
> The reason I'm skeptical about the robustness is that we'll miss
> testing if this misses a path.
Surely missing a pat
ady caught earlier.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
ds to be tested in CI.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/
n the queue at the time)
c) Yet something else?
If it's a), given the extension talks about rounding to the nearest
upcoming frame, does VK_PRESENT_MODE_MAILBOX_KHR effectively behave
the same as VK_PRESENT_MODE_FIFO(_RELAXED)_KHR with this extension?
If it's b), there can be any number of image
icular for the radeonsi/RADV drivers (due to issues in addrlib). It
shouldn't be enabled by default before those issues are addressed (and
ideally CI coverage in place to prevent them from creeping back in).
--
Earthling Michel Dänzer | https://redhat.com
Libre software enth
n mind for next
> submits.
Thanks.
The CI pipeline does test building the svga driver (maybe the testing
coverage can be increased in the future? :), so it's at least
theoretically possible for an svga driver change to break the pipeline.
--
Earthling Michel Dänzer |
okens, 0);
>}
>
> - templ.tokens = new_tokens;
> + pipe_shader_state_from_tgsi(, new_tokens);
>templ.stream_output.num_outputs = 0;
>
>if (streamout) {
>
--
Earthling Michel Dänzer | https:/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-07 10:19 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> With variable refresh rate, it could certainly be useful for the
>> kernel to have this information as early as possible. It
>> shouldn't make a
On 2020-02-04 8:12 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> Hmm, I didn't fully realize this in my reading of the draft, thanks
>> Matias for pointing it out!
>>
>> That the timing of frame N+1 has to be specified when submitting frame
>> N for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-02-03 8:48 p.m., Keith Packard wrote:
> Michel Dänzer writes:
>
>> Instead of rounding to the nearest upcoming frame, should it
>> round to the earliest frame after the specified period has
>> passed? As written
u considered allowing the GOOGLE_display_timing
desiredPresentTime to be specified as a relative time, measured from
when the previous image of the swapchain was actually presented,
instead of as an absolute time? Could something like that also address
the motivation for VK_MESA_present_period?
- --
Ear
but to just use frames instead. (It would
be good to seek feedback on this from AMD DC developers and the larger
DRM kernel driver community as well)
P.S. It would be good to create a WIP merge request for this in the main
Mesa project, to have a central place for gatherin
gt;
> Oh, hello Pierre, forgotten to CC you in the first run, sorry!
>
> I'll recheck against LLVM 10.0-rc in the evening.
> This shouldn't stop Mesa 20.0 then any longer?!
> We have 1 month for fixing.
Mesa 20.0 can't support LLVM 11 any
otherwise git push will create a non-forked project on the fly, which
won't work for making MRs.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
create an MR by clicking on the URL in
the git push terminal output when pushing to the branch in your forked
repository.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X dev
again. :) In order to merge an MR, reassign it
to "Marge Bot" (@marge-bot). Marge will take care of rebasing and
merging the MR once the CI pipeline has passed.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast |
pretty long way from that becoming an issue.
Looking at https://gitlab.freedesktop.org/mesa/mesa/pipelines/charts ,
we've had a pretty constant rate of ~10-15 MRs being merged on average
per day this year, and currently the pipeline takes ~20 minutes on
average, allowing up to ~70 MRs to be merged p
AD:master). Gitlab will
> automatically mark the MR as "Merged".
These steps 2-4 should only be used in exceptional cases, as they will
bypass the CI pipeline. Normally, one should either wait for the CI
pipeline to come back green before merging, or click "Merge
automatically when pipeline succ
ng.
[0] Or for the whole Mesa group, if you prefer.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
On 2019-12-07 12:56 a.m., Rob Clark wrote:
> On Fri, Dec 6, 2019 at 3:46 PM Bas Nieuwenhuizen
> wrote:
>>
>> On Fri, Dec 6, 2019 at 10:49 AM Michel Dänzer wrote:
>>>
>>>
>>> I just merged
>>> https://gitlab.freedesktop.org/mesa/mesa/merge_re
all jobs by default
as before.
The main motivation for these changes is to avoid wasting CI runner
resources. In that same spirit, please also cancel any unneeded
build/test jobs. This can be done already before those jobs start
running, e.g. while the container stage jobs run.
On 2019-12-02 3:15 p.m., Tapani Pälli wrote:
> On 11/15/19 8:41 PM, Mark Janes wrote:
>> Michel Dänzer writes:
>>
>>> On 2019-11-15 4:02 p.m., Mark Janes wrote:
>>>> Michel Dänzer writes:
>>>>
>>>>> Now that the GitLab CI pipel
On 2019-11-15 4:02 p.m., Mark Janes wrote:
> Michel Dänzer writes:
>
>> Now that the GitLab CI pipeline tests a snapshot of piglit with llvmpipe
>> (https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2468), the
>> question has come up how to deal with inter-dependen
[1] Might soon be .gitlab-ci/container/x86_test.sh and DEBIAN_TAG in the
x86_test job definition, respectively, once
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2722 is merged.
--
Earthling Michel Dänzer | https://redhat.com
Libre software
tlab.freedesktop.org/mesa/mesa/issues/{issue}
>>
>> Is there an advantage to the !{issue} format? Perhaps gitlab parses it
>> and closes the issue?
>
> gitlab can parse both the !nnn format and full URLs, and yes, it does
> close issues when a commit with such a Closes: l
h the damage region applies?
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.fre
On 2019-08-30 6:52 p.m., Boris Brezillon wrote:
> On Fri, 30 Aug 2019 18:43:59 +0200
> Michel Dänzer wrote:
>
>>> diff --git a/include/GL/internal/dri_interface.h
>>> b/include/GL/internal/dri_interface.h
>>> index 4c60d349ddd5..e04bed689219 100644
>>&
Idrawable *drawable,
> + unsigned int nrects, int *rects);
> };
This would break the DRI2_BufferDamage extension version 1 ABI. You'd
need to either add a new hook like set_damage_region2 and bump
__DRI2_BUFFER_DAMAGE_VERSION (and make sure that's handled correctly
thub projects that
> having tests run during PRs are a god send.
Yeah.
>> With my last name spelled correctly Dänzer or Daenzer,
>
> Oops. I worried about getting the "ae" right and forgot the "n"..
> m(_ _)m
No worries, I appreciate your effort! :)
(which is what I've been asking all along :).
Given that, I'm in favour.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing
viewed-by: Michel Dänzer
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedeskt
t the
appveyor step, even if the pre-merge pipeline passed.
Not sure what can be done about this though, other than requiring forked
projects used for MRs to set up the appveyor integration as well.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthu
On 2019-08-02 6:12 p.m., Brian Paul wrote:
> On 08/02/2019 09:56 AM, Eric Engestrom wrote:
>> On Friday, 2019-08-02 17:50:17 +0200, Michel Dänzer wrote:
>>> On 2019-08-02 5:37 p.m., Brian Paul wrote:
>>>> Ugh, I didn't mean to do this. I'm trying to figure out ho
On 2019-08-02 5:37 p.m., Brian Paul wrote:
> Ugh, I didn't mean to do this. I'm trying to figure out how to make a
> merge request with gitlab.
Just push to a branch in your personal repository, and the output of git
push contains an URL for creating an MR for it.
--
Earthling Michel
On 2019-08-01 6:51 p.m., Emil Velikov wrote:
> On Thu, 1 Aug 2019 at 16:03, Emil Velikov wrote:
>>
>> On Thu, 1 Aug 2019 at 14:26, Michel Dänzer wrote:
>>> On 2019-08-01 2:32 p.m., Emil Velikov wrote:
>>
>>>> Sure I'll do that in a moment.
>>>
On 2019-08-01 2:32 p.m., Emil Velikov wrote:
> On Thu, 1 Aug 2019 at 09:35, Michel Dänzer wrote:
>>
>> On 2019-07-31 11:47 p.m., Eric Engestrom wrote:
>>> On Wednesday, 2019-07-31 16:07:45 +0200, Michel Dänzer wrote:
>>>> On 2019-07-31 3:26 p.m., Emil Veli
On 2019-07-31 11:47 p.m., Eric Engestrom wrote:
> On Wednesday, 2019-07-31 16:07:45 +0200, Michel Dänzer wrote:
>> On 2019-07-31 3:26 p.m., Emil Velikov wrote:
>>> On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote:
>>>>
>>>> On 2019-07-31 3:04 p.m., Em
On 2019-07-31 3:26 p.m., Emil Velikov wrote:
> On Wed, 31 Jul 2019 at 14:16, Michel Dänzer wrote:
>>
>> On 2019-07-31 3:04 p.m., Emil Velikov wrote:
>>> From: Emil Velikov
>>>
>>> Currently we use the python package to manage repositories. At the sam
ces.list.d/buster.list
> +echo "deb https://deb.debian.org/debian/ buster-updates main"
> >/etc/apt/sources.list.d/buster-updates.list
> apt-get update
> apt-get install -y \
>bzip2 \
>
This should be merged as part of an MR which requires the docker i
t *)key2) &&
^
src/gallium/winsys/svga/drm/vmw_screen.c:49:12: warning: implicit declaration
of function 'minor'; did you mean 'mknod'? [-Wimplicit-function-declaration]
minor(*(dev_t *)key1) == minor(*(dev_t *)key2)) ? 0 : 1;
^
m
On 2019-07-15 4:11 p.m., Newton, Jeremy wrote:
> Sorry about that, I've only used git email maybe three times in my life :)
Nothing to apologize for, everybody has to learn that kind of thing. :)
--
Earthling Michel Dänzer | https://www.amd.com
Libre softw
of Mesa's libgbm.
>
> Signed-off-by: Jeremy Newton
> Signed-off-by: Marek Olšák
> Reviewed-by: Michel Dänzer
> ---
> src/gallium/auxiliary/pipe-loader/pipe_loader_drm.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/gallium/auxiliary/pipe-lo
s set to amdgpu.
"Gallium driver name" instead of "dri driver name" might make it
slightly clearer why this is done.
Also, might be worth adding something to the commit log that this will
allow dropping the amdgpu-pro specific GBM implementation in favour of
Mesa's.
Eith
test and confirms
> if only regress with v3d?
It still passes for me with radeonsi & llvmpipe.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
m
) set corresponding to glFlush, but not for other internal flushes.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@li
controlled by meson's b_ndebug configuration item. While its
default value depends on the build type, it can be freely enabled or
disabled with any build type.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast |
On 2019-07-02 7:29 p.m., Marek Olšák wrote:
> If you don't wanna see the messages, don't use debugoptimized.
Makes sense, but means it needs to be guarded by DEBUG, not NDEBUG.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusi
On 2019-07-02 2:09 p.m., Mathias Fröhlich wrote:
> On Tuesday, 2 July 2019 10:25:41 CEST Michel Dänzer wrote:
>> On 2019-07-02 3:44 a.m., Dieter Nützel wrote:
>>>
>>> /opt/mesa> git bisect good
>>> b5697c311b6f29dee40b96c48bad3279e366
+--
> 18 files changed, 27 insertions(+), 29 deletions(-)
The changes to src/mesa/main/errors.c mean that Mesa now prints messages
on GL API usage errors by default when assertions are enabled, whereas
previously it only did so for debugging builds. This should probably be
reverted, since these mess
templates as needed and
using that.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.
luded that patch in the VegaM series. :-)
I think Alex's point (which I agree with) is that the commit log is
inaccurate and misleading.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
ec9a13c2a207e98e2dd6b352552c0e069af0727
.
See the top-level .gitlab-ci.yml file for a well-tested way to only
generate a docker image when needed, based on a fixed image tag.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast |
scrn->front_buffer = NULL;
>
Couldn't dri3_set_drawable be called for a pixmap first, then later for
a window, for the same scrn?
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X develop
error.majorCode = err->major_code;
>
As-is, this will re-introduce
https://bugs.freedesktop.org/show_bug.cgi?id=99781 . That one was about
__glXSendErrorForXcb, while the regressions are about __glXSendError, so
maybe only revert the __glXSendError hunk for now?
--
ak horribly there.
I trust you won't push this without testing GLX first then. :)
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
mesa-dev
s?
This patch doesn't prevent triple buffering. The application can still
prepare up to one frame worth of GPU commands before the GPU has
finished processing the commands of the previous frame (while the
pre-previous frame is being displayed).
I just think the term "in flight" should maybe be
ws->cs_sync_flush(sctx->gfx_cs);
> }
> }
>
> static void si_fence_server_signal(struct pipe_context *ctx,
> struct pipe_fence_handle *fence)
> {
> struct si_context *sctx = (struct si_context *)ctx;
>
Reviewed-by: Michel Dänzer
--
E
1 - 100 of 2182 matches
Mail list logo
