similar to: [LLVMdev] Passing pointers to pointers to JIT

On Mon, Sep 9, 2024 at 7:37?AM Thomas Zimmermann <tzimmermann at suse.de> wrote: > > Call drm_client_setup() to run the kernel's default client setup > for DRM. Set fbdev_probe in struct drm_driver, so that the client > setup can start the common fbdev client. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > Cc: Zack Rusin <zack.rusin at

> 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

There seems to be some interest these days in OpenCL. However for some projects, a issue they face to adopting OpenCL is requirements of maintaining two source trees: one for normal C code (for use on systems without OpenCL support or poor OpenCL performance) and another for OpenCL. I am interested in using LLVM to create a OpenCL frontend for multicore CPUs. Now that the spec is out, we have a

On Tuesday 16 December 2008 12:21:24 Timothy Baldridge wrote: > There seems to be some interest these days in OpenCL. However for some > projects, a issue they face to adopting OpenCL is requirements of > maintaining two source trees: one for normal C code (for use on > systems without OpenCL support or poor OpenCL performance) and another > for OpenCL. > > I am interested in

> 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. > > Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de> > Cc: Roland Scheidegger <sroland at vmware.com> > --- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c |

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

Chris Lattner wrote: > The direction we're going is to expose more and more vector operations in > LLVM IR. For example, compares and select are currently being worked on, > so you can do a comparison of two vectors which returns a vector of bools, > and use that as the compare value of a select instruction (selecting between > two vectors). This would allow implementing min

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

Hi, we have two modules, one that we basically use as a library in which we store a lot of simple function calls, the other is small program generated at run-time. Whenever a function call for to one of the builtin functions is being called we use CloneFunction to clone the instruction from the library module and insert it in the generated module. The problem is for example when we have

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 first one to never lower any of the GPU instructions so we'd have > intrinsics or

Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-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]

Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-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]

Prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-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]

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

From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> Currently drm_gem_handle_create_tail exposes the handle to userspace before the buffer object constructions is complete. This allowing of working against a partially constructed object, which may also be in the process of having its creation fail, can have a range of negative outcomes. A lot of those will depend on what the individual

From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> Currently drm_gem_handle_create_tail exposes the handle to userspace before the buffer object constructions is complete. This allowing of working against a partially constructed object, which may also be in the process of having its creation fail, can have a range of negative outcomes. A lot of those will depend on what the individual

On Tuesday 27 November 2007 06:01:34 pm Chris Lattner wrote: > > The main reason for adding intrinsics instead of just using C library > > calls is for support for vector types. @llvm.sin.* can be overloaded as > > @llvm.sin.v4f32, for example, which is very useful for some users. > > My question is "how can these be used" by people. Specifically, these > need

Hi, On 14/02/2023 13:59, Christian K?nig wrote: > Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: >> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> >> >> Currently drm_gem_handle_create_tail exposes the handle to userspace >> before the buffer object constructions is complete. This allowing >> of working against a partially constructed object, which may

Hi, On 14/02/2023 13:59, Christian K?nig wrote: > Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin: >> From: Tvrtko Ursulin <tvrtko.ursulin at intel.com> >> >> Currently drm_gem_handle_create_tail exposes the handle to userspace >> before the buffer object constructions is complete. This allowing >> of working against a partially constructed object, which may

Hi, This is a batch of patches touching drm for preparing for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). As found with Coccinelle[1], add