search for: accelerators

Signed-off-by: Kieran Mansley <kmansley@solarflare.com> Cleanup vif_state on device removal diff -r f992a517aba5 drivers/xen/netfront/accel.c --- a/drivers/xen/netfront/accel.c Wed Oct 03 13:41:33 2007 +0100 +++ b/drivers/xen/netfront/accel.c Wed Oct 03 13:45:55 2007 +0100 @@ -500,6 +500,30 @@ EXPORT_SYMBOL_GPL(netfront_accelerator_r /* + * Remove the hooks from a single vif state.

FWIW I'm completely on board with everything Adrian has said in this thread :) -eric On Wed, Jan 17, 2018 at 11:00 AM Adrian Prantl via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > As mentioned by Adrian in the comment you linked, I too

> On Jan 17, 2018, at 9:20 AM, Jonas Devlieghere via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5 > accelerator tables in LLVM. > > To give you some background: my motivation is that I want to upstream support > for (Apple style) accelerator tables in llvm-dsymutil, Some background for

Hi Pavel, As mentioned by Adrian in the comment you linked, I too am looking at DWARFv5 accelerator tables in LLVM. To give you some background: my motivation is that I want to upstream support for (Apple style) accelerator tables in llvm-dsymutil, which is currently missing because the way they are generated is slightly different. As this requires making changes the current code, I wanted to

Christos, We would be very interested in learning more about this. In my group, we (Prakalp Srivastava, Maria Kotsifakou and I) have been working on LLVM extensions to make it easier to target a wide range of accelerators in a heterogeneous mobile device, such as Qualcomm's Snapdragon and other APUs. Our approach has been to (a) add better abstractions of parallelism to the LLVM instruction set that can be mapped down to a wide range of parallel hardware accelerators; and (b) to develop optimizing "back-en...

...e and use cases. I am planning to share more details and a set of patches in the next days. However, I would first like to see if there is an interest for this. The project is about providing compiler and runtime support for the automatic and transparent offloading of loop or function workloads to accelerators. It is composed of the following: a) Compiler and Transformation Passes for extracting loops or functions for offloading. b) A runtime library that handles scheduling, data sharing and coherency between the host and accelerator sides. c) A modular codebase and design. Adaptors specialize the code...

Hi Daniel, CC linux-fbdev Thanks for your patch! On Thu, 29 Oct 2020, Daniel Vetter wrote: > So ever since syzbot discovered fbcon, we have solid proof that it's > full of bugs. And often the solution is to just delete code and remove > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). > > Now the problem is that most modern-ish drivers really

Hello, i have been working with an accelerator backend. the accelerator has large vector/simd units. i want streaming loops (non-temporal) vectorized present in code to be offloaded to accelerator simd units. i find polly really suitable for this. i am thinking if the generated IR is passed to polly and then it analyzes loop to know it posses no reuse, if such loop is identified accelerator

Thank you for all the responses. Unfortunately I wasn't able to make any progress on creating the patches today. I'll be sure to add everyone who expressed interest here to the phabricator diff once I have them ready. Jonas, do you have any dsymutil patches I can look at? I am interested in seeing what kind of interfaces are you using, particularly on the reading side. I think the current

...rds, Sergos On Sat, Jun 6, 2015 at 2:24 PM, Christos Margiolas <chrmargiolas at gmail.com> wrote: > Hello, > > Thank you a lot for the feedback. I believe that the heterogeneous engine > should be strongly connected with parallelization and vectorization efforts. > Most of the accelerators are parallel architectures where having efficient > parallelization and vectorization can be critical for performance. > > I am interested in these efforts and I hope that my code can help you > managing the offloading operations. Your LLVM instruction set extensions may > require so...

In a virtualized environment running Xen or VMware, can the guest operating systems utilize hardware crypto acceleration such as the "PadLock" AES acceleration built into VIA CPUs? (Wasn't able to find this info in any of ~400 Google hits, so I'm shooting it out a bit to let as many as possible benefit from the answer.)

In a virtualized environment running Xen or VMware, can the guest operating systems utilize hardware crypto acceleration such as the "PadLock" AES acceleration built into VIA CPUs? (Wasn't able to find this info in any of ~400 Google hits, so I'm shooting it out a bit to let as many as possible benefit from the answer.)

In a virtualized environment running Xen or VMware, can the guest operating systems utilize hardware crypto acceleration such as the "PadLock" AES acceleration built into VIA CPUs? (Wasn't able to find this info in any of ~400 Google hits, so I'm shooting it out a bit to let as many as possible benefit from the answer.)

So ever since syzbot discovered fbcon, we have solid proof that it's full of bugs. And often the solution is to just delete code and remove features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). Now the problem is that most modern-ish drivers really only treat fbcon as an dumb kernel console until userspace takes over, and Oops printer for some emergencies. Looking at

On 29/10/2020 15:22, Daniel Vetter wrote: > So ever since syzbot discovered fbcon, we have solid proof that it's > full of bugs. And often the solution is to just delete code and remove > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). > > Now the problem is that most modern-ish drivers really only treat > fbcon as an dumb kernel console until

...y-ast-detect-parallel it will mark loops in the generated Ast as > "coincident", i.e. parallel and without reuse. > > If you know the vector width of your accelerator, you can use > LoopVectorizationLegality::canVectorize to determine whether you can > vectorize it. If your accelerators computational model assumes no > loop-carried dependencies, maybe LoopVectorizationLegality can be > modified to accept 'infinite' vector width. > > polly-dev at googlegroups.com would be the mailing list for help > specically for Polly. > > Michael > > > >...

On Sat, Oct 31, 2020 at 11:28 AM Geert Uytterhoeven <geert at linux-m68k.org> wrote: > > Hi Daniel, > > CC linux-fbdev > > Thanks for your patch! > > On Thu, 29 Oct 2020, Daniel Vetter wrote: > > So ever since syzbot discovered fbcon, we have solid proof that it's > > full of bugs. And often the solution is to just delete code and remove >

Hello all, In <https://reviews.llvm.org/D41986#977215> it was brought up that there are at least two parties interested in having DWARF5 accelerator tables implemented, so I'm writing this email to see if there's anyone else interested in this topic, and to try to synchronize our efforts. Our interest for this stems from a desire to make dwarf parsing fast on non-apple targets

So ever since syzbot discovered fbcon, we have solid proof that it's full of bugs. And often the solution is to just delete code and remove features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). Now the problem is that most modern-ish drivers really only treat fbcon as an dumb kernel console until userspace takes over, and Oops printer for some emergencies. Looking at

Hi Daniel et al. On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote: > So ever since syzbot discovered fbcon, we have solid proof that it's > full of bugs. And often the solution is to just delete code and remove > features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code"). > > Now the problem is that most modern-ish drivers really only treat >