On Wed, Apr 28, 2021 at 10:35 AM Daniel Vetter wrote:
>
> On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> > Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
> > > > Am 28.04.21 um 14:26 schrieb Daniel Vetter:
> >
How do you run the opencl-cts tests on this?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1. Also add the overall
> upstream plan, including some notes for the TTM conversion.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are difference
On Monday, April 26, 2021 2:38:58 AM PDT Matthew Auld wrote:
> Add new extension to support setting an immutable-priority-list of
> potential placements, at creation time.
>
> If we use the normal gem_create or gem_create_ext without the
> extensions/placements then we still get the old behaviour
On Wednesday, April 28, 2021 9:56:25 AM PDT Jason Ekstrand wrote:
> On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld wrote:
[snip]
> > Slightly orthogonal: what does Mesa do here for snooped vs LLC
> > platforms? Does it make such a distinction? Just curious.
>
> In Vulkan on non-LLC platforms, we o
On Wed, Apr 28, 2021 at 11:41 AM Matthew Auld wrote:
>
> On 28/04/2021 16:51, Jason Ekstrand wrote:
> > On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1. Also add the overall
> >> upstream plan, including some notes for the TTM conversion.
On 28/04/2021 16:51, Jason Ekstrand wrote:
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1. Also add the overall
upstream plan, including some notes for the TTM conversion.
v2(Daniel):
- include the overall upstreaming plan
- add a note f
Hi all,
I'm filling in for Eric this week, but he'll be back next week. I'd
like to announce mesa 21.1.0-rc3 is now available for general
consumption. As always, this is a Release Candidate, and bug reports and
anything that has regressed are very much needed.
There's a bunch of work here, lots
On 28/04/2021 16:16, Kenneth Graunke wrote:
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
+Existing uAPI issues
+
+Some potential issues we still need to resolve.
+
+I915 MMAP
+-
+In i915 there are multiple ways to MMAP GEM object, including mapping the
On Mon, Apr 26, 2021 at 4:42 AM Matthew Auld wrote:
>
> Add an entry for the new uAPI needed for DG1. Also add the overall
> upstream plan, including some notes for the TTM conversion.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here
On Monday, April 26, 2021 2:38:53 AM PDT Matthew Auld wrote:
> +Existing uAPI issues
> +
> +Some potential issues we still need to resolve.
> +
> +I915 MMAP
> +-
> +In i915 there are multiple ways to MMAP GEM object, including mapping the
> same
> +object using differen
Am 28.04.21 um 16:34 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
Am 28.04.21 um 15:34 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
Am 28.04.21 um 14:26 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 02:21:5
On Wed, Apr 28, 2021 at 03:37:49PM +0200, Christian König wrote:
> Am 28.04.21 um 15:34 schrieb Daniel Vetter:
> > On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
> > > Am 28.04.21 um 14:26 schrieb Daniel Vetter:
> > > > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote
Am 28.04.21 um 15:34 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
Am 28.04.21 um 14:26 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
Am 28.04.21
On Wed, Apr 28, 2021 at 03:11:27PM +0200, Christian König wrote:
> Am 28.04.21 um 14:26 schrieb Daniel Vetter:
> > On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
> > > On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
> > > > Am 28.04.21 um 12:05 schrieb Daniel Vetter
Am 28.04.21 um 14:26 schrieb Daniel Vetter:
On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
Am 28.04.21 um 12:05 schrieb Daniel Vetter:
On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
On Tue, Apr 27,
On Wed, Apr 28, 2021 at 6:31 AM Christian König
wrote:
>
> Am 28.04.21 um 12:05 schrieb Daniel Vetter:
> > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> >> On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
> >>> On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
> >>> wrote:
On Wednesday, April 28th, 2021 at 2:21 PM, Daniel Vetter
wrote:
> Yeah I think we have pretty clear consensus on that goal, just no one yet
> volunteered to get going with the winsys/wayland work to plumb drm_syncobj
> through, and the kernel/mesa work to make that optionally a userspace
> fence
On Wed, Apr 28, 2021 at 02:21:54PM +0200, Daniel Vetter wrote:
> On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
> > Am 28.04.21 um 12:05 schrieb Daniel Vetter:
> > > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> > > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wr
On Wed, Apr 28, 2021 at 12:31:09PM +0200, Christian König wrote:
> Am 28.04.21 um 12:05 schrieb Daniel Vetter:
> > On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> > > On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
> > > > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
> >
Am 28.04.21 um 12:05 schrieb Daniel Vetter:
On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
wrote:
Ok. So that would only make the following use cases broken for now:
- amd
On Tue, Apr 27, 2021 at 02:01:20PM -0400, Alex Deucher wrote:
> On Tue, Apr 27, 2021 at 1:35 PM Simon Ser wrote:
> >
> > On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
> > wrote:
> >
> > > > Ok. So that would only make the following use cases broken for now:
> > > >
> > > > - amd render ->
On Tue, Apr 27, 2021 at 06:27:27PM +, Simon Ser wrote:
> On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher
> wrote:
>
> > It's an upcoming requirement for windows[1], so you are likely to
> > start seeing this across all GPU vendors that support windows. I
> > think the timing depends on
On Wed, Apr 28, 2021 at 11:07:09AM +0200, Michel Dänzer wrote:
> On 2021-04-28 8:59 a.m., Christian König wrote:
> > Hi Dave,
> >
> > Am 27.04.21 um 21:23 schrieb Marek Olšák:
> >> Supporting interop with any device is always possible. It depends on which
> >> drivers we need to interoperate with
On Wed, Apr 28, 2021 at 08:59:47AM +0200, Christian König wrote:
> Hi Dave,
>
> Am 27.04.21 um 21:23 schrieb Marek Olšák:
> > Supporting interop with any device is always possible. It depends on
> > which drivers we need to interoperate with and update them. We've
> > already found the path forwar
On 2021-04-28 8:59 a.m., Christian König wrote:
> Hi Dave,
>
> Am 27.04.21 um 21:23 schrieb Marek Olšák:
>> Supporting interop with any device is always possible. It depends on which
>> drivers we need to interoperate with and update them. We've already found
>> the path forward for amdgpu. We j
26 matches
Mail list logo
