));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus drm_wait_vblank().
Looks good to me other than that.
--
Earthling Michel Dänzer| http
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
On 30.07.2014 06:32, Daniel Vetter wrote:
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+ drm_vblank_wait(crtc
Michel Dänzer:
- Restore lost notes about v3:
- Spelling in kerneldoc.
- Inline wait_event condition.
- s/vblank_wait/wait_one_vblank/
Cc: Michel Dänzer mic...@daenzer.net
Cc: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed
On 31.07.2014 00:21, Thierry Reding wrote:
On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
On 30.07.2014 17:22, Daniel Vetter wrote:
On Wed, Jul 30
On 31.07.2014 16:54, Daniel Vetter wrote:
On Thu, Jul 31, 2014 at 3:14 AM, Michel Dänzer mic...@daenzer.net wrote:
I think it would be better to refactor drm_wait_vblank() than to
reinvent it.
That's the ioctl implementation which spends most of its time decoding
ioctl structures. If we
changes to allow the kernel to keep the vertical blank counters
consistent, since on many devices the hardware vertical blank counter is
reset to 0 at some point during modeset changes.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast
Digging out an ooold post of Daniel's...
On 04.03.2014 18:13, Daniel Vetter wrote:
On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel Dänzer wrote:
When the pre/post-modeset hooks were originally added, it worked like
this: the pre-modeset hook enabled the vblank interrupt, which updated
On 28.05.2014 20:19, Ville Syrjälä wrote:
On Wed, May 28, 2014 at 06:12:54PM +0900, Michel Dänzer wrote:
Digging out an ooold post of Daniel's...
On 04.03.2014 18:13, Daniel Vetter wrote:
On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel Dänzer wrote:
When the pre/post-modeset hooks were
On 29.05.2014 19:56, Daniel Vetter wrote:
On Thu, May 29, 2014 at 6:11 AM, Michel Dänzer mic...@daenzer.net wrote:
We could rename the off/on to pre/post_modeset if you like, but then
someone gets to audit all the other drivers. That someone isn't
going to be me.
I appreciate your caution
modesets, assuming the modeset resets the hardware
vblank counter.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx
On Mon, 2014-02-24 at 14:11 +0200, Ville Syrjälä wrote:
On Mon, Feb 24, 2014 at 12:48:55PM +0900, Michel Dänzer wrote:
On Fre, 2014-02-21 at 21:03 +0200, ville.syrj...@linux.intel.com wrote:
We can kill of the drm_vblank_{pre,post}_modeset() calls since those are
there simply to make
can't
imagine any user of this API requiring non-monotonic timestamps and
breaking with monotonic ones. I think it was simply a mistake that we
didn't make them monotonic in the first place (or maybe it wasn't even
possible when this API was first introduced).
--
Earthling Michel Dänzer
On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote:
On Fri, 2012-10-05 at 15:55 +0200, Michel Dänzer wrote:
On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote:
In practice we never want the timestamps for vblank and page flip events
to be affected by time adjustments, so in addition
probably be a bool rather than an int.
Looks good to me otherwise, as does patch 1.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
Intel-gfx mailing
interrupt is disabled, does it? It returns the sequence
number from the last time vblank_disable_and_save() was called (when the
vblank interrupt was disabled). That's why drm_vblank_get() is needed here.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software
On 18.03.2015 11:53, Michel Dänzer wrote:
On 18.03.2015 00:44, Chris Wilson wrote:
When userspace queries the current vblank for the CRTC, we can reply
with the cached value (using atomic reads to serialise with the vblank
interrupt as necessary) without having to touch registers
it again on the first query following the IRQ.
As I mentioned before, it might not be too hard to make querying the
current counter work without enabling the interrupt. But this looks like
a step in the right direction.
Acked-by: Michel Dänzer michel.daen...@amd.com
--
Earthling Michel Dänzer
drm_vblank_pre/post_modeset will be purely
drm internal for the old UMS ioctl.
Note that the kerneldoc for pre/post_modeset is wrong since as Michel
Dänzer correctly pointed out it works if only using pre/post_modeset.
The trouble that lead to this comment is the very old version
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent to the older per/post modeset
functions, except that they block out drm_vblank_get right away.
There's
On 28.05.2015 17:38, Daniel Vetter wrote:
On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote:
These should be functionally equivalent
On 28.05.2015 18:03, Michel Dänzer wrote:
On 28.05.2015 17:38, Daniel Vetter wrote:
On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:41, Daniel Vetter wrote:
On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
On 27.05.2015 18:04, Daniel Vetter wrote
state to on again. You can avoid
that with something like sleep 1 xset dpms force off.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx
ug which causes the counter to jump
forward with drm_vblank_on/off(). It may not manifest itself with
current Intel hardware because that has a full 32-bit hardware frame
counter, turning the related calculations into no-ops. I haven't had
time to investigate this further yet.
--
Earthling Miche
many vertical blank periods occurred since the interrupt was disabled.
> But also this series is not fully tested. Apparently I have an issue yet
> with flip-vs-expired-vblank_* tests and pm_rpm basic tests.
Maybe some of the test failures are due to the abo
On 08/09/16 02:23 AM, Imre Deak wrote:
> This fixes the error path for platforms that don't define the new
> page_flip_target() hook.
>
> Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2")
> Testcase: igt/kms_flip/basic-flip-vs-dpms
> CC: Michel Dänzer <m
D GPUs:
xf86-video-ati supports old GPUs on which glamor can't work, so
-modesetting can never be a complete replacement.
xf86-video-amdgpu is also used by the amdgpu-pro stack, with
modifications which are probably unsuitable for -modesetting. There's
also still a feature gap to -modesetting, e.g.
On 07/12/16 11:49 PM, Daniel Vetter wrote:
> vgem (and our igt tests using vgem) need this. I suspect etnaviv will
> fare similarly.
>
> v2. Make it build. Oops.
>
> Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
> non-KMS driver")
&
ver here (on the mails, not in the patch
> body).
That could be because he has "Avoid duplicate copies of messages?"
enabled in his mailman subscription options.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
ts those two branches
> working again
>
> Sorry to be the bearer of bad news - I'm guessing this is PRIME related
It's not. You can choose between
https://patchwork.freedesktop.org/patch/125754/
or
https://patchwork.freedesktop.org/patch/125644/
for the fix. :)
eone would call a cursor_set ioctl
> in parallell for two crtcs at the same time and race writing the
> position registers?
> Note that the device has only a single global cursor.
> Admittedly the effects of a race would probably be small, but I'd rather
> see it
On 22/03/17 07:06 PM, Chris Wilson wrote:
> Move the repeated (a - b) <= (1 << 23) to its own function.
>
> v2: Catch the '1<<23' inside drm_handle_vblank() as well
>
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
Reviewed-by: Michel Dänzer <
vblwait->request.sequence) <= (1 << 23) ||
> + vblank_passed(drm_vblank_count(dev, pipe),
> + vblwait->request.sequence) ||
> !READ_ONCE(vblank->enabled));
> }
&
in a respectful and civilised manner when
> +interacting with community members on mailing lists, IRC, or bug
> +trackers. The community represents the project as a whole, and abusive
> +or bullying behaviour is not tolerated by the project.
>
Acked-by: Michel
From: Michel Dänzer <michel.daen...@amd.com>
This allows making the master screen's pixmap_dirty_list entries
explicitly reflect that we're now tracking the root window instead of
the screen pixmap, in order to allow Present page flipping on master
outputs while there are active slave o
From: Michel Dänzer <michel.daen...@amd.com>
Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
---
Chris / Ilia / Ben, this should be manageable for the intel/nouveau
drivers, right?
src/amdgpu_drv.h | 26 ++
src/amdgpu_kms.c | 18 +--
t; delayed switch no matter what.
Are you sure that this is working as intended?
https://bugs.freedesktop.org/show_bug.cgi?id=100399 sounds like
unbinding works even while Xorg is using the DRM device.
--
Earthling Michel Dänzer | http://www.amd.com
Libr
On 13/07/17 09:31 PM, Ilia Mirkin wrote:
> On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer <michel.daen...@amd.com>
>>>
>>> Signed-off-by: Michel Dänze
On 14/07/17 11:24 AM, Ilia Mirkin wrote:
> On Thu, Jul 13, 2017 at 10:14 PM, Michel Dänzer <mic...@daenzer.net> wrote:
>> On 13/07/17 09:31 PM, Ilia Mirkin wrote:
>>> On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer <mic...@daenzer.net> wrote:
>>>>
On 18/04/17 07:07 PM, Michel Dänzer wrote:
> From: Michel Dänzer <michel.daen...@amd.com>
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
>
> Chris / Ilia / Ben, this should be manageable for the intel/nouveau
> drivers, right?
Any feedback,
On 13/07/17 05:27 PM, Michel Dänzer wrote:
> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>> From: Michel Dänzer <michel.daen...@amd.com>
>>
>> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
>> ---
>>
>> Chris / Ilia / Ben, this should be
On 21/06/17 05:14 PM, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
>> On 21/06/17 04:38 PM, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>>>> This makes the redundant fb helpers .load_
be yet another bug,
> but might be relevant for your use-case. Just try to run both an fbdev
> application and some kms-native thing, and then SIGKILL the native kms
> app.
>
> But since pre-existing not really required, and probably too much effort.
I suspect something like
t; Cc: Daniel Vetter <daniel.vet...@intel.com>
> Cc: Jani Nikula <jani.nik...@linux.intel.com>
> Cc: Sean Paul <seanp...@chromium.org>
> Cc: David Airlie <airl...@linux.ie>
> Cc: dri-de...@lists.freedesktop.org
> Reported-by: Tommi Rantala <tt.rant...@g
Airlie <airl...@linux.ie>
> Cc: dri-de...@lists.freedesktop.org
> Reported-by: Tommi Rantala <tt.rant...@gmail.com>
> Cc: Tommi Rantala <tt.rant...@gmail.com>
> Cc: Michel Dänzer <mic...@daenzer.net>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
>
reset to 0 might happen? If there is, maybe it could be solved by
calling drm_crtc_vblank_off() before it might happen and
drm_crtc_vblank_on() after it might have happened.
Otherwise, might it be better not to use the HW counter at all when it's
known not to be reliable?
--
Earthling Michel Dänzer
On 07/11/17 11:50 AM, Ville Syrjälä wrote:
> On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
>> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
>>> Some HW vblank counters reset due to power management events, which messes
>>> up the vblank counting
ay be premature to start exposing hooks into it.
Sounds like it may not be too late to abandon the separate i915
scheduler in favour of the common one used by amdgpu and etnaviv?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast |
>>>
>>> Lukas
>>
>> I would say fixes, it doesn't look particularly scary. :)
>
> Agreed. If it's good enough for stable, it's good enough for -fixes!
It's not that simple, is it? Fast-tracking patches (some of wh
e tiling
mode is communicated via BO metadata.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h
On 2018-03-13 04:12 PM, Ville Syrjälä wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>
>>> To make it possible
On 2018-03-13 04:20 PM, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com>
>>>
>>> To make it possible
se run
git rm tests/gem_ctx_bad_exec
and re-send the patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.
s/int/u32/ in drm_core_check_feature() args
>>>
>>> Cc: Chris Wilson
>>> Signed-off-by: Ville Syrjälä
>>
>> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting
>> case for this. Exactly same problem as we have here. Would be good to a
(ChunMing) Zhou"
> Cc: Harry Wentland
> Cc: Michel Dänzer
> Suggested-by: Michel Dänzer
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/
s allowing DRI2/Present page flipping
while there's an SW cursor? That cannot work correctly, as the SW cursor
image is missing in the newly flipped pixmap, and the SW cursor code
will restore stale background contents to it when the cursor has to be
drawn again.
--
Earthling Michel Dänzer
On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
>
>
> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>>>> This adds support for outputting kerne
On 2019-03-13 2:37 p.m., Christian König wrote:
> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
>> On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
>>> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
>>>>
>>>> Den 12.03.2019 17.17, skrev Ville
On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
> On 3/13/19 11:54 AM, Christian König wrote:
>> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>>> On 2019-03-13 2:37 p.m., Christian König wrote:
>>>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
>>>>
uld need to be a mechanism for switching scanout to a linear,
CPU accessible framebuffer.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
NG, but later RADEON_INFO_ACCEL_WORKING2 had to
be added, because the former claimed acceleration was "working" in cases
where it really wasn't... That kind of thing could become ugly in the
long run if other Xorg driver start using atomic, and they'll inevitably
be broken in different ways
o make this perfectly clear, also add a comment to DRM_UNLOCKED.
>
> Cc: Emil Velikov
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 139 ++------
> include/drm/drm_ioctl.h | 3 +
> 2 files changed, 72 insertions(+), 70 deletions(-)
D
d expand our variable size reservation_list to take advantage
> of that extra space.
>
> Signed-off-by: Chris Wilson
> Cc: Christian König
> Cc: Michel Dänzer
> ---
> drivers/dma-buf/reservation.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> di
ce
supporting that.
Since this change is essentially a workaround for broken userspace which
can never have worked, and has the potential of subverting the ongoing
transition from using primary nodes to render nodes in userspace code,
there needs to be evidence supporting that the benefit outweighs the ris
Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The
> next patch will improve the kerneldoc and add a todo entry for this.
>
> Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors")
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Reported-by: Mi
ould your GPU_MAPPED above work for TT? I think we'll also need
> STOLEN, I'm even hearing noises that there's going to be stolen for
> discrete vram for us ...
Could i915 use DRM_MEM_PRIV for stolen? Or is there other hardware with
something similar?
witch/case to make code obvious.
>
> Analysis from Michel Dänzer:
>
> The waiting condition rely on all relevant places where vblank_count
> is modified calls wake_up(>queue).
>
> drm_handle_vblank():
> - Calls wake_up(>queue)
>
> drm_vblank_enable():
>
On 2019-06-27 9:35 a.m., Pekka Paalanen wrote:
>
> Are connector names in xrandr still using type_id in their names?
Yes, they are.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X dev
On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
> On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
>> On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
>>> A recent commit in clang added -Wtautological-compare to -Wall, which is
>>> enabled for i915 so w
On 2020-02-12 6:07 p.m., Nathan Chancellor wrote:
> On Wed, Feb 12, 2020 at 09:52:52AM +0100, Michel Dänzer wrote:
>> On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
>>> On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
>>>> On 2020-02-11 7:13
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
___
Intel-gfx mail
ady caught earlier.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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
ich keeps the generated code the same
>>>> (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and
>>>> the warning is silenced so we can catch more potential issues in the
>>>> future.
>>>>
>>>> Link: https://gi
that check is relevant for
> 32-bit x86 so we cannot remove it.
That's suprising. AFAICT N_RELOC(ULONG_MAX) works out to the same value
in both cases, and remain is a 32-bit value in both cases. How can it be
larger than N_RELOC(ULONG_MAX) on 32-bit (but not on 64-bit)?
--
Earthling Michel Dän
lly surprising? :)
> - _and_ you're using the legacy page_flip path, atomic flip doesn't
> support it
Simon Ser has VRR working with sway using the atomic KMS API.
> - _and_ the PAGE_FLIP_ASYNC flag is set.
AFAIK it works both without and with PAGE_FLIP_ASYNC. (Async just means
tearing if the
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
___
Intel-gfx mailing
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
it was an async flip or not.
As for the timestamp in the event, I'm not sure what the expectations
are for async flips, but I suspect it may not really matter. E.g. the
timestamp calculated to correspond to the end of the previous vertical
blank period might be fine.
--
Earthling Michel
s.
This definitely looks wrong. The counter value returned by the
get_vblank_counter hook is supposed to increment when a vertical blank
period occurs; page flips are not supposed to affect this in any way.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 2021-02-08 2:34 p.m., Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered
ly needed I think.
Per above, not sure this is really true.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing li
On 2021-02-08 12:49 p.m., Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend
an issue and mesa was using
SYS_kcmp to compare device node fds.
A far shorter and more portable solution is possible, so let me
prepare a Mesa patch.
Make sure to read my comments on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881 first. :)
--
Earthling Michel Dänzer
ace while evicted, and this will appear to user-space like the
> WC-mapped object suddenly became WB-mapped. But it appears like mesa
> doesn't care about this as long as the mappings are fully coherent.
FWIW, the Mesa radeonsi driver avoids surprises due to this (e.g. som
On 2021-09-30 14:27, Matthew Auld wrote:
> On 30/09/2021 11:04, Michel Dänzer wrote:
>> On 2021-09-29 13:54, Thomas Hellström wrote:
>>> On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
>>>> This should let us do an accelerated copy directly to the shmem page
>
>>>>> The driver exposing those details would be quite useful for userspace
>>>>> though, so that it can delay committing updates to late, but not too
>>>>> late. Setting a deadline to be the vblank seems easy enough, but it
&
no shift instead of <<, shouldn't it? Multiplying a value
in bytes by the page size doesn't make sense.
I didn't check the rest of the patch in detail, but it's easy introduce subtle
regressions with this kind of change. It'll require a lot of review & testing
scrutiny.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
't immediately think of something better, though.
>
> Yeah, I was wondering about that as well. Especially since I wanted to add
> some more flags in the future when for example a bandwidth quota how much
> memory can be moved in/out is exceeded.
>
> Something like phase1, phase2, pha
88 matches
Mail list logo
