On Fri, Dec 16, 2011 at 7:01 PM, James Cloos cl...@jhcloos.com 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
On Fri, Dec 16, 2011 at 7:38 PM, James Jones jajo...@nvidia.com wrote:
On 12/16/11 4:27 PM, Younes Manton wrote:
On Fri, Dec 16, 2011 at 7:01 PM, James Clooscl...@jhcloos.com wrote:
I've been trying to test out vdpau w/o success.
It turns out that libvdpau_r600.so is in /usr/lib64/vdpau
On Tue, Dec 6, 2011 at 4:51 PM, Andy Furniss andy...@ukfsn.org 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
On Thu, Dec 1, 2011 at 7:00 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
src/gallium/include/pipe/p_video_state.h | 3 +++
src/gallium/state_trackers/vdpau/decode.c | 3 +++
2 files changed, 6 insertions(+), 0
2011/11/21 Christian König deathsim...@vodafone.de:
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,
On Tue, Oct 25, 2011 at 1:35 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
diff --git a/src/gallium/state_trackers/vdpau/mixer.c
b/src/gallium/state_trackers/vdpau/mixer.c
index 8728157..83daddf 100644
---
On Mon, Sep 5, 2011 at 11:35 PM, Andrew Randrianasulu
randrianas...@gmail.com 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:
On Thu, Sep 1, 2011 at 10:56 AM, Michel Dänzer mic...@daenzer.net 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 deathsim...@vodafone.de
---
src/gallium/auxiliary/util/u_format.csv | 6
On Thu, Sep 1, 2011 at 11:08 AM, Christoph Bumiller
e0425...@student.tuwien.ac.at wrote:
On 01.09.2011 17:02, Younes Manton wrote:
On Thu, Sep 1, 2011 at 10:56 AM, Michel Dänzer mic...@daenzer.net wrote:
On Don, 2011-09-01 at 15:50 +0200, Christian König wrote:
Start with correctly defining
2011/9/1 Christian König deathsim...@vodafone.de:
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 {
+
2011/9/1 Christian König deathsim...@vodafone.de:
Am Donnerstag, den 01.09.2011, 13:28 -0400 schrieb Younes Manton:
2011/9/1 Christian König deathsim...@vodafone.de:
This gets mplayers menu overlay working.
+ if (destination_rect) {
+ res_tmpl.width0 = abs(destination_rect-x0
2011/8/29 Maarten Lankhorst m.b.lankho...@gmail.com:
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 buffers should be handled internally
On Sat, Aug 27, 2011 at 7:58 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
The nouveau xvmc decoder doesn't need it.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
src/gallium/state_trackers/xorg/xvmc/surface.c | 9 ++---
1 files changed, 6 insertions(+), 3
On Sat, Aug 27, 2011 at 7:56 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
.../xorg/xvmc/tests/test_rendering.c | 38 ---
1 files changed, 24 insertions(+), 14 deletions(-)
diff --git
On Sun, Aug 28, 2011 at 12:13 PM, Younes Manton youne...@gmail.com wrote:
On Sat, Aug 27, 2011 at 7:58 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
The nouveau xvmc decoder doesn't need it.
Signed-off-by: Maarten Lankhorst m.b.lankho...@gmail.com
---
src/gallium/state_trackers/xorg
On Sun, Aug 28, 2011 at 12:56 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
On 08/28/2011 06:23 PM, Younes Manton wrote:
On Sun, Aug 28, 2011 at 12:13 PM, Younes Manton youne...@gmail.com wrote:
On Sat, Aug 27, 2011 at 7:58 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote
On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul bri...@vmware.com 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.
On Fri, Aug 26, 2011 at 5:54 PM, Zack Rusin za...@vmware.com wrote:
On Friday, August 26, 2011 05:12:52 PM Younes Manton wrote:
On Fri, Aug 26, 2011 at 4:31 PM, Brian Paul bri...@vmware.com wrote:
Two things that should probably be fixed in the src/gallium/auxiliary/vl/
code:
1
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 the bugs.
Christian.
Reviewed-by: Younes Manton youne
2011/8/16 Christian König deathsim...@vodafone.de:
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;
+ mb-macroblock_address
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
2011/8/12 Christian König deathsim...@vodafone.de:
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 with Mesa's MIT license
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
2011/8/8 Christian König deathsim...@vodafone.de:
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
2011/8/8 Christian König deathsim...@vodafone.de:
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 decoder
2011/8/8 Christian König deathsim...@vodafone.de:
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
On Fri, Jul 29, 2011 at 9:37 AM, Maarten Lankhorst
m.b.lankho...@gmail.com 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
On Fri, Jul 29, 2011 at 6:46 PM, Maarten Lankhorst
m.b.lankho...@gmail.com 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
On Fri, Jul 29, 2011 at 7:45 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
On 07/30/2011 01:05 AM, Younes Manton wrote:
On Fri, Jul 29, 2011 at 6:46 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
2nd patch isn't needed. You shouldn't call vl_video_buffer_create_ex,
you should
On Fri, Jul 29, 2011 at 8:15 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
On 07/30/2011 01:57 AM, Younes Manton wrote:
On Fri, Jul 29, 2011 at 7:45 PM, Maarten Lankhorst
m.b.lankho...@gmail.com wrote:
On 07/30/2011 01:05 AM, Younes Manton wrote:
On Fri, Jul 29, 2011 at 6:46 PM
On Fri, Jul 22, 2011 at 10:00 AM, Brian Paul bri...@vmware.com 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 wrong value during
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 6:21 PM, Jose Fonseca jfons...@vmware.com 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
On Mon, Jul 18, 2011 at 8:32 PM, Marek Olšák mar...@gmail.com wrote:
On Tue, Jul 19, 2011 at 12:21 AM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
We can't do try-map + create + map + dereference internally in a
driver. Creating a new buffer and replacing a pointer
2011/7/12 Keith Whitwell kei...@vmware.com:
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
On Mon, Jun 6, 2011 at 12:52 PM, Roland Scheidegger srol...@vmware.com wrote:
Am 05.06.2011 06:31, schrieb Younes Manton:
2011/6/4 Jose Fonseca jfons...@vmware.com:
At very least there are ovious things that need to be fixed:
- get_param / is_format_supported should not be duplicated from
On Mon, Jun 13, 2011 at 3:23 PM, Jose Fonseca jfons...@vmware.com wrote:
- Original Message -
Am 05.06.2011 06:31, schrieb Younes Manton:
2011/6/4 Jose Fonseca jfons...@vmware.com:
At very least there are ovious things that need to be fixed:
- get_param / is_format_supported
2011/6/4 Jose Fonseca jfons...@vmware.com:
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
2010/11/12 Christian König deathsim...@vodafone.de:
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,
On Wed, Nov 10, 2010 at 9:56 AM, Christian König
deathsim...@vodafone.de 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
On Thu, Jun 10, 2010 at 3:23 PM, Roland Scheidegger srol...@vmware.com 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
41 matches
Mail list logo
