On September 24, 2022 04:04:48 "Filip Gawin" wrote:
2. repo is growing large. Amber kinda requires long history, modern
mesa not. This may be good spot to split if cleanup is required.
mesa absolutely uses long history. there is nothing to clean up. those
bytes of disk space are well
, 2022 at 12:59 PM Jason Ekstrand wrote:
On Mon, Jun 6, 2022 at 11:38 AM Jesse Natalie wrote:
(Hopefully this goes through and not to spam like last time I tried to
respond…)
No, neither of these would currently work with UWP.
The primary reason is that neither Khronos API has extensions
On Mon, Jun 6, 2022 at 11:38 AM Jesse Natalie
wrote:
> (Hopefully this goes through and not to spam like last time I tried to
> respond…)
>
>
>
> No, neither of these would currently work with UWP.
>
>
>
> The primary reason is that neither Khronos API has extensions to
> initialize the winsys
a/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/
v10 (Jason Ekstrand, Daniel Vetter):
- Add reviews/acks
- Add a patch to rename _rcu to _unlocked
- Split things better so import is clearly RFC status
v11 (Daniel Vetter):
- Add more CCs to try and get maintainers
a/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/
v10 (Jason Ekstrand, Daniel Vetter):
- Add reviews/acks
- Add a patch to rename _rcu to _unlocked
- Split things better so import is clearly RFC status
v11 (Daniel Vetter):
- Add more CCs to try and get maintainers
sonally I consider that only "sin" and
> "cos" are needed additions for RISC-V. Unclear what precision yet, likely 8
> bits, for serving as initial value for a Newton-Rapson style computation.
>
> Regards.
>
> On Thu, Jan 20, 2022 at 2:36 AM Jason Ekstrand
> w
> - Does it make sense to move to SPIR-V?
None whatsoever. SPIR-V is an interchange format, not a set of
manipulatable data structures suitable for compiler lowering and
optimization.
You also don't want to build hardware around consuming SPIR-V. There are
lots of things that the SPIR-V has
@@ -297,7 +297,8 @@ Jan Vesely Jan Vesely
Jan Zielinski jzielins
-Jason Ekstrand
+Jason Ekstrand
+Jason Ekstrand
Jeremy Huddleston
Jeremy Huddleston
--
2.34.1
On Thu, Dec 9, 2021 at 11:24 AM Timur Kristóf
wrote:
> On Tue, 2021-12-07 at 08:19 -0500, Alyssa Rosenzweig wrote
> >
> > If it were just linked lists, I'd say someone should write the
> > Coccinelle to transform the tree to use the one in util and call it a
> > day. It's a bit more complicated
+1
On Mon, Dec 6, 2021 at 5:51 PM Dylan Baker wrote:
> Since classic is gone, I thought I'd lay out my thinking for Amber.
>
> I'm assuming that we'll branch Amber from the 21.3 branch, after that
> reaches normal EOL. That gives us the benefit of developing on top of a
> known good state for
On Mon, Dec 6, 2021 at 5:50 PM Dylan Baker wrote:
> Classic is gone, and the cleanups have begun, obviously. There is
> another cleanup that I had in mind, which is moving src/mesa into
> src/gallium/frontends/mesa. This makes the build system a little
> cleaner, as currently we do some bending
Also, welcome to the Mesa community and thanks for your contribution! Sorry
your first experience has been a bit bumpy. I hope this doesn't put you
off too badly. We always like when new people show up and dive in.
--Jason
On November 13, 2021 22:49:44 Autumn wrote:
All right! Coming in
On Thu, Nov 4, 2021 at 8:53 PM Dave Airlie wrote:
>
> Just polling for opinions here on how best to move forward with
> enabling the provisional vulkan beta headers in Mesa and the fallout
> from doing so for people importing updated vulkan headers.
>
> Do we want to allow beta/provisional
Fine with me.
On October 31, 2021 10:11:44 Michael Blumenkrantz
wrote:
Hi,
I'd like to propose adding/changing two tags:
* change `feature_request` -> `Feature` (this is barely used at present, so
renaming shouldn't affect anyone negatively)
* add `Bug`
I would use these primarily
On Tue, Oct 12, 2021 at 3:56 PM apinheiro wrote:
>
>
> On 12/10/21 13:55, Alyssa Rosenzweig wrote:
>
> I would love to see this be the process across Mesa. We already don't
> rewrite commit messages for freedreno and i915g, and I only have to do
> the rebase (busy-)work for my projects in other
On Wed, Oct 6, 2021 at 12:37 PM Mike Blumenkrantz
wrote:
>
> On Wed, Oct 6, 2021 at 1:27 PM Bas Nieuwenhuizen
> wrote:
>>
>> On Wed, Oct 6, 2021 at 7:07 PM Jason Ekstrand wrote:
>> >
>> > On Wed, Oct 6, 2021 at 11:24 AM Emma Anholt wrote:
>> &
On Wed, Oct 6, 2021 at 11:24 AM Emma Anholt wrote:
>
> On Wed, Oct 6, 2021 at 9:20 AM Mike Blumenkrantz
> wrote:
> >
> > Hi,
> >
> > It's recently come to my attention that gitlab has Approvals. Was anyone
> > else aware of this feature? You can just click a button and have your name
> >
na today from too much cross-process implicit sharing. I do think
you want some sort of "ignore implicit sync" API but, in this new
world of flags, it would look more like "don't bother looking for
shared fences flagged write". You'd still respect the exclusive
fence, if there is on
e to ignore fences. Those changes
are years in the past. If we have a real problem here (not sure on
that yet), then we'll have to figure out how to fix it without nuking
uAPI.
--Jason
> Regards,
> Christian.
>
> Am 10.06.21 um 23:09 schrieb Jason Ekstrand:
> > Modern userspace
On Tue, Jun 15, 2021 at 8:46 PM Timothy Arceri wrote:
>
> On 6/16/21 11:03 AM, Jason Ekstrand wrote:
>
> I'm bringing this up via e-mail so it gets a wider audience. Given how will
> crocus is working at this point, is like to propose we hold off for about
> three more relea
I'm bringing this up via e-mail so it gets a wider audience. Given how will
crocus is working at this point, is like to propose we hold off for about
three more releases before we drop classic. This next release, 21.2, we'll
have crocus as an option with i965 as the default. There will also be
Friday (June 18th) unless we get a good reason to
do otherwise. If you've got a good reason (it'd better be good enough
to justify 12k LOC), please raise it by replying to this e-mail or
starting a thread on !9728.
Thanks,
--Jason Ekstrand
[1]: https://gitlab.freedesktop.org/mesa/mesa
a/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/
v10 (Jason Ekstrand, Daniel Vetter):
- Add reviews/acks
- Add a patch to rename _rcu to _unlocked
- Split things better so import is clearly RFC status
v11 (Daniel Vetter):
- Add more CCs to try and get maint
On Thu, Jun 10, 2021 at 3:11 PM Chia-I Wu wrote:
>
> On Tue, May 25, 2021 at 2:18 PM Jason Ekstrand wrote:
> > Modern userspace APIs like Vulkan are built on an explicit
> > synchronization model. This doesn't always play nicely with the
> > implicit synchroniz
I should have said that the minimal support can be for LINEAR, X-tiled
and Y-tiled. CCS can and probably should come later.
On Wed, Jun 9, 2021 at 6:14 PM Yiwei Zhang wrote:
>
> On Wed, Jun 9, 2021 at 2:19 PM Jason Ekstrand wrote:
> >
> > +Nanley
> >
> > We've
+Nanley
We've not defined those yet. We had some internal talks a couple
years ago. The rough idea we had at the time was to define a modifier
for those cases which put the CCS after each main surface at some
fixed calculation offset based on width, height, and stride. Then the
one modifier
a/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/
v10 (Jason Ekstrand, Daniel Vetter):
- Add reviews/acks
- Add a patch to rename _rcu to _unlocked
- Split things better so import is clearly RFC status
v11 (Daniel Vetter):
- Add more CCs to try and get maint
a/mesa/-/merge_requests/4037
IGT tests: https://patchwork.freedesktop.org/series/90490/
v10 (Jason Ekstrand, Daniel Vetter):
- Add reviews/acks
- Add a patch to rename _rcu to _unlocked
- Split things better so import is clearly RFC status
Cc: Christian König
Cc: Michel Dänzer
Cc: Dave Airlie
C
t; > Am 19.05.21 um 01:58 schrieb Matthew Brost:
> > > > > Add entry fpr i915 new parallel submission uAPI plan.
> > > > >
> > > > > v2:
> > > > >(Daniel Vetter):
> > > > > - Expand logical order expl
On Tue, May 4, 2021 at 12:16 PM Marek Olšák wrote:
>
> I see some mentions of XNACK and recoverable page faults. Note that all
> gaming AMD hw that has userspace queues doesn't have XNACK, so there is no
> overhead in compute units. My understanding is that recoverable page faults
> are still
On Mon, May 3, 2021 at 10:16 AM Bas Nieuwenhuizen
wrote:
>
> On Mon, May 3, 2021 at 5:00 PM Jason Ekstrand wrote:
> >
> > Sorry for the top-post but there's no good thing to reply to here...
> >
> > One of the things pointed out to me recently by Daniel Vetter that
On Mon, May 3, 2021 at 10:03 AM Christian König
wrote:
>
> Am 03.05.21 um 16:59 schrieb Jason Ekstrand:
> > Sorry for the top-post but there's no good thing to reply to here...
> >
> > One of the things pointed out to me recently by Daniel Vetter that I
> >
Sorry for the top-post but there's no good thing to reply to here...
One of the things pointed out to me recently by Daniel Vetter that I
didn't fully understand before is that dma_buf has a very subtle
second requirement beyond finite time completion: Nothing required
for signaling a dma-fence
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, incl
Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Thomas Hellström
> Cc: Daniele Ceraolo Spurio
> Cc: Lionel Landwerlin
> Cc: Jon Bloomfield
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: dri-de...@lists.free
done with the buffer and we wouldn't (I
hope!) end up with the accidental edges in the dependency graph.
Of course, I've not yet proven any of this correct so feel free to
tell me why it won't work. :-) It was just one of those "about to go
to bed and had a thunk" type thoughts.
--
On Tue, Apr 27, 2021 at 1:38 PM Dave Airlie wrote:
>
> On Tue, 27 Apr 2021 at 22:06, Christian König
> wrote:
> >
> > Correct, we wouldn't have synchronization between device with and without
> > user queues any more.
> >
> > That could only be a problem for A+I Laptops.
>
> Since I think you
Trying to figure out which e-mail in this mess is the right one to reply to
On Tue, Apr 27, 2021 at 12:31 PM Lucas Stach wrote:
>
> Hi,
>
> Am Dienstag, dem 27.04.2021 um 09:26 -0400 schrieb Marek Olšák:
> > Ok. So that would only make the following use cases broken for now:
> > - amd render
Maybe, maybe not I mean, normally I'd be all for it but
https://rosenzweig.io/blog/asahi-gpu-part-3.html
--Jason
On Tue, Apr 27, 2021 at 12:32 PM Ian Romanick wrote:
>
> If we're going to cut all the classic drivers and a handful of older
> Gallium drivers... can we also cut Apple
On Mon, Apr 26, 2021 at 10:31 AM Matthew Auld wrote:
>
> On 26/04/2021 16:11, 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, incl
On Wed, Apr 21, 2021 at 2:23 PM Daniel Vetter wrote:
>
> On Wed, Apr 21, 2021 at 8:28 PM Tvrtko Ursulin
> wrote:
> > On 21/04/2021 18:17, Jason Ekstrand wrote:
> > > On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
> > > wrote:
> > >> On 21/04/2021 14:
Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Thomas Hellström
> Cc: Daniele Ceraolo Spurio
> Cc: Lionel Landwerlin
> Cc: Jon Bloomfield
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
> Cc: dri-de...@lists.free
On Wed, Apr 21, 2021 at 9:25 AM Tvrtko Ursulin
wrote:
>
>
> On 21/04/2021 14:54, Jason Ekstrand wrote:
> > On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
> > wrote:
> >>
> >> On 20/04/2021 18:00, Jason Ekstrand wrote:
> >>> On Tue, A
On Wed, Apr 21, 2021 at 3:22 AM Tvrtko Ursulin
wrote:
>
> On 20/04/2021 18:00, Jason Ekstrand wrote:
> > On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 19/04/2021 16:19, Jason Ekstrand wrote:
> >>> O
On Tue, Apr 20, 2021 at 1:54 PM Daniel Vetter wrote:
>
> On Tue, Apr 20, 2021 at 7:45 PM Daniel Stone wrote:
>
> > And something more concrete:
> >
> > dma_fence.
> >
> > This already has all of the properties described above. Kernel-wise, it
> > already devolves to CPU-side signaling when it
On Tue, Apr 20, 2021 at 11:34 AM Tvrtko Ursulin
wrote:
>
>
> On 19/04/2021 16:19, Jason Ekstrand wrote:
> > On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
> >>
> >> On 16/04/2021 17:38, Jason Ekstrand wrote:
> >>> On Thu, Apr 15
s for modesetting and other
> > >> producer<->consumer
> > >> scenarios?
> > > Let me work on the full replay for your rfc first, because there's a lot
> > > of details here and nuance.
> > > -Daniel
> > >
> > >> Thanks
ting and other producer<->consumer
> >> scenarios?
> > Let me work on the full replay for your rfc first, because there's a lot
> > of details here and nuance.
> > -Daniel
> >
> >> Thanks,
> >> Marek
> >>
> >> On Tue, Apr 20, 2021 at
It's still early in the morning here and I'm not awake yet so sorry if
this comes out in bits and pieces...
On Tue, Apr 20, 2021 at 7:43 AM Daniel Stone wrote:
>
> Hi Marek,
>
> On Mon, 19 Apr 2021 at 11:48, Marek Olšák wrote:
>>
>> 2. Explicit synchronization for window systems and modesetting
Not going to comment on everything on the first pass...
On Mon, Apr 19, 2021 at 5:48 AM Marek Olšák wrote:
>
> Hi,
>
> This is our initial proposal for explicit fences everywhere and new memory
> management that doesn't use BO fences. It's a redesign of how Linux graphics
> drivers work, and
On Mon, Apr 19, 2021 at 7:02 AM Matthew Auld wrote:
>
> On 16/04/2021 17:38, Jason Ekstrand wrote:
> > On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld
> > wrote:
> >>
> >> Add an entry for the new uAPI needed for DG1.
> >>
> >> v2(D
Reviewed-by: Jason Ekstrand
On April 16, 2021 05:37:55 Matthew Auld wrote:
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc: mesa-dev@lists.freedesktop.org
Reviewed-by: Daniel Vetter
---
include/uapi/drm/i915_drm.h | 54 ++---
1 file
with the placements extension
> - rather than have a generic setparam which can cover multiple
> use cases, have each extension be responsible for one thing
> only
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc
+mesa-dev and some Intel mesa people.
On Wed, Apr 14, 2021 at 5:23 AM Daniel Vetter wrote:
>
> On Tue, Apr 13, 2021 at 12:47:06PM +0100, Matthew Auld wrote:
> > Add an entry for the new uAPI needed for DG1.
> >
> > v2(Daniel):
> > - include the overall upstreaming plan
> > - add a note for
> >> are focusing effort on other OSS projects, and want to maintain OpenSWR at
> >> its current feature level, but we are often seeing Mesa core changes
> >> causing problems in OpenSWR, that we can’t always address right away. So,
> >> we would like to
On Thu, Mar 25, 2021 at 4:32 PM Kenneth Graunke wrote:
>
> On Thursday, March 25, 2021 2:04:45 PM PDT Ian Romanick wrote:
> > On 3/25/21 10:49 AM, Jason Ekstrand wrote:
> > Can you be more specific? Also, is there a reason why that work can't
> > or shouldn't be done di
Can you be more specific? Also, is there a reason why that work can't
or shouldn't be done directly in the LTS branch? As Ken pointed out,
I'm not sure we want to totally declare those drivers dead. People can
still do feature or enhancement development of they want to, it just
happens in a
On Thu, Mar 25, 2021 at 9:41 AM Rob Clark wrote:
>
> On Wed, Mar 24, 2021 at 9:15 PM Jason Ekstrand wrote:
> >
> > On March 24, 2021 22:25:10 Rob Clark wrote:
> >
> >> On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen
> >> wrote:
> >>>
On March 24, 2021 22:25:10 Rob Clark wrote:
On Wed, Mar 24, 2021 at 3:52 PM Jordan Justen
wrote:
On 2021-03-23 09:38:59, Eric Anholt wrote:
On Tue, Mar 23, 2021 at 7:02 AM Jason Ekstrand wrote:
Trying to pick this discussion back up. Daniel Stone thinks it's a
half hour of API bashing
On Wed, Mar 24, 2021 at 10:28 AM Rob Clark wrote:
>
> On Mon, Mar 22, 2021 at 3:15 PM Dylan Baker wrote:
> >
> > Hi list,
> >
> > We've talked about it a number of times, but I think it's time time to
> > discuss splitting the classic drivers off of the main development branch
> > again,
On Tue, Mar 23, 2021 at 2:06 PM Simon Ser wrote:
>
> From a user-space point-of-view, this looks super useful! The uAPI sounds
> good to me.
>
> Acked-by: Simon Ser
>
> Would be nice to have some short docs as well. Here's an example of a
> patch adding some docs for an ioctl [1], if you aren't
Adding mesa-dev and wayland-devel for broader circulation.
On Wed, Mar 17, 2021 at 5:19 PM Jason Ekstrand wrote:
>
> Modern userspace APIs like Vulkan are built on an explicit
> synchronization model. This doesn't always play nicely with the
> implicit synchronization used i
On Tue, Mar 23, 2021 at 8:39 AM Kenneth Graunke wrote:
>
> On Tuesday, March 23, 2021 6:28:23 AM PDT Jason Ekstrand wrote:
> > On March 23, 2021 01:46:54 Kenneth Graunke wrote:
> [snip]
> > > One extra thought: can we also fork off anv Gen7.x support at the same
Trying to pick this discussion back up. Daniel Stone thinks it's a
half hour of API bashing to retarget all the MRs so, if the fd.o
admins have some heads up, it should be tractable. Should we do this
right after branching 21.1 along with the LTS branch?
--Jason
On Fri, Aug 7, 2020 at 3:38 AM
On March 23, 2021 01:46:54 Kenneth Graunke wrote:
On Monday, March 22, 2021 3:15:30 PM PDT Dylan Baker wrote:
Hi list,
We've talked about it a number of times, but I think it's time time to
discuss splitting the classic drivers off of the main development branch
again, although this time I
+1. I'd we think GLVND and X are ready for this, I think it's a good plan.
On March 22, 2021 17:34:09 Eric Anholt wrote:
On Mon, Mar 22, 2021 at 3:27 PM Dylan Baker wrote:
Hi list,
We've talked about it a number of times, but I think it's time time to
discuss splitting the classic drivers
On March 16, 2021 05:06:53 Daniel Stone wrote:
On Mon, 15 Mar 2021 at 20:54, Jason Ekstrand wrote:
Three comments:
1. +1
2. Khronos has generally standardized on American English in their
specs so I guess that provides some sort of prior art or something.
3. I'd generally be a fan
Three comments:
1. +1
2. Khronos has generally standardized on American English in their
specs so I guess that provides some sort of prior art or something.
3. I'd generally be a fan of encouraging American spellings in common
code as well. As someone who doesn't use auto-complete, having to
On March 13, 2021 04:18:26 Quentin SCHIBLER wrote:
GLVND depends on several X librairies. Does it means you cannot have OpenGL
on wayland without X ?
Yes and no. libGL.so on Linux depends on X11 for historical reasons. The
short version is that, long ago, libGL.so exposed all its symbols
Hi Tommy,
As you've probably noticed already, Mesa documentation is sparse at
best. For NIR, the best places to go are:
1. For ALU ops, nir_opcodes.py defines the opcodes as well as a C
snippet which describes the opcode's semantics
2. For all intrinsics, nir_intrinsics.py defines them and
Drive-by comment: I'm afraid getting window-system stuff working
isn't "the last push". It's probably 50-80% of the project. I have
no idea how any of this works for LLVMpipe; maybe we can steal some
code from there? In any case, you're unlikely to find a lot of win32
experts here.
--Jason
To help smooth things along, I've created a new label "Project Access
Requests" for use with these things. I've subscribed to it myself and
would encourage the other maintainers to do so as well. That way we
see these issues instead of them getting lost in the pile.
--Jason
On Thu, Jan 21,
All,
At suggestion from several people on IRC, I've done a bit of house
cleaning of the main Mesa repo. I created a new mesa/mesa-archive
repo and moved all of the stale feature branches to that repo and
removed them from mesa/mesa. Many of those branches haven't seen a
commit in 10-20 years so
On Tue, Nov 17, 2020 at 6:10 PM Jordan Justen wrote:
>
> On 2020-11-17 16:03:31, Brian Paul wrote:
> > Another Intel question: It looks like gen11/gen12 don't have fp/int64
> > enabled in the Vulkan driver. From gen_device_info.c:
> >
> > #define GEN11_FEATURES(_gt, _slices, _subslices, _l3) \
>
Good work!
On Fri, Oct 30, 2020 at 3:24 PM Dave Airlie wrote:
>
> Just to let everyone know, a month ago I submitted the 20.2 llvmpipe
> driver for OpenGL 4.5 conformance under the SPI/X.org umbrella, and it
> is now official[1].
>
> Thanks to everyone who helped me drive this forward, and to
to play with the shiney new features. I'd like
to support them somehow but it likely won't be directly in the driver.
Making a layer sounds like a fantastic GSOC project.
--Jason
On Wed, Oct 28, 2020 at 5:26 PM Jason Ekstrand wrote:
>
> All,
>
> Some of you may be curious about what
All,
Some of you may be curious about what I've been up to for most of
2020, why I've not been working on IBC, and why I suddenly decided to
start caring about ray-tracing. Well... it's all because I've been
working on this little project to implement VK_KHR_ray_tracing in ANV.
I finally have
Generally, you need to be careful with forcing no_error. Some apps
rely on gl errors to check for features and other things.
Force-disabling errors may break the app. Mesa's implementation of
the no_error extension has been a gradual process where people have
been removing the error checking
First off, I should point out that the AMD NIR -> LLVM translator is,
as far as I know, the only NIR back-end that consumes variables at
all. Most back-ends assume that all variable access is completely
lowered away before the back-end ever sees it. How this is done
depends on the variable mode.
On Fri, Oct 2, 2020 at 5:51 PM wrote:
>
> On Fri, 2020-10-02 at 12:53 -0500, Jason Ekstrand wrote:
> > On Fri, Oct 2, 2020 at 11:34 AM Eric Anholt wrote:
> > > On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> > > wrote:
> > > > Hi all,
> &g
On Fri, Oct 2, 2020 at 11:34 AM Eric Anholt wrote:
>
> On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> wrote:
> >
> > Hi all,
> >
> > Recently I've been thinking about the potential for the Rust programming
> > language in Mesa. Rust bills itself a safe system programming language
> > with
On Thu, Oct 1, 2020 at 10:56 PM Rob Clark wrote:
>
> On Thu, Oct 1, 2020 at 6:36 PM Alyssa Rosenzweig
> wrote:
> >
> > Implications for the build system vary. Rust prefers to be built by its
> > own package manager, Cargo, which is tricky to integrate with other
> > build systems. Actually,
First off, I think you all did a fantastic job. I felt that things
ran very smoothly and, as far as the talks themselves go, I think it
went almost as smoothly as an in-person XDC. I'm really quite
impressed. I do have a couple pieces of more nuanced feedback:
1. I think we were maybe a bit
FYI: I just opened this issue:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/3534
On Thu, Sep 17, 2020 at 12:13 PM Jason Ekstrand wrote:
>
> One more comment: Could you make a big WIP MR with the whole driver
> to act as a pointer to the branch for now? Then it can be the thing
&g
One more comment: Could you make a big WIP MR with the whole driver
to act as a pointer to the branch for now? Then it can be the thing
that gets merged once the stuff in a and b land.
--Jason
On Thu, Sep 17, 2020 at 12:10 PM Jason Ekstrand wrote:
>
> Good work, all! I'm super-happy
Good work, all! I'm super-happy to see another Vulkan driver land in Mesa.
On Thu, Sep 17, 2020 at 8:52 AM apinheiro wrote:
> Our development branch is ~525 patches on top of master, categorized as
> follows:
>a) Patches that touch common Mesa infrastructure (NIR, Vulkan WSI, Meson,
>
The error says pretty clearly what went wrong. The loader looked for
the `vk_icdGetInstanceProcAddr` symbol and couldn't find it in your
so. You need at least the basic Get*ProcAddr symbols or else the
loader can't do anything. You'll also need device and instance
creation functions and
3D graphics virtualization is not as simple as just running the driver
required by the host GPU inside the guest OS. For desktop
virtualization, it's typically done by the guest providing a different
3D graphics driver which somehow passes through the graphics commands
to the 3D driver on the
On Tue, Aug 4, 2020 at 5:54 AM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 3 Aug 2020 at 17:16, Jason Ekstrand wrote:
> > On Mon, Aug 3, 2020 at 11:12 AM Kenneth Graunke
> > wrote:
> > > Seems reasonable to me...in the old Subversion days, we called it
>
On Mon, Aug 3, 2020 at 1:38 PM Eric Engestrom wrote:
>
> On Monday, 2020-08-03 13:31:19 -0500, Jason Ekstrand wrote:
> > On Mon, Aug 3, 2020 at 1:24 PM Eric Engestrom wrote:
> > >
> > > On Monday, 2020-08-03 10:30:29 -0500, Jason Ekstrand wrote:
> > >
On Mon, Aug 3, 2020 at 1:24 PM Eric Engestrom wrote:
>
> On Monday, 2020-08-03 10:30:29 -0500, Jason Ekstrand wrote:
> > All,
> >
> > I'm sure by now you've all seen the articles, LKML mails, and other
> > chatter around inclusive language in software. While mesa d
On Mon, Aug 3, 2020 at 12:51 PM Erik Faye-Lund
wrote:
>
> On Mon, 2020-08-03 at 12:48 -0500, Jason Ekstrand wrote:
> > On Mon, Aug 3, 2020 at 12:42 PM Erik Faye-Lund
> > wrote:
> > > On Mon, 2020-08-03 at 10:30 -0500, Jason Ekstrand wrote:
> > > > All,
>
On Mon, Aug 3, 2020 at 12:42 PM Erik Faye-Lund
wrote:
>
> On Mon, 2020-08-03 at 10:30 -0500, Jason Ekstrand wrote:
> > All,
> >
> > I'm sure by now you've all seen the articles, LKML mails, and other
> > chatter around inclusive language in software. While mesa d
On Mon, Aug 3, 2020 at 11:12 AM Kenneth Graunke wrote:
>
> Seems reasonable to me...in the old Subversion days, we called it
> 'trunk'...then 'master' with Git...but calling the main development
> branch 'main' is arguably the simplest and most descriptive term.
>
> One thing we'll have to
, of course, so doing a simple
search-and-replace likely isn't going to work. However, I think such
documents are helpful for guiding the discussion.
--Jason
On Mon, Aug 3, 2020 at 10:30 AM Jason Ekstrand wrote:
>
> All,
>
> I'm sure by now you've all seen the articles, LKML mails, and oth
All,
I'm sure by now you've all seen the articles, LKML mails, and other
chatter around inclusive language in software. While mesa doesn't
provide a whole lot of documentation (hah!), we do have a website, a
code-base, and a git repo and this is something that we, as a project
should consider.
acks without is indeed dubious.
>
> Jose
>
> ____
> From: Jason Ekstrand
> Sent: Monday, May 11, 2020 17:29
> To: Jose Fonseca
> Cc: ML mesa-dev ;
> erik.faye-l...@collabora.com
> Subject: Re: [Mesa-dev] RFC: Memory allocation on Mesa
>
>
Sorry for the top-post.
Very quick comment: If part of your objective is to fulfill Vulkan's
requirements, we need a LOT more plumbing than just
MALLOC/CALLOC/FREE. The Vulkan callbacks aren't set at a global level
when the driver is loaded but are provided to every call that
allocates anything
On Thu, May 7, 2020 at 9:07 AM Erik Faye-Lund
wrote:
>
> On Thu, 2020-05-07 at 09:05 -0500, Jason Ekstrand wrote:
> > Looks shiny but
> >
> > We need to be very careful here. One of the big no-nos with Khronos
> > trademark rules is using logos for things wh
1 - 100 of 12044 matches
Mail list logo
