h dma-fences for
interoperability...
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Tue, Oct 13, 2020, 23:52 Thomas Zimmermann wrote:
> Hi
>
> On Tue, 13 Oct 2020 13:01:58 -0700 Eric Anholt wrote:
>
> > On Tue, Oct 13, 2020 at 12:08 AM Thomas Zimmermann
> > wrote:
> > >
> > > Hi
> > >
> > > On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker"
> > > wrote:
> > >
> > > > I have
On Sun, Oct 4, 2020, 10:13 Jacob Lifshay wrote:
> On Sun, Oct 4, 2020, 08:19 Alyssa Rosenzweig <
> alyssa.rosenzw...@collabora.com> wrote:
>
>> Cc'd.
>>
>> On Sun, Oct 04, 2020 at 03:17:28PM +0300, Michael Shigorin wrote:
>> > Hell
port.
>
AArch64 with Linux is moving to tier 1 support with official support from
ARM:
https://github.com/rust-lang/rfcs/pull/2959
In my experience on armv7hf and powerpc64le with Linux and on aarch64 on
Android (running rustc in termux), I've never had issues with Rust.
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
truct(s)) => println!("B or C: the string is
{}", s),
A(_) => {}
}
struct MyStruct(String);
enum MyEnum {
A(String),
B {
intv: i32,
strv: String,
},
C(MyStruct),
}
Jacob Lifshay
___
mesa-dev mailing l
On Sun, Aug 23, 2020, 18:38 Dave Airlie wrote:
> On Mon, 24 Aug 2020 at 10:12, Jacob Lifshay
> wrote:
> > no, that is the existing LLVM backend from AMD's opengl/opencl drivers.
> amdvlk came later.
>
> Those are the same codebase, amdvlk just uses a fork of llvm, but the
&
On Sun, Aug 23, 2020, 17:08 Luke Kenneth Casson Leighton
wrote:
>
>
> On Monday, August 24, 2020, Dave Airlie wrote:
>
>>
>> amdgpu is completely scalar,
>
>
> it is?? waah! that's new information to me. does it even squash vec2/3/4,
> predication and swizzle?
>
yes, iirc.
>
> what about the
On Sun, Aug 23, 2020, 16:31 Dave Airlie wrote:
> It's hard to know then what you can expect to leverage from Mesa for
> that sort of architecture, the SPIRV->NIR translation, and then you
> probably want some sort of driver specific NIR->LLVM translation,
> amdgpu is completely scalar, llvmpipe
On Sun, Aug 23, 2020, 15:55 Dave Airlie wrote:
> What is your work submission model then, Vulkan is designed around
> having work submitted to a secondary processor from a control
> processor. Do you intend for the device to be used only as a
> coprocessor, or as a CPU for normal tasks that can
On Sun, Aug 23, 2020, 12:49 Dave Airlie wrote:
> The big thing doing what Jacob did before, and from memory where he
> went wrong despite advice to the contrary is he skipped the
> "vectorises it" stage, which is highly important for vector CPU
> execution, as opposed to scalar GPU.
>
IIRC, my
om the entry point) .
> I will study the code. Is there any document to read about that? I want to
> understand how loaders and icd interact.
>
IIRC the docs are here:
https://github.com/KhronosGroup/Vulkan-Loader/blob/master/loader/LoaderAndLayerInterf
On Tue, Mar 17, 2020 at 11:35 PM Jason Ekstrand wrote:
>
> On Wed, Mar 18, 2020 at 12:20 AM Jacob Lifshay
> wrote:
> >
> > The main issue with doing everything immediately is that a lot of the
> > function calls that games expect to take a very short time (e.g.
>
On Tue, Mar 17, 2020 at 7:08 PM Jason Ekstrand wrote:
>
> On Tue, Mar 17, 2020 at 7:16 PM Jacob Lifshay
> wrote:
> >
> > On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
> > >
> > > Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifsh
On Tue, Mar 17, 2020 at 11:14 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:59 -0700 schrieb Jacob Lifshay:
> > I think I found a userspace-accessible way to create sync_files and
> > dma_fences that would fulfill the requirements:
> > https://github.com/to
On Tue, Mar 17, 2020 at 10:21 AM Lucas Stach wrote:
>
> Am Dienstag, den 17.03.2020, 10:12 -0700 schrieb Jacob Lifshay:
> > One related issue with explicit sync using sync_file is that combined
> > CPUs/GPUs (the CPU cores *are* the GPU cores) that do all the
> > rend
is that there should be some way to create an
explicit fence/semaphore from userspace and later signal it. This
seems to conflict with the requirement for a sync_file to complete in
finite time, since the user process could be stopped or killed.
Any ideas?
Jacob Lifshay
One idea for Marge-bot (don't know if you already do this):
Rust-lang has their bot (bors) automatically group together a few merge
requests into a single merge commit, which it then tests, then, then the
tests pass, it merges. This could help reduce CI runs to once a day (or
some other rate). If
See also: http://bugs.libre-riscv.org/show_bug.cgi?id=188
It might be worthwhile to consider a Vulkan extension to support this as a
translation target for DX9 as well as other old HW?
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev
On Mon, Jan 13, 2020 at 9:39 AM Jason Ekstrand wrote:
>
> On Mon, Jan 13, 2020 at 11:27 AM Luke Kenneth Casson Leighton
> wrote:
>> jason i'd be interested to hear your thoughts on what jacob wrote, does it
>> alleviate your concerns, (we're not designing hardware specifically around
>>
s
work by having a nested set of blocks and the switch instruction picks
which block to break out of.
Hopefully, that all made sense. :)
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Any progress on adding EXT_sRGB support to Mesa?
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
redirects to the
source code on GitHub.
I renamed the project because vulkan-cpu infringes the Vulkan trademark.
The source code will still be available at the old URL (
https://github.com/programmerjake/vulkan-cpu) to avoid breaking any links,
however I probably won't keep the old repository up-to-da
optimizations, so I could have just
used the SPIR-V parser that Khronos has already written as it's fast enough.
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
, which can then be inlined. Hopefully, that will save most
of the work needed to implement vectorized math functions. Also, llvm is
already pretty good at converting vectorized sqrt intrinsics to vector sqrt
instructions, which x86 sse/avx and (i think) arm neon already have.
>
>
> Anyway, I hope this helps. Best of luck.
>
Thanks,
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
This commit improves the message by telling them that they could probably
enable DRI3. More importantly, it includes a little heuristic to check
to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
if we are, doesn't emit the warning. This way, users with both a discrete
card
Just to double check, is there anything else I need to do to have this
patch committed?
Jacob Lifshay
On Feb 19, 2017 02:08, "Kai Wasserbäch" <k...@dev.carbon-project.org> wrote:
> Jason Ekstrand wrote on 19.02.2017 06:01:
> > On Feb 18, 2017 12:37 PM, "Ka
This commit improves the message by telling them that they could probably
enable DRI3. More importantly, it includes a little heuristic to check
to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
if we are, doesn't emit the warning. This way, users with both a discrete
card
This commit improves the message by telling them that they could probably
enable DRI3. More importantly, it includes a little heuristic to check
to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
if we are, doesn't emit the warning. This way, users with both a discrete
card
This commit improves the message by telling them that they could probably
enable DRI3. More importantly, it includes a little heuristic to check
to see if we're running on AMD or NVIDIA's proprietary X11 drivers and,
if we are, doesn't emit the warning. This way, users with both a discrete
card
This commit improves the message by telling them that they could probably
enable DRI3 and giving a url to a Ask Ubuntu question showing how to do
that. More importantly, it includes a little heuristic to check to see
if we're running on AMD or NVIDIA's proprietary X11 drivers and, if we
are,
On Feb 14, 2017 12:18 AM, "Nicolai Hähnle" <nhaeh...@gmail.com> wrote:
On 13.02.2017 17:54, Jacob Lifshay wrote:
> the algorithm i was going to use would get the union of the sets of live
> variables at the barriers (union over barriers), create an array of
> st
the
memory barrier, then start another for loop over tid_in_workgroup, then
load all live variables.
Jacob Lifshay
On Feb 13, 2017 08:45, "Nicolai Hähnle" <nhaeh...@gmail.com> wrote:
> [ re-adding mesa-dev on the assumption that it got dropped by accident ]
>
> On 13.02.2017 1
forgot to add mesa-dev when I sent (again).
-- Forwarded message --
From: "Jacob Lifshay" <programmerj...@gmail.com>
Date: Feb 13, 2017 8:27 AM
Subject: Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc
To: "Nicolai Hähnle" <nhaeh...@g
forgot to add mesa-dev when I sent.
-- Forwarded message --
From: "Jacob Lifshay" <programmerj...@gmail.com>
Date: Feb 12, 2017 6:16 PM
Subject: Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc
To: "Dave Airlie" <airl...@gmail.com>
, so there are
no global variables that prevent the library from being completely
reentrant. I might have global variables for something like detecting cpu
features, but that will be protected by a mutex.
Jacob Lifshay
On Sun, Feb 12, 2017 at 3:14 PM Dave Airlie <airl...@gmail.com> wrote:
&
-vectorization pass would still output scalar code for
statically uniform values, llvm (as of 3.9.1) doesn't have a pass to
devectorize vectors where all elements are identical.
Jacob Lifshay
On Feb 11, 2017 11:11, "Roland Scheidegger" <srol...@vmware.com> wrote:
Am 11.02.2017 um 00:03 schri
fixes bug 99715
Signed-off-by: Jacob Lifshay <programmerj...@gmail.com>
---
src/vulkan/wsi/wsi_common_x11.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/src/vulkan/wsi/wsi_common_x11.c b/src/vulkan/wsi/wsi_common_x11.c
index 64ba921..e092066 100644
--- a/src/vulkan/wsi/wsi_common
I think vulkan is supposed to be reentrant already.
Jacob Lifshay
On Feb 10, 2017 3:38 PM, "Roland Mainz" <roland.ma...@nrubsig.org> wrote:
> On Sat, Feb 11, 2017 at 12:03 AM, Jacob Lifshay
> <programmerj...@gmail.com> wrote:
> > I would like to write a
it
committed, and would be able to do the rest with minimal help.
Jacob Lifshay
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
39 matches
Mail list logo
