rendering
with a quick reset. Iirc someone (from cros google team maybe) was even
looking into making llvmpipe run on top of vgem as a real dri/drm mesa
driver.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-
, no idea. We might need to revamp all that. But for a
userspace client that does nothing fancy (no multiple render buffer
targets in one bo, or vk style "I write to everything all the time,
perhaps" stuff) there should be 0 perf difference between implicit sync
through dma_resv and explicit sync through sync_file/syncobj/dma_fence
directly.
If there is I'd consider that a bit a driver bug.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
hristian gets to fix up amdgpu more,
at least for anything that has a dma-buf attached even if it's not shared
with anything !amdgpu.ko).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X
video experts. (I just do 3D)
dma_fence has an error state which you can set when things went south. The
fence still completes (to guarantee forward progress).
Currently that error code isn't really propagated anywhere (well i915 iirc
does something like that since it tracks the depedencies internally
are messy. In the old
> system the feedback loop was simple, we don't have admin time or money
> for servers we don't get the features, cloud allows us to get the
> features and enjoy them and at some point in the future the bill gets
> paid by someone else. Credit cards lifesty
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
> > wrote:
> > > Hi all,
> > >
> > > You might have read the short take in the X.org boar
On Fri, Feb 28, 2020 at 4:38 AM 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.
> >
> > Th
On Fri, Feb 28, 2020 at 2:54 AM Carsten Haitzler wrote:
>
> On Thu, 27 Feb 2020 22:27:04 +0100 Daniel Vetter
> said:
>
> Might I suggest that given the kind of expenses detailed here, literally
> buying
> 1 - 4 reasonably specced boxes and hosting them at OSUOSL would be
sponsors, but
filling a shortfall of this magnitude is neither easy nor quick work,
and we therefore decided to give an early warning as soon as possible.
Any help in finding sponsors for fd.o is very much appreciated.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
is better since in
general there will be a bit of Q with organizers. The board plans to
make a final decision by end of July.
If you just have some questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote:
> On 2018-10-26 7:22 a.m., Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
&
On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > > wrote:
&
On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote:
>
> Hi,
>
> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote:
> > On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote:
> > > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> > &g
nsoring grants,
papers committee, and acquiring lots of sponsors. None of this is
spelled out in the bylaws, it's all in policies that the board
deliberates and approves. I think this same approach will also work
well for fd.o.
And if members are unhappy with what the board does, they can fix in
comments in private, please send them to
both the x.org board and gpul - they want to know how to improve and
what to keep for the next conference they're going to organize too.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
to seeing you there. If you have any
> inquiries/questions, please send an email to xdc2...@gpul.org, adding on
> CC the X.org board (bo...@foundation.x.org).
>
> Best regards,
>
> Sam
> _______
> mesa-dev mailing list
> mesa-...@li
On Thu, Jun 21, 2018 at 11:16 PM, Daniel Vetter wrote:
> Hi all,
>
> The X.org board is soliciting proposals to host XDC in 2019. By the usual
> rotation a location in (North) America is preferred, but the board will also
> consider other locations, especially if there's an
questions about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel
On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote:
> On 24 April 2018 at 20:14, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.veli...@gmail.com>
> > wrote:
> >> On 13 April 2018 at 11:00, D
On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 13 April 2018 at 11:00, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive communit
i Latvala <petri.latv...@intel.com>
Cc: Rodrigo Vivi <rodrigo.v...@intel.com>
Cc: Sean Paul <seanp...@chromium.org>
Reviewed-by: Keith Packard <kei...@keithp.com>
Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
---
If you wonder about the wide distribution list f
the X server and it can use that to enumerate the available displays
>>>> through the Vulkan API.
>>
>>
>> The thing is if you are running under X I don't think apps should be
>> bypassing
>> things and going straight to hw enumeration, it makes too many problems
>&
folks since 2-3 years now). Bunch of people decided not to do XDC this
year even, because too much travelling in one row. Plus Google's limit
in scheduling a room, plus Khr f2f. We'll try to do better next year,
but sometimes perfect scheduling is just not an option.
Thanks, Daniel
--
Daniel Vette
to this mail or send a mail to
bo...@foundation.x.org if you don't want the entire world to read it.
And if you want to send at pseudonymous feedback, drop a pastebin onto
the #xf-bod channel on the OFTC irc server.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79
h 6bpc panels really.
Right now userspace can't request a specific bpp for the sink/pipe,
that's fully under the kernel's control. It only gets to set the pixel
format of fbs.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Sun, Apr 02, 2017 at 12:58:33PM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > On that, I think we could just unconditionally hand leases all encoders.
> > Encoders turned out to be a bit an uapi mistake.
>
> Well, given the complexit
ll appear to be disconnected to
> + all clients other than the grabbing client.
> +
> +┌───
> +RRDestroyOutputGrab
> + outputgrab: OUTPUTGRAB
> +└───
> + Errors: OutputGrab
> +
> + Destroys the named OUTPUTGRAB.
> +
> + ❧❧❧
>
On Tue, Apr 04, 2017 at 08:53:45AM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > The multi-seat thing sounds like vapourware, I think we should care about
> > the vr use-case for now, and only that one.
>
> Ok, I can live with
On Mon, Apr 03, 2017 at 09:41:34AM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > Hm, if you restrict getresources and getplanes, you'll get your leased
> > objects query api. Iirc that part was missing in your kernel patch. And it
> > g
On Mon, Apr 03, 2017 at 03:50:33PM -0700, Keith Packard wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > Also if this confuses VR, then another reason why we want to make leases
> > invariant and only allow pure revoke, not changing the list.
>
de which failed at 30 bpp, might still work at 18bpp and is
> > better going to a lower resolution.
>
> The question was whether the kernel will ever allow the same mode at the
> same bpp, since that's what this patch tries to do.
Yes, this can happen. Doing a full modeset with recomputing clocks and
everything behind userspace's back might not be something the kernel
driver can pull of with a reasonable amount of effort, hence why we punt
to userspace. The interface spec makes this a CAN, not WILL, to allow less
unreasonable hw to handle these cases directly in the kernel driver. E.g.
plain link-retraining is handled in i915.ko still.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
On Thu, Feb 02, 2017 at 09:57:20AM -0800, Eric Anholt wrote:
> Daniel Vetter <dan...@ffwll.ch> writes:
>
> > On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> >> Jani Nikula <jani.nik...@linux.intel.com> writes:
> >>
> >> > On
cussion
in the other thread.
-Daniel
>
> Regards
> Manasi
>
> >
> > Regards
> > Manasi
> >
> >
> > On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> > > Martin Peres <martin.pe...@linux.intel.com> writes:
> > >
>
Manasi
>
>
> On Mon, Feb 13, 2017 at 01:05:17PM -0800, Eric Anholt wrote:
> > Martin Peres <martin.pe...@linux.intel.com> writes:
> >
> > > On 06/02/17 17:50, Martin Peres wrote:
> > >> On 03/02/17 10:04, Daniel Vetter wrote:
> > >>> On F
e modes again based on new link
> > paarmeters and send a new mode list back.
>
> Seems like a bad behaviour from the kernel, isn't it? It should return
> immediatly
> if the mode is gonna be pruned :s
The mode list pruning isn't relevant for modeesets, the kernel doesn't
validat
ew times, and I'd like
that to be an orthogonal abi extension. Right now we just don't have the
required tracking even within the kernel to know which connector changed
(and the tracking we do have missed a few things, too). My idea is to push
the tracking into the leaves of the callchains with a functio
ils...\n", con_id);
> +}
> +drmModeFreeProperty(props);
> +}
> +drmModeFreeConnector(koutput);
> +}
> +
> mode_res = drmModeGetResources(drmmode->fd);
> if (!mode_res)
>
's the way I always make edits. Way nicer than a web
> GUI. :-)
And if you have a shell account, it's easy to resurrect your web wiki
account:
https://wiki.freedesktop.org/sitewranglers/wiki/401/
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
about what organizing XDC entails,
please feel free to chat with a previous organizers, or with someone from
the board.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel
that.
Please send in your proposal to bo...@foundation.x.org latest by 28th
Oct to make sure the baord can consider it.
Thanks,
Daniel, secretary of the board
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
) defined(_SC_AVPHYS_PAGES) /* Solaris */
long pagesize, npages;
pagesize = sysconf(_SC_PAGESIZE);
--
1.7.9.2
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org
aligned which would look funky for full-screen apps I guess.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg
On Wed, Oct 22, 2014 at 04:03:21PM -0700, Andy Ritger wrote:
On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote:
On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger arit...@nvidia.com wrote:
I assume the TILE property described below would be per-connector?
It looks like this would
as a firmware image
which would contain the entire kms state, and which we'd apply in an
atomic modeset at driver load. Everyone else (boot splash, X, ...)
will then just inherit that config. That should give you even
flicker-free screen walls if you want to ;-)
Cheers, Daniel
--
Daniel Vetter
Software
. At least my minimal testing with a few X servers seemed to
indicate that that still worked ...
Or did you manage to get rid of the dummy console, too? That would be a
bug in the Kconfig logic we currently have.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48
this :(
On the plus side our QA has started another try at running with nouveau
(last time around was just too much fallout from nouveau) to run our neat
seat of prime tests. So investing into a few good tests there should pay
of nicely.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79
On Wed, Jun 12, 2013 at 12:28 PM, Terje Bergström tbergst...@nvidia.com wrote:
On 11.06.2013 15:09, Daniel Vetter wrote:
Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
is used to restart the ioctl if we had to kick a thread (to make sure
it doesn't hold any locks), e.g
the reset handler would do (kernel work item currently), not any
userspace process doing an ioctl. But atm we don't resubmit victimized
workloads.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Jun 11, 2013 at 1:43 PM, Terje Bergström tbergst...@nvidia.com wrote:
On 11.06.2013 14:00, Daniel Vetter wrote:
We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
which blew up the gpu (that one has been submitted already in a
different ioctl call), but to be able
@@
#include sys/wait.h
#include limits.h
#include wordexp.h
+#include signal.h
#include i915_drm.h
#include intel_bufmgr.h
--
1.7.9.2
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
xorg-devel
). Or something else.
To make the intel roundup complete: Chris, can I volunteer you to give
another stab at an updates from flatland talk?
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--disable-nouveau option for platforms without nouveau support
Applied them all, thanks a lot.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
when applying ...
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
generic 2d
accel code on top of GL. That should give you reasonable (albeit likely
not stellar) X render performance.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
xorg-devel@lists.x.org: X.Org development
Archives: http
by the Parfait 0.4.2 bug checking tool.
For more information see http://labs.oracle.com/projects/parfait/ ]
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
Thanks for the patch, applied.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
own buildsystem-fu is barely good enough to make
things compile ;-)
Thanks for your awesome work, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
to Solaris).
- You don't seem to touch the testsuite, and I think you want it on
Andriod, too.
Added xorg-devel to cc, maybe someone else has already tried this with a
different package, my buildsystem fu is not up to this.
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
On Fri, Jan 6, 2012 at 02:41, Gaetan Nadon mems...@videotron.ca wrote:
On 12-01-04 09:38 AM, Daniel Vetter wrote:
On Wed, Jan 4, 2012 at 15:33, Gaetan Nadon mems...@videotron.ca wrote:
On 12-01-04 04:52 AM, Daniel Vetter wrote:
While I have the attention of someone versed in buildsystem-fu
by abusing the automake test rig. Is this ok or is there a better way to
do something like this?
Thanks, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org
routine, how would this gets used by someone who installed the package
from a distro? I am wondering which files to install from this subdir.
The system_routine/debugger stuff is from Ben Widawsky. Adding him to
cc so he can join the fun.
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0
On Wed, Jan 4, 2012 at 15:33, Gaetan Nadon mems...@videotron.ca wrote:
On 12-01-04 04:52 AM, Daniel Vetter wrote:
While I have the attention of someone versed in buildsystem-fu:
intel-gpu-tools also contains a set of tests for the i915 kernel module
(and the libdrm interface for it). Currently
tinderbox be using make test instead of, or in addition to,
make check?
No, running that only makes sense when you have and intel gpu, and
even then you need a fairly recent kernel to no oops it ;-)
-Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
On Wed, Jan 4, 2012 at 16:39, Alan Coopersmith
alan.coopersm...@oracle.com wrote:
On 01/04/12 06:38, Daniel Vetter wrote:
One thing I'm wondering is whether we could easily ship these tests in
some form, so that users could run them from the distro package
instead of grabbing the sources
into here. I'll see what makes a good fit and shows best what
awesome stuff is currently going on in opens source graphics.
Cheers, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
xorg-devel@lists.x.org: X.Org development
Archives
65 matches
Mail list logo
