search for: rusin

> On Dec 2, 2020, at 09:27, Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Hi > > Am 02.12.20 um 09:01 schrieb Thomas Zimmermann: >> Hi >> Am 30.11.20 um 21:59 schrieb Zack Rusin: >>> >>> >>>> On Nov 24, 2020, at 06:38, Thomas Zimmermann <tzimmermann at suse.de> wrote: >>>> >>>> Using struct drm_device.pdev is deprecated. Convert vmwgfx to struct >>>> drm_device.dev. No functional changes. >>&g...

On Thu, Dec 03, 2020 at 03:06:20AM +0000, Zack Rusin wrote: > > > > On Dec 2, 2020, at 11:03, Daniel Vetter <daniel at ffwll.ch> wrote: > > > > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin <zackr at vmware.com> wrote: > >> > >> > >> > >>> On Dec 2, 2020, at 09:27, Thomas Zi...

...;tzimmermann at suse.de> > Cc: Roland Scheidegger <sroland at vmware.com> > --- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 8 ++++---- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 27 +++++++++++++------------- > drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 2 +- Reviewed-by: Zack Rusin <zackr at vmware.com> z

On Thu, 4 May 2023 01:43:51 +0000 Zack Rusin <zackr at vmware.com> wrote: > On Wed, 2023-05-03 at 10:54 +0300, Pekka Paalanen wrote: > > On Wed, 3 May 2023 03:35:29 +0000 > > Zack Rusin <zackr at vmware.com> wrote: > > > > > On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez Canillas wrote: >...

...ely vector GPUs. The question > is more whether we'll be able to have llvm build up vector > instructions from scalar ones The reason why I started this thread was looking for some example code doing this? Have we already had any backend in LLVM doing this? It seems not easy to me. Zack Rusin wrote: > I think Alex was referring here to a AOS layout which is completely not > ready. > Actually currently the plan is to have essentially a "two pass" LLVM IR. I > wanted the first one to never lower any of the GPU instructions so we'd have > intrinsics or maybe ev...

...oblem is that probably linker (llvm-ld) generates platform specific executable instead of bitcode in this case. So if you had any clues how I could fix this, then it would be great. BTW. I'm not sure also if that would work for technical reasons, like binary compatibility. -- Regards, Rafał Rusin

Zack Rusin wrote: >> Sure, it would be very reasonable to make these target-specific >> builtins when targeting a GPU, the same way we have target-specific >> builtins for SSE. > > Actually currently the plan is to have essentially a "two pass" LLVM IR. I > wanted the fi...

...time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct vmw_surface_dirty. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Zack Rusin <zackr at vmware.com> Cc: VMware Graphics Reviewers <linux-graphics-maintainer at vmware.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at ffwll.ch> Cc: dri-devel at lists.freedesktop.org Signed-off-by: Kees Cook <keescook at chromium.org> ---...

...time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct vmw_surface_dirty. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Zack Rusin <zackr at vmware.com> Cc: VMware Graphics Reviewers <linux-graphics-maintainer at vmware.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at ffwll.ch> Cc: dri-devel at lists.freedesktop.org Signed-off-by: Kees Cook <keescook at chromium.org> ---...

...time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add __counted_by for struct vmw_surface_dirty. [1] https://github.com/kees/kernel-tools/blob/trunk/coccinelle/examples/counted_by.cocci Cc: Zack Rusin <zackr at vmware.com> Cc: VMware Graphics Reviewers <linux-graphics-maintainer at vmware.com> Cc: David Airlie <airlied at gmail.com> Cc: Daniel Vetter <daniel at ffwll.ch> Cc: dri-devel at lists.freedesktop.org Signed-off-by: Kees Cook <keescook at chromium.org> ---...

Hi Rafal, LLVM's bitcode is not target independent in the manner you're hoping for. You can't take bitcode generated for x86 and use it on ARM, for example, or bitcode generated for Linux and use it on Darwin. -Jim On Jun 18, 2011, at 4:10 PM, Rafal Rusin wrote: > Hello, > > I wonder if it's possible to cross compile regular linux packages > (autotools based) into llvm bitcode. > Such bitcode could run on multiple target platforms using lli. > So for example if we take 'tar' sources and compile them, we have > '...

On Tuesday 30 December 2008 15:30:35 Chris Lattner wrote: > On Dec 30, 2008, at 6:39 AM, Corbin Simpson wrote: > >> However, the special instrucions cannot directly be mapped to LLVM > >> IR, like > >> "min", the conversion involves in 'extract' the vector, create > >> less-than-compare, create 'select' instruction, and create

On Thu, 4 May 2023 01:50:25 +0000 Zack Rusin <zackr at vmware.com> wrote: > On Wed, 2023-05-03 at 09:48 +0200, Javier Martinez Canillas wrote: > > Zack Rusin <zackr at vmware.com> writes: > > > > > On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez Canillas wrote: > > > > AFAICT this is t...

I'm interested in understanding the extent of the assumptions which llvm makes about the types of hardware it is capable of targeting. In particular, I'm investigating a proposal by Zack Rusin to use llvm as the shader compilation engine within Mesa, targeting GPU backends. I'm aware of the Apple GLSL compiler, and also I've seen the Vector LLVA paper. However, I'm not sure that either of these quite bridges the gap to the execution environment provided by modern GPUs....

On Thu, 4 May 2023 13:27:22 +0200 Jonas ?dahl <jadahl at gmail.com> wrote: > On Thu, May 04, 2023 at 01:39:04PM +0300, Pekka Paalanen wrote: > > On Thu, 4 May 2023 01:50:25 +0000 > > Zack Rusin <zackr at vmware.com> wrote: > > > > > On Wed, 2023-05-03 at 09:48 +0200, Javier Martinez Canillas wrote: > > > > Zack Rusin <zackr at vmware.com> writes: > > > > > > > > > On Tue, 2023-05-02 at 11:32 +0200, Javier Martinez...

...r make different assumptions. In particular, the code generator we ship is good for targetting certain classes of devices, but isn't fully general (it doesn't help if you're synthesizing a netlist from llvm, for example). > In particular, I'm investigating a proposal by Zack Rusin to use llvm as > the shader compilation engine within Mesa, targeting GPU backends. Ok > It seems that LLVA and by extension Vector-LLVA assumes that looping and > branching control flow can be expressed in terms of a simple "br" branch > operation. LLVA is not a part of LL...

...c: Daniel Vetter <daniel at ffwll.ch> Cc: amd-gfx at lists.freedesktop.org Cc: lima at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc: Steven Price <steven.price at arm.com> Cc: virtualization at lists.linux-foundation.org Cc: spice-devel at lists.freedesktop.org Cc: Zack Rusin <zackr at vmware.com> --- drivers/gpu/drm/drm_gem.c | 48 +++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index aa15c52ae182..e3d897bca0f2 100644 --- a/drivers/gpu/drm/drm_gem.c +++...

...c: Daniel Vetter <daniel at ffwll.ch> Cc: amd-gfx at lists.freedesktop.org Cc: lima at lists.freedesktop.org Cc: nouveau at lists.freedesktop.org Cc: Steven Price <steven.price at arm.com> Cc: virtualization at lists.linux-foundation.org Cc: spice-devel at lists.freedesktop.org Cc: Zack Rusin <zackr at vmware.com> --- drivers/gpu/drm/drm_gem.c | 48 +++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 24 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index aa15c52ae182..e3d897bca0f2 100644 --- a/drivers/gpu/drm/drm_gem.c +++...

Hey, as some of you may know we're in process of experimenting with LLVM in Gallium3D (Mesa's new driver model), where LLVM would be used both in the software only (by just JIT executing shaders) and hardware (drivers will implement LLVM code-generators) cases. While the software only case is pretty straight forward I just realized I missed something in my initial evaluation. That

...x at lists.freedesktop.org >> Cc: lima at lists.freedesktop.org >> Cc: nouveau at lists.freedesktop.org >> Cc: Steven Price <steven.price at arm.com> >> Cc: virtualization at lists.linux-foundation.org >> Cc: spice-devel at lists.freedesktop.org >> Cc: Zack Rusin <zackr at vmware.com> >> --- >> ? drivers/gpu/drm/drm_gem.c | 48 +++++++++++++++++++-------------------- >> ? 1 file changed, 24 insertions(+), 24 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c >> index aa15c52ae182..e...