bm_bo_map definitely has to handle tiling, that's one of its main purposes.
It also really has to handle implicit synchronization, since there's no GBM API
for explicit synchronization.
Just doing a direct mmap for gbm_bo_map can be bad for other reasons as well.
E.g. if the BO storage
On 2024-06-17 19:18, Pierre Ossman wrote:
> On 17/06/2024 18:09, Michel Dänzer wrote:
>>>
>>> Can I know whether it is needed or not? Or should I be cautious and always
>>> do it?
>>
>> Assuming GBM in the X server uses the GPU HW driver, I'd say
On 2024-06-17 17:27, Pierre Ossman wrote:
> On 17/06/2024 16:50, Michel Dänzer wrote:
>> On 2024-06-17 12:29, Pierre Ossman wrote:
>>>
>>> Just to avoid any uncertainty, are both of these things done implicitly by
>>> gbm_bo_map()/gbm_bo_unmap()?
>>>
&
On 2024-06-17 16:52, Christian König wrote:
> Am 17.06.24 um 16:50 schrieb Michel Dänzer:
>> On 2024-06-17 12:29, Pierre Ossman wrote:
>>> Just to avoid any uncertainty, are both of these things done implicitly by
>>> gbm_bo_map()/gbm_bo_unmap()?
>>>
>>&g
a blit from the real BO to a staging one for CPU access.
> 6. ioctl(DMA_BUF_IOCTL_SYNC, &{ .flags = DMA_BUF_SYNC_START |
> DMA_BUF_SYNC_READ })
gbm_bo_map() should do this internally if needed.
> 7. pixman_blt()
> 8. gbm_bo_unmap()
--
Earthling Michel Dänzer
, you need to file a user verification issue.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
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
ering 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
Libr
ately. (This performance 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
on a system?
Both should 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 the
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 n
buf poll 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
and provide the existing synchronization 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
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 | Mes
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
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
ce/
The floor at the bottom left of the Actual 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
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 |
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 c
ommit 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 wi
it'll keep 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.freedesk
'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.
--
Ea
've been 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
/ instead. Other than that, no changes
should be necessary 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.
benefit 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://
is is possible 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 |
from the fd into the queue.
One way to 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
't compile
> 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 |
aders 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
R.
(One gotcha is that an e-mail is only sent for the original 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 |
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?
&
how to use Gitlab to verify that
> 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 a
e 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.freedeskto
ered 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
___
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
--
Earth
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 |
t;
> Implicit sync really means that 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 kern
isn't enough 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
.
Not sure what difference it 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
be only triggered 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
_
which is 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
an one which is already 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
pported, it needs 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.f
ns to be in 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
ticular 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 sof
hat in 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(&templ, new_tokens);
>templ.stream_output.num_outputs = 0;
>
>if (streamout) {
>
--
Earthling Michel Dänzer | htt
-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 m
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
-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, it
N for
presentation. Is that really how game engines (want to) work?
Instead, have you 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? Cou
o bother
with proper time calculations 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 proje
t;> Pierre
>
> 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
trying this,
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
___
o 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
in. :) 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 |
gh per day.
Yeah, I think we're a 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
a
ster). 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
X-Gitlab-* headers for easy filtering.
[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
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
run 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
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
example.
[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
https://gitlab.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 s
which 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://list
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
>>&
ext *_ctx, __DRIdrawable *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&
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! :)
ether (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
___
m
wed-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
uld fail at 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 soft
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 fig
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.
--
Earthli
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.
>&g
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 Velikov
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
> >/etc/apt/sources.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 wh
t *)key1) == major(*(dev_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 *)ke
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
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/pi
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.
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
E_FLUSH_* flags
(not) 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 mail
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 softwa
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
| 4 ++--
> 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
and/ci-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.fr
, so I included 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 develop
mit/0ec9a13c2a207e98e2dd6b352552c0e069af0727
.
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
1 - 100 of 2258 matches
Mail list logo
