search for: suboptimally

Hi. In the current state of gvt-g the user experience is suboptimal. So my question is what are the ETAs for following features: 1. Accelerated virt-manager console using gvt-g device 2. Custom resolutions or dynamic resolution 3. UEFI VMs support (Windows guest) Thanks.

Could you elaborate a bit more about the first two features? On UEFI VMs support (Windows guest), do you mean enabling Windows VM display on UEFI? Thanks. > -----Original Message----- > From: iGVT-g [mailto:igvt-g-bounces@lists.01.org] On Behalf Of Alex Ivanov > Sent: Friday, April 19, 2019 2:51 AM > To: libvirt-users@redhat.com; igvt-g@lists.01.org; virt-tools-list@redhat.com >

Hi Martijn, thank you for your answer. So the problem would be suboptimal compression due to suboptimal assumption about the input signal, right? What I do not understand is how the format of a FLAC format would be affected by supporting A-law and mu-law files as input (and thus output). Despite of suboptimal performance, is it possible to treat 8bit *-law samples as 8bit linear PCM files and

> -----Original Message----- > From: Gerd Hoffmann [mailto:gerd@kraxel.org] > Sent: Thursday, May 9, 2019 3:28 PM > To: Alex Ivanov <gnidorah@ya.ru> > Cc: Yuan, Hang <hang.yuan@intel.com>; libvirt-users@redhat.com; igvt- > g@lists.01.org; virt-tools-list@redhat.com > Subject: Re: [iGVT-g] GVT-g - suboptimal user experience > > Hi, > > > 1. Its

Hi list, I want to find the total maximum resources I can spend given a set allocation proportion and some simple budget constraints. However, I get suboptimal results via lp and friends (i.e. lpSolve and simplex in the linprog and boot) . For example: library(lpSolve) proportions = c( 0.46, 0.28, 0.26) constraints = c( 352, 75, 171) lp(objective.in = proportions, const.mat =

Hello. All features are about usability and simple user experience. 1. Its about local display / dmabuf feature. Currently user needs to use virt-viewer tool. But virt-manager already incorporates graphical console. It would be nice if it could support accelerated gvt-g local display. Preferably with minimum performance overhead. Also virt-manager should allow to use mdev videocard alone,

Hi, > 1. Its about local display / dmabuf feature. Currently user needs to > use virt-viewer tool. But virt-manager already incorporates graphical > console. It would be nice if it could support accelerated gvt-g local > display. virt-manager and virt-viewer essentially run the same code spice client code: both are using the spice-gtk widget. So, if that isn't working

So it looks like this solution is currently not very user friendly. Perhaps Intel could get Red Hat help to make first-class support of gvt feature in virt-manager? 09.05.2019, 10:28, "Gerd Hoffmann" <gerd@kraxel.org>: >   Hi, > >>  1. Its about local display / dmabuf feature. Currently user needs to >>  use virt-viewer tool. But virt-manager already incorporates

Hi Tim and Alex Thanks for your replies. So just to make it clear for me: does this imply that there’s indeed no way on the current version to tell the compiler or Clang to optimize this? Thanks, Joan > On 8 Aug 2019, at 18:30, Tim Northover via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, 8 Aug 2019 at 17:08, Alex Brachet-Mialot via llvm-dev > <llvm-dev at

In the following example, LLVM's logic for merging isomorphic types causes two functions in different compilation units with identical function signatures to have different signatures in the resulting bitcode: =========================== $ cat demo-struct1.c struct foo { int x; }; struct bar { int x; }; struct foo *return_arg_1(struct foo *a, struct bar *b) { return a; } $ cat demo-struct2.c

Hi, right now, LLVM does register spilling by: 1. Creating stack object 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot 3. At later stage, frame indices are replaced by calling to MRegisterInfo::eliminateFrameIndex. This works for me, but there's slight problem. The target does not have "register + contant" addressing mode, so accessing frame index

Hi, For the program below, where "incr" and "Arr" are globals ================================= int incr; float Arr[1000]; int foo () {   float x = 0;   int newInc = incr+1;   for (int i = 0; i < 1000; i++) {     for (int j = 0; j < 1000; j += incr) {         x += (Arr[i] + Arr[j]);     }   }   return x; } ================================= The SCEV expression computed

I don't know much about this, but maybe -mllvm -unroll-count=1 can be used as a workaround? /Patrik Hägglund -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Brent Walker Sent: den 28 mars 2012 03:18 To: llvmdev Subject: [LLVMdev] Suboptimal code due to excessive spilling Hi, I have run into the following strange behavior

This might not be the workaround you want because it is only available in C, but you can use restrict to allow such optimizations. https://godbolt.org/z/2gQ26f Alex On Thu, Aug 8, 2019 at 11:50 AM Michael Kruse via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > char* scscx is an universal pointer and may point to anything, > including itself. That is, scscx might

On Tue, 2006-05-23 at 13:04 -0500, Chris Lattner wrote: > > That approach sounds suboptimal. By "reserving" one register we can already > > cause some values to be spilled, that otherwise would be stored in > > register. > > Right. > > PowerPC has the same problem in certain cases. For example, vector loads > only support reg+reg addressing, which

https://bugs.freedesktop.org/show_bug.cgi?id=95334 Bug ID: 95334 Summary: GM107 with 2560x1440 display on HDMI selects suboptimal resolution 1920x1080 Product: xorg Version: 7.7 (2012.06) Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium

I found a something that I quite not understand when compiling a common piece of code using the -Os flags. I found it while testing my own backend but then I got deeper and found that at least the x86 is affected as well. This is the referred code: char pp[3]; char *scscx = pp; int tst( char i, char j, char k ) { scscx[0] = i; scscx[1] = j; scscx[2] = k; return 0; } The above gets

On Thu, Jul 9, 2009 at 8:44 AM, Nicolas Capens<nicolas at capens.net> wrote: > I believe I’ve found a bug in the encoding of the movd instruction on x64. > Here’s some IR code to reproduce it: [snip > Note the last movq. What was probably intended to be generated was “movd > ecx, mm0”. LLVM mistakenly sets the ‘wide’ bit of the REX prefix to 1, > turning movd into movq. Also,

Hi, I have an ubuntu system with some of our own services on it. I prefer to run these services as a non-root user. I can control the services using upstart as a non root user and can start and stop the service using initctl without any problems. I''m trying to use puppet to start and stop these services; however, it''s not obvious if it is possible. A suboptimal approach

On Tue, 23 May 2006, Vladimir Prus wrote: > right now, LLVM does register spilling by: > > 1. Creating stack object > 2. Passing index of that stack object to MRegisterInfo::storeRegToStackSlot > 3. At later stage, frame indices are replaced by calling to > MRegisterInfo::eliminateFrameIndex. > > This works for me, but there's slight problem. The target does not have