2011/12/21 Maarten Lankhorst :
> Hey Christian,
>
> On 12/21/2011 04:41 PM, Christian König wrote:
>> Those functions are called a couple of million times a second, so even if
>> the assertion is only tested in debug builds it has quite an effect on
>> performance, sometimes even masquerading rea
On Fri, Dec 16, 2011 at 7:38 PM, James Jones wrote:
> On 12/16/11 4:27 PM, Younes Manton wrote:
>>
>> On Fri, Dec 16, 2011 at 7:01 PM, James Cloos wrote:
>>>
>>> I've been trying to test out vdpau w/o success.
>>>
>>> It turns ou
On Fri, Dec 16, 2011 at 7:01 PM, James Cloos wrote:
> I've been trying to test out vdpau w/o success.
>
> It turns out that libvdpau_r600.so is in /usr/lib64/vdpau/, whereas
> everything looks for it in the standard ld path (ie, /usr/lib64).
>
> With »ln -s vdpau/libvdpau_r600.so /usr/lib64/« it s
On Thu, Dec 1, 2011 at 7:00 PM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> src/gallium/include/pipe/p_video_state.h | 3 +++
> src/gallium/state_trackers/vdpau/decode.c | 3 +++
> 2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/src/gallium/includ
On Sat, Dec 10, 2011 at 11:13 PM, Tobias Droste wrote:
> fixes the following build error since
> c83fb4d45f2a47042f395271efe6e5489b2c4aee:
>
> /usr/include/strings.h:46:13: error: expected declaration specifiers or
> ‘...’ before numeric constant
> /usr/include/strings.h:46:13: error: conflicting
On Tue, Dec 6, 2011 at 4:51 PM, Andy Furniss wrote:
> Maarten Lankhorst wrote:
>>
>> The brokenness in vlVdpVideoMixerRender was compensating for
>> brokenness in vlVdpPresentationQueueDisplay, so fix both at
>> the same time.
>
>
> These fix the two remaining issues (aspect not maintained when fu
2011/11/21 Christian König :
> On 16.11.2011 15:38, Maarten Lankhorst wrote:
>> If the decode_bitstream interface is changed to get all bitstream buffers
>> at the same time,
>> there wouldn't be overhead to doing it like this. For a single picture
>> it's supposed to stay constant,
>> so for vdpau
On Tue, Oct 25, 2011 at 1:35 PM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
> ---
>
> diff --git a/src/gallium/state_trackers/vdpau/mixer.c
> b/src/gallium/state_trackers/vdpau/mixer.c
> index 8728157..83daddf 100644
> --- a/src/gallium/state_trackers/vdpau/mixer.c
> +++ b/src/g
On Mon, Sep 5, 2011 at 11:35 PM, Andrew Randrianasulu
wrote:
> Hello.
>
> Just tested http://repo.or.cz/w/mesa/nouveau-pmpeg.git/ (commit
> 25363beccacc70a514045283bbe14951262f7b1f, "nouveau video fixup") with my nv43.
>
> At first, i got only nv40_fragtex.c:50: nv40_sampler_view_init: Assertion
>
2011/9/1 Christian König :
> Am Donnerstag, den 01.09.2011, 13:28 -0400 schrieb Younes Manton:
>> 2011/9/1 Christian König :
>> > This gets mplayers menu overlay working.
>>
>> > + if (destination_rect) {
>> > + res_tmpl.width0 = abs
2011/9/1 Christian König :
> This gets mplayers menu overlay working.
> + if (destination_rect) {
> + res_tmpl.width0 = abs(destination_rect->x0-destination_rect->x1);
> + res_tmpl.height0 = abs(destination_rect->y0-destination_rect->y1);
> + } else {
> + res_tmpl.width0 = vlsur
On Thu, Sep 1, 2011 at 11:08 AM, Christoph Bumiller
wrote:
> On 01.09.2011 17:02, Younes Manton wrote:
>> On Thu, Sep 1, 2011 at 10:56 AM, Michel Dänzer wrote:
>>> On Don, 2011-09-01 at 15:50 +0200, Christian König wrote:
>>>> Start with correctly defining IA44 and
On Thu, Sep 1, 2011 at 10:56 AM, Michel Dänzer wrote:
> On Don, 2011-09-01 at 15:50 +0200, Christian König wrote:
>> Start with correctly defining IA44 and AI44 formats.
>>
>> Signed-off-by: Christian König
>> ---
>> src/gallium/auxiliary/util/u_format.csv | 6 +++-
>> src/gallium/auxiliary
2011/8/29 Maarten Lankhorst :
> Hey,
>
> On 08/29/2011 10:08 AM, Christian König wrote:
>> Am Montag, den 29.08.2011, 00:36 -0400 schrieb Younes Manton:
>> [snip]
>>> Well, that was what the last discussion was all about, whether or not
>>> decode buffe
On Sun, Aug 28, 2011 at 12:56 PM, Maarten Lankhorst
wrote:
> On 08/28/2011 06:23 PM, Younes Manton wrote:
>> On Sun, Aug 28, 2011 at 12:13 PM, Younes Manton wrote:
>>> On Sat, Aug 27, 2011 at 7:58 PM, Maarten Lankhorst
>>> wrote:
>>>> The nouveau xvmc de
On Sun, Aug 28, 2011 at 12:13 PM, Younes Manton wrote:
> On Sat, Aug 27, 2011 at 7:58 PM, Maarten Lankhorst
> wrote:
>> The nouveau xvmc decoder doesn't need it.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> src/gallium/state_trackers/xorg/xvmc/surfa
On Sat, Aug 27, 2011 at 7:56 PM, Maarten Lankhorst
wrote:
> Signed-off-by: Maarten Lankhorst
> ---
> .../xorg/xvmc/tests/test_rendering.c | 38 ---
> 1 files changed, 24 insertions(+), 14 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xorg/xvmc/tests/tes
On Sat, Aug 27, 2011 at 7:58 PM, Maarten Lankhorst
wrote:
> The nouveau xvmc decoder doesn't need it.
>
> Signed-off-by: Maarten Lankhorst
> ---
> src/gallium/state_trackers/xorg/xvmc/surface.c | 9 ++---
> 1 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/stat
On Fri, Aug 26, 2011 at 5:54 PM, Zack Rusin wrote:
> On Friday, August 26, 2011 05:12:52 PM Younes Manton wrote:
>> On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul wrote:
>> > Two things that should probably be fixed in the src/gallium/auxiliary/vl/
>> > code:
>> &
On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul wrote:
> Two things that should probably be fixed in the src/gallium/auxiliary/vl/
> code:
>
> 1. The copyright statements refer to Tungsten Graphics. That's probably a
> copy & paste error. s/Tungsten Graphics/the authors/ or thereabouts.
>
> 2. #incl
o the XvMC interface
> it doesn't implement zscan, quant and mismatch control inside the
> bitstream parser, so that still needs to be done on the hardware side.
>
> Sorry for the delay, beside recovering from a hard-disk crash, I needed
> a couple of days to hammer out all t
2011/8/16 Christian König :
> Am Dienstag, den 16.08.2011, 01:15 -0400 schrieb Younes Manton:
>> Anyway, here are some specific comments:
>>
>> + for (; num_macroblocks > 0; --num_macroblocks) {
>> + mb->base.codec = PIPE_VIDEO_CODEC_MPEG12;
>> +
Hi,
I tried to give some thought to how this interface would work for
decoders that can't or would prefer not to support multiple decode
buffers, and most of the scenarios I came up with seem to work out, so
overall I'm not opposed to it. Even though I still think this can be
done by each driver w
2011/8/12 Christian König :
> Am Donnerstag, den 11.08.2011, 12:04 -0400 schrieb Younes Manton:
>> It's been brought to my attention that the source this is based on is
>> GPL'd, which means it needs to go before 7.12 is released since it's
>> incompatible
It's been brought to my attention that the source this is based on is
GPL'd, which means it needs to go before 7.12 is released since it's
incompatible with Mesa's MIT license.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesk
2011/8/8 Christian König :
> Am Montag, den 08.08.2011, 15:00 +0200 schrieb Maarten Lankhorst:
>> On 08/08/2011 12:10 PM, Christian König wrote:
>> > Most modern players doesn't do it like this any more, but it still seems
>> > to cause a bunch of problems when seeking or fast forward both with
>>
2011/8/8 Christian König :
> Am Montag, den 08.08.2011, 15:00 +0200 schrieb Maarten Lankhorst:
>> On 08/08/2011 12:10 PM, Christian König wrote:
>> > Most modern players doesn't do it like this any more, but it still seems
>> > to cause a bunch of problems when seeking or fast forward both with
>>
2011/8/8 Christian König :
> Am Samstag, den 06.08.2011, 14:37 -0400 schrieb Younes Manton:
>> The attached patch I believe should satisfy everyone's needs here. It
>> removes the use of pipe_video_decode_buffer from the state tracker and
>> moves it to the shader decode
On Fri, Jul 29, 2011 at 8:15 PM, Maarten Lankhorst
wrote:
> On 07/30/2011 01:57 AM, Younes Manton wrote:
>> On Fri, Jul 29, 2011 at 7:45 PM, Maarten Lankhorst
>> wrote:
>>> On 07/30/2011 01:05 AM, Younes Manton wrote:
>>>> On Fri, Jul 29, 2011 at 6:
On Fri, Jul 29, 2011 at 7:45 PM, Maarten Lankhorst
wrote:
> On 07/30/2011 01:05 AM, Younes Manton wrote:
>> On Fri, Jul 29, 2011 at 6:46 PM, Maarten Lankhorst
>> wrote:
>>>> 2nd patch isn't needed. You shouldn't call vl_video_buffer_create_ex,
>>&g
On Fri, Jul 29, 2011 at 6:46 PM, Maarten Lankhorst
wrote:
>> 2nd patch isn't needed. You shouldn't call vl_video_buffer_create_ex,
>> you should override the create_buffer hook yourself and do what you
>> want. I'll push the 1st one later.
> What create_buffer hook do you mean? If you mean
> pipe_
On Fri, Jul 29, 2011 at 9:37 AM, Maarten Lankhorst
wrote:
> Hi guys,
>
> With some help from the nouveau team I managed to get video acceleration
> working for my nv96 card. The video buffer api works well enough for nouveau,
> I added flags to vl_video_buffer_create_ex so I could force a linear s
On Fri, Jul 22, 2011 at 10:00 AM, Brian Paul wrote:
> On 07/21/2011 06:59 PM, Younes Manton wrote:
>>
>> The blend_quad function clobbers the actual render target color/alpha
>> values while applying the destination blend factor, which results in
>> restoring the wro
The blend_quad function clobbers the actual render target color/alpha
values while applying the destination blend factor, which results in
restoring the wrong value during the masking stage for write-disabled
channels.
---
src/gallium/drivers/softpipe/sp_quad_blend.c | 185 +--
On Mon, Jul 18, 2011 at 8:32 PM, Marek Olšák wrote:
> On Tue, Jul 19, 2011 at 12:21 AM, Jose Fonseca wrote:
>>
>>
>> - Original Message -
>>> We can't do try-map + create + map + dereference internally in a
>>> driver. Creating a new buffer and replacing a pointer to the old one
>>> may l
On Mon, Jul 18, 2011 at 6:21 PM, Jose Fonseca wrote:
>
>
> - Original Message -
>> We can't do try-map + create + map + dereference internally in a
>> driver. Creating a new buffer and replacing a pointer to the old one
>> may lead to the following issue. If a buffer pointer is replaced, i
On Thu, Jul 14, 2011 at 1:19 PM, Christian König
wrote:
> Yeah, I also thought about this. My overall feeling was to get it into
> VRAM first and then bring it into the form needed by the hardware with a
> shader if the need arise.
That's pretty much impossible since you can't use a shader to gen
2011/7/12 Keith Whitwell :
> I'm a bit unsure about what's the best approach here, though at this
> stage I'm happy with your approach and don't think it needs to be
> changed before any merge.
>
> But speaking in general terms, individual planes map well onto 8-bit
> single-component texture image
On Thu, Jun 16, 2011 at 10:14 AM, Jose Fonseca wrote:
>
> Younes,
>
> If the thread you quote had been last word on the subject, then then this
> thread would have never happened:
>
> http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg09601.html
>
> and this conversation would not b
On Mon, Jun 13, 2011 at 3:23 PM, Jose Fonseca wrote:
>
> - Original Message -
>> Am 05.06.2011 06:31, schrieb Younes Manton:
>> > 2011/6/4 Jose Fonseca :
>> >> At very least there are ovious things that need to be fixed:
>> >>
>>
On Mon, Jun 6, 2011 at 12:52 PM, Roland Scheidegger wrote:
> Am 05.06.2011 06:31, schrieb Younes Manton:
>> 2011/6/4 Jose Fonseca :
>>> At very least there are ovious things that need to be fixed:
>>>
>>> - get_param / is_format_supported should not be duplic
2011/6/4 Jose Fonseca :
> I think we need to have a proper review round of the gallium interfaces, so
> that we have an interface everybody feels that we can support going forward,
> which did not happen last round.
>
> That said, I don't think much attention has been given to this branch outside
2010/11/12 Christian König :
> What I need for both the ycrcb texture and vertex uploads is a buffer in
> system memory, where the cpu access is fast and a function to tell the
> gpu to upload this buffer to vram, so the cpu doesn't need to pump the
> data over the system bus, wait for an "in use"
On Wed, Nov 10, 2010 at 9:56 AM, Christian König
wrote:
> I also started to profile the performance of the code a bit, as expected
> we spend far to much time deciding of how and where to draw something
> compared to really drawing something. Up to 50% of the whole cpu time is
> spend in gen_block
2010/10/22 Christian König :
> Hi, Younes,
>
> my target is the R600 chipset not the R300 series, so the first step was
> merging the pipe-video branche with master and getting r600g to work.
>
> After this was done, I added a video context creation function to r600g
> as you suggested. Least I fix
On Thu, Jun 10, 2010 at 3:23 PM, Roland Scheidegger wrote:
> On 10.06.2010 21:14, Keith Whitwell wrote:
>> On Thu, 2010-06-10 at 11:32 -0700, Roland Scheidegger wrote:
>>> On 10.06.2010 17:12, Keith Whitwell wrote:
On Thu, 2010-06-10 at 07:29 -0700, Brian Paul wrote:
> Keith Whitwell wrot
46 matches
Mail list logo
