Displaying 10 results from an estimated 10 matches for "boild".
Did you mean:
boils
2006 Mar 01
3
oggfile, skeleton and vorbis tools
(w. quotes from the xiphmeet:
<http://westfish.xiph.org/~giles/200603_meeting.txt>, I've tried to
strip it down to relevant stuff)
<xiphmont> "Is there any interest in extending vcedit/libvorbisfile to
do basic handling of Vorbis streams from concurrently multiplexed Ogg?"
< xiphmont> Yes, but that work was *also* tied to OggFile from way back
when, and one
2006 Mar 07
2
oggfile, skeleton and vorbis tools
...ere's more than
> one concurrent Vorbis stream but we're still talking about the
> Vorbis-only case.
>
> > [1] The motivation for this would be to allow current players to play
> > Annodexed Ogg Vorbis without noticing.
>
> Yes, there are a few applications that boild down to that (eg, playing
> only the audio from an A/V file in general).
Monty,
(afaik) Ian is working towards patching libvorbisfile to read the first
vorbis logical bitstream in an Ogg file, eg. to allow playing just the
audio from a theora+vorbis file.
ie. libvorbisfile continues to handle...
2014 Jul 22
3
[PATCH 09/17] drm/radeon: use common fence implementation for fences
...a bit of glue to insulate the madness and bad design i915 might do from
radeon. That imo doesn't invalidate the overall fence interfaces.
So what about the following:
- fence->enabling_signaling is restricted to be called from process
context. We don't use any different yet, so would boild down to adding a
WARN_ON(in_interrupt) or so to fence_enable_sw_signalling.
- Make fence->signaled optional (already the case) and don't implement it
in readon (i.e. reduce this patch here). Only downside is that radeon
needs to correctly (i.e. without races or so) call fence_signal....
2014 Jul 22
2
[PATCH 09/17] drm/radeon: use common fence implementation for fences
...d design i915 might do from
>> radeon. That imo doesn't invalidate the overall fence interfaces.
>>
>> So what about the following:
>> - fence->enabling_signaling is restricted to be called from process
>> context. We don't use any different yet, so would boild down to adding a
>> WARN_ON(in_interrupt) or so to fence_enable_sw_signalling.
>>
>> - Make fence->signaled optional (already the case) and don't implement it
>> in readon (i.e. reduce this patch here). Only downside is that radeon
>> needs to correctly...
2006 Mar 07
0
oggfile, skeleton and vorbis tools
...it when Oggfile comes along,
> will they be replaced by something more tightly integrated with
> Oggfile?
Possibly/probably.
> [1] The motivation for this would be to allow current players to play
> Annodexed Ogg Vorbis without noticing.
Yes, there are a few applications that boild down to that (eg, playing
only the audio from an A/V file in general).
Monty
2006 Mar 09
0
oggfile, skeleton and vorbis tools
...one concurrent Vorbis stream but we're still talking about the
>>Vorbis-only case.
>>
>>
>>>[1] The motivation for this would be to allow current players to play
>>>Annodexed Ogg Vorbis without noticing.
>>
>>Yes, there are a few applications that boild down to that (eg, playing
>>only the audio from an A/V file in general).
>
>
> (afaik) Ian is working towards patching libvorbisfile to read the first
> vorbis logical bitstream in an Ogg file, eg. to allow playing just the
> audio from a theora+vorbis file.
>
> ie. l...
2014 Jul 22
0
[PATCH 09/17] drm/radeon: use common fence implementation for fences
...e the madness and bad design i915 might do from
> radeon. That imo doesn't invalidate the overall fence interfaces.
>
> So what about the following:
> - fence->enabling_signaling is restricted to be called from process
> context. We don't use any different yet, so would boild down to adding a
> WARN_ON(in_interrupt) or so to fence_enable_sw_signalling.
>
> - Make fence->signaled optional (already the case) and don't implement it
> in readon (i.e. reduce this patch here). Only downside is that radeon
> needs to correctly (i.e. without races...
2014 Jul 22
0
[PATCH 09/17] drm/radeon: use common fence implementation for fences
...gt; radeon. That imo doesn't invalidate the overall fence interfaces.
>>>>
>>>> So what about the following:
>>>> - fence->enabling_signaling is restricted to be called from process
>>>> context. We don't use any different yet, so would boild down to adding a
>>>> WARN_ON(in_interrupt) or so to fence_enable_sw_signalling.
>>>>
>>>> - Make fence->signaled optional (already the case) and don't implement it
>>>> in readon (i.e. reduce this patch here). Only downside is that rad...
2014 Jul 22
0
[PATCH 09/17] drm/radeon: use common fence implementation for fences
...o from
>>> radeon. That imo doesn't invalidate the overall fence interfaces.
>>>
>>> So what about the following:
>>> - fence->enabling_signaling is restricted to be called from process
>>> context. We don't use any different yet, so would boild down to adding a
>>> WARN_ON(in_interrupt) or so to fence_enable_sw_signalling.
>>>
>>> - Make fence->signaled optional (already the case) and don't implement it
>>> in readon (i.e. reduce this patch here). Only downside is that radeon
>>>...
2014 Jul 22
3
[PATCH 09/17] drm/radeon: use common fence implementation for fences
On Tue, Jul 22, 2014 at 01:46:07PM +0200, Daniel Vetter wrote:
> On Tue, Jul 22, 2014 at 10:43:13AM +0200, Christian K?nig wrote:
> > Am 22.07.2014 06:05, schrieb Dave Airlie:
> > >On 9 July 2014 22:29, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote:
> > >>Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com>
> >