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
- Original Message -
> 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:
> >> >>
> >> >> - get_pa
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:
>> >>
>> >> - get_param / is_format_supported should not be duplicate
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 duplicated from screen.
>>
>> This is also de
- 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:
> >>
> >> - get_param / is_format_supported should not be duplicated from
> >> screen.
> >
> > This is also deliberate.
> > Pa
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 duplicated from screen.
>
> This is also deliberate. Params and surface formats may depend on the
> codec/prof
Am Samstag, den 04.06.2011, 18:28 -0700 schrieb 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.
I agree to that, the interface was at lea
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
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
from those working on it. So th
2011/6/4 Christian König :
> Am Samstag, den 04.06.2011, 15:20 -0400 schrieb Matt Turner:
>> Is there a reason that this can't be merged to master?
> Since float buffer support was merged to master I can't see any more
> obstacles. Just gone over the branch one more time and fixed some
> problem cr
Am Samstag, den 04.06.2011, 15:20 -0400 schrieb Matt Turner:
> Is there a reason that this can't be merged to master?
Since float buffer support was merged to master I can't see any more
obstacles. Just gone over the branch one more time and fixed some
problem created by merging.
> It seems like t
2011/4/26 Christian König :
> Hi Andy and everybody on the list,
>
> sorry for the late reply, but i've been on vacation the last couple of
> days.
>
> Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss:
>> In addition to the quit crash I notice that resizing will also crash.
> Should be
Christian König wrote:
Am Montag, den 16.05.2011, 19:54 +0100 schrieb Andy Furniss:
I noticed another strange thing with pipe-video on my rv670.
Until recently there was a bug that made the mesa demo lodbias misrender.
It's fixed now in master and pipe-video, but if I use pipe-video + vdpau
de
Am Montag, den 16.05.2011, 19:54 +0100 schrieb Andy Furniss:
> I noticed another strange thing with pipe-video on my rv670.
>
> Until recently there was a bug that made the mesa demo lodbias misrender.
>
> It's fixed now in master and pipe-video, but if I use pipe-video + vdpau
> decode (xvmc un
Christian König wrote:
My rv670 is still suffering quite different problems both xvmc and vdpau -
http://www.andyqos.ukfsn.org/pend-rv670-vdpau.png
http://www.andyqos.ukfsn.org/mobcal-rv670-vdpau.png
It's on my todo list, but I don't have any idea what's causing this,
probably more a bug inside
Am Montag, den 09.05.2011, 20:04 +0100 schrieb Andy Furniss:
> On my rv790 there are still vdpau decode artifacts that don't show with
> xvmc -
I fixed a couple of bugs with the vdpau implementation, at least the
first 50 frame of pendulum are now binary identical to the xvmc output
and newmobcal
Christian König wrote:
My rv670 is still suffering quite different problems both xvmc and vdpau -
Please try the following patch with xvmc:
--- a/src/gallium/drivers/r600/r600_video_context.c
+++ b/src/gallium/drivers/r600/r600_video_context.c
@@ -40,5 +40,5 @@ r600_video_create(struct pipe_scr
Am Montag, den 09.05.2011, 20:04 +0100 schrieb Andy Furniss:
> Andy Furniss wrote:
>
> > dd6cd206a6395be651bc965580e17c0d63513c7b
> >
> > [g3dvl] correctly implement non power of two buffers
> >
> > regresses rendering on my RV670.
Very interesting, sounds like a bug in the shader compiler for R6x
Andy Furniss wrote:
dd6cd206a6395be651bc965580e17c0d63513c7b
[g3dvl] correctly implement non power of two buffers
regresses rendering on my RV670.
I see with the weekend changes and master merge that the "new" xvmc
artifacts on my rv790 are now gone without patching.
mplayer vanilla is wo
2011/5/7 Christian König :
> Am Donnerstag, den 05.05.2011, 17:53 -0400 schrieb Alex Deucher:
>> Something like the attached patch should work.
> If EXPORT_NORM is just an optimisation, then why is piglits "fbo-srgb"
> test is failing when I comment it out on my RV710? I just want to avoid
> a regr
Am Donnerstag, den 05.05.2011, 17:53 -0400 schrieb Alex Deucher:
> Something like the attached patch should work.
If EXPORT_NORM is just an optimisation, then why is piglits "fbo-srgb"
test is failing when I comment it out on my RV710? I just want to avoid
a regression on R6xx when implementing ble
Christian König wrote:
But how do you test this? Are you using the mplayer or some other tool
to get the vdpau output playing without synchronisation? Asking because
I'm still searching for something similar to mpeg2play_accel, a very
simple tool to hack and test the interface.
I am just using
Am Freitag, den 06.05.2011, 00:17 +0100 schrieb Andy Furniss:
> > I'm currently focusing more on the variable length decoding part of the
> > vdpau mpeg2, by the way: How is well does this work on your hardware?
>
> Still showing the new artifacts even with the patch. It's also quite
> slow, I ha
Andy Furniss wrote:
It does fix xvmc - my chip is RV770 (well RV790) so I wasn't expecting
any change.
I've got a RV670 box that I test with occasionally, so I thought I would
try that - I didn't get to test the patch as I found it has suffered a
separate regression, which causes quite diffe
Christian König wrote:
The problem is more complicated than this, using a signed buffer format
is just a workaround, the real solution is to implement blender clamping
in r600g. You could try this (temporary) patch until I figured out how
to do this correctly on all supported hardware:
--- a/sr
2011/5/5 Christian König :
> Am Donnerstag, den 05.05.2011, 12:11 +0100 schrieb Andy Furniss:
>> Andy Furniss wrote:
>> > There has been a regression though -
>> >
>> > [g3dvl] remove resource_format workaround
>> >
>> > causes quite bad artifacts on newmobcal.
>>
>> I can get rid of the new artifa
Am Donnerstag, den 05.05.2011, 12:11 +0100 schrieb Andy Furniss:
> Andy Furniss wrote:
> > There has been a regression though -
> >
> > [g3dvl] remove resource_format workaround
> >
> > causes quite bad artifacts on newmobcal.
>
> I can get rid of the new artifacts for xvmc with the patch below.
>
Andy Furniss wrote:
There has been a regression though -
[g3dvl] remove resource_format workaround
causes quite bad artifacts on newmobcal.
I can get rid of the new artifacts for xvmc with the patch below.
ffmpeg12vdpau shows the same "new" artifacts, but is not fixed by this.
diff --git a/
2011/4/26 Alex Deucher :
> 2011/4/26 Christian König :
>> Hi Alex,
>>
>> Am Dienstag, den 26.04.2011, 09:52 -0400 schrieb Alex Deucher:
>>> This looks great Christian. Nice work. One quick note regarding
>>> 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446, COLOR[0-7]_INFO does need a
>>> bo. It's requi
2011/4/26 Christian König :
> Hi Alex,
>
> Am Dienstag, den 26.04.2011, 09:52 -0400 schrieb Alex Deucher:
>> This looks great Christian. Nice work. One quick note regarding
>> 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446, COLOR[0-7]_INFO does need a
>> bo. It's required since that reg has the tiling
Andy Furniss wrote:
So is there something still missing for the xvmc state tracker, or can I
continue with implementing the vdpau state tracker?
There is a fullscreen issue - with 4/3 content on 16/9 screen the side
black bars are drawn to leave 4/3 viewable, but the content is still
stretched
Hi Alex,
Am Dienstag, den 26.04.2011, 09:52 -0400 schrieb Alex Deucher:
> This looks great Christian. Nice work. One quick note regarding
> 68cc6bc5d8b6986acc7f5780d705f4ae9be2a446, COLOR[0-7]_INFO does need a
> bo. It's required since that reg has the tiling field and we need the
> reloc to kn
Christian König wrote:
Hi Andy and everybody on the list,
sorry for the late reply, but i've been on vacation the last couple of
days.
Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss:
In addition to the quit crash I notice that resizing will also crash.
Should be fixed by now. I
2011/4/26 Christian König :
> Hi Andy and everybody on the list,
>
> sorry for the late reply, but i've been on vacation the last couple of
> days.
>
> Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss:
>> In addition to the quit crash I notice that resizing will also crash.
> Should be
Hi Andy and everybody on the list,
sorry for the late reply, but i've been on vacation the last couple of
days.
Am Dienstag, den 12.04.2011, 21:38 +0100 schrieb Andy Furniss:
> In addition to the quit crash I notice that resizing will also crash.
Should be fixed by now. I implemented most of the
35 matches
Mail list logo
