search for: metdata

Hi I'm working on a project which needs loop-attached metadata similar to the parallel metadata discussed in here. Currently I'm trying to make the metadata get through the optimisation passes unscathed. For loop passes, I've solved that by modifying the LPPassManager to check for metadata presence before and after runOnLoop, and restoring it if necessary (assuming the loop didn't

Hi I'm working on a project which needs loop-attached metadata similar to the parallel metadata discussed in here. Currently I'm trying to make the metadata get through the optimisation passes unscathed. For loop passes, I've solved that by modifying the LPPassManager to check for metadata presence before and after runOnLoop, and restoring it if necessary (assuming the loop didn't

On 2/25/2013 4:50 PM, Redmond, Paul wrote: > > On the branch into the loop: Well... In this case the metadata is not on the latch. I guess this is because the initial loop structure is this questionable jump-to-cond-then-back scheme. I agree---this doesn't look right. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Hi Paul, On 02/26/2013 06:13 AM, Redmond, Paul wrote: > The point is if the two representations are equivalent (which is what I'd > like to determine) and one is more convenient/less intrusive on existing > passes than that should be determined sooner rather than later :P Isn't it possible that multiple nested loops share the header and the pre-header in normalized loops? Thus,

Seeing that mike is away for a about week, I thought I'd post this on the Mailing list. The attached diff is to fix the ability to provide metadata updates from a file whilst using the DSP (live input). Currently it doesn't work reliably. just cd ices (from CVS) patch -p1 < metadata.diff and rebuild. karl. <p> -------------- next part -------------- A non-text attachment

On 2/25/2013 2:08 PM, Redmond, Paul wrote: > > I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Latch is a branch to the header. What branch in particular do you have in mind? Loop

Hi, On 2013-02-25, at 5:11 PM, Krzysztof Parzyszek wrote: > On 2/25/2013 2:08 PM, Redmond, Paul wrote: >> >> I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) > >

Hi, I've been looking through past threads looking for an answer to why the loop metadata is attached to the loop latch branch. What is the reason for putting the metadata inside the loop rather than outside (for example on the branch into the loop header.) Note that I'm asking about llvm.loop.parallel not llvm.mem.parallel_loop_access which obviously must be inside the loop. It seems

On 2/25/2013 7:41 PM, Redmond, Paul wrote: > > I'm suggesting this as a possible alternative to the loop latch approach. > Please re-read my original email. Your reply seemed like you're quoting code that is currently generated, not your proposal. I'm not sure why you would want the loop metadata to be attached to some other branch. Loop latch will always exist, while, at

Hi, On 2013-02-25 10:20 PM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org> wrote: >On 2/25/2013 7:41 PM, Redmond, Paul wrote: >> >> I'm suggesting this as a possible alternative to the loop latch >>approach. >> Please re-read my original email. > >Your reply seemed like you're quoting code that is currently generated, >not your

Hi Pekka, On Tue, Feb 26, 2013 at 11:08 AM, Pekka Jääskeläinen < pekka.jaaskelainen at tut.fi> wrote: > > > Isn't it possible that multiple nested loops share the header and > the pre-header in normalized loops? Thus, then adding metadata to the > preheader's branch would make the MD ambiguous for nested loops. > > The header can't be shared, otherwise

Hi, On 2013-02-25 8:22 PM, "Krzysztof Parzyszek" <kparzysz at codeaurora.org> wrote: >On 2/25/2013 4:50 PM, Redmond, Paul wrote: >> >> On the branch into the loop: > >Well... In this case the metadata is not on the latch. I guess this is >because the initial loop structure is this questionable >jump-to-cond-then-back scheme. I agree---this doesn't

...0 10 1 0.00000000 1.31000 279.2400 1.860000 5.800000 ...so after about 170 observations it changes to week 2, and so on. I've tried something like this, but its only one variable's mean, and I would rather have the rows=weeks and columns= the different variables. < tapply(metdata$rainfall,metdata$week,FUN=mean) 1 2 3 4 5 6 0.080952381 0.101190476 0.379761905 0.179761905 0.000000000 0.295238095 7 8 9 10 11 12 0.146428571 0.015476190 0.163888889 0.098809524...

...ew bitstream on each song change, but still no-go. Only on the very first reconnect does the title streaming show correct. The metadata information however NEVER displays correctly in the stats.xml - even though the comment headers seem to be fine - so I suspect I need to use another method? btw - Metdata inside OddCast DSP seems to work fine... Louis ----- Original Message ----- From: "Geoff Shang" <gshang@uq.net.au> To: <icecast-dev@xiph.org> Sent: Friday, March 21, 2003 5:02 PM Subject: Re: [icecast-dev] Metadata <p>> Hi: > > Disclaimer: I'm not a devel...

...ce, there's lots of vmap() based accessing in kernel. Think in another direction, this means we won't suffer form unnecessary barriers for kthread like vhost in the future, we will manually pick the one we really need (but it should have little possibility). Please notice we only access metdata through remapping not the data itself. This idea has been used for high speed userspace backend for years, e.g packet socket or recent AF_XDP. The only difference is the page was remap to from kernel to userspace. > I don't > like the idea I have to say. As a first step, why don&...

...ce, there's lots of vmap() based accessing in kernel. Think in another direction, this means we won't suffer form unnecessary barriers for kthread like vhost in the future, we will manually pick the one we really need (but it should have little possibility). Please notice we only access metdata through remapping not the data itself. This idea has been used for high speed userspace backend for years, e.g packet socket or recent AF_XDP. The only difference is the page was remap to from kernel to userspace. > I don't > like the idea I have to say. As a first step, why don&...

On Fri, Dec 14, 2018 at 11:57:35AM +0800, Jason Wang wrote: > > On 2018/12/13 ??11:44, Michael S. Tsirkin wrote: > > On Thu, Dec 13, 2018 at 06:10:22PM +0800, Jason Wang wrote: > > > It was noticed that the copy_user() friends that was used to access > > > virtqueue metdata tends to be very expensive for dataplane > > > implementation like vhost since it involves lots of software check, > > > speculation barrier, hardware feature toggling (e.g SMAP). The > > > extra cost will be more obvious when transferring small packets. > > > &...

On Fri, Dec 14, 2018 at 11:57:35AM +0800, Jason Wang wrote: > > On 2018/12/13 ??11:44, Michael S. Tsirkin wrote: > > On Thu, Dec 13, 2018 at 06:10:22PM +0800, Jason Wang wrote: > > > It was noticed that the copy_user() friends that was used to access > > > virtqueue metdata tends to be very expensive for dataplane > > > implementation like vhost since it involves lots of software check, > > > speculation barrier, hardware feature toggling (e.g SMAP). The > > > extra cost will be more obvious when transferring small packets. > > > &...

So why does the ices.conf file have <Protocol>http</Protocol> ic it is going to use icy anyways? On Fri, Feb 26, 2016 at 2:00 AM, Marvin Scholz <epirat07 at gmail.com> wrote: > On 26 Feb 2016, at 7:03, A. Craig West wrote: > > > I have been trying to access the "artist" and "title" metadata in the > > xml > > files as separate

-llvm-commits, +llvmdev > On Oct 2, 2014, at 2:57 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > > Author: dexonsmith > Date: Thu Oct 2 16:56:57 2014 > New Revision: 218914 > > URL: http://llvm.org/viewvc/llvm-project?rev=218914&view=rev > Log: > DI: Fold constant arguments into a single MDString > > This patch addresses the first