On Sun, Jun 23, 2013 at 11:56 PM, Alex Deucher wrote:
> On Sun, Jun 23, 2013 at 2:24 PM, Marek Olšák wrote:
>> Hi Alex,
>>
>> rctx->framebuffer.state.nr_cbufs might not contain what you think it
>> does, because the framebuffer that needs flushing may have been
>> replaced by a new framebuffer an
This might fix the lockups caused by colorbuffer flushes and it's generally
the right thing to do. Untested.
---
src/gallium/drivers/r600/evergreen_compute.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/galliu
---
src/gallium/auxiliary/util/u_format.c | 14 ++
src/gallium/auxiliary/util/u_format.h | 3 +++
src/mesa/state_tracker/st_cb_drawpixels.c | 6 ++
3 files changed, 23 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.c
b/src/gallium/auxiliary/util/u_format
On Sun, Jun 23, 2013 at 5:47 PM, Andy Furniss wrote:
> Ilia Mirkin wrote:
>>
>> Signed-off-by: Ilia Mirkin
>> ---
>>
>> These changes make MPEG2 I-frames generate the correct macroblock data (as
>> compared to mplayer via xvmc). Other MPEG2 frames are still misparsed, and
>> MPEG1 I-frames have s
On Sun, Jun 23, 2013 at 2:24 PM, Marek Olšák wrote:
> Hi Alex,
>
> rctx->framebuffer.state.nr_cbufs might not contain what you think it
> does, because the framebuffer that needs flushing may have been
> replaced by a new framebuffer and the cache flushing of the old
> framebuffer usually takes pl
Ilia Mirkin wrote:
Signed-off-by: Ilia Mirkin
---
These changes make MPEG2 I-frames generate the correct macroblock data (as
compared to mplayer via xvmc). Other MPEG2 frames are still misparsed, and
MPEG1 I-frames have some errors (but largely match up).
This messes up mpeg2 vdpau decode for
On Sun, Jun 23, 2013 at 7:41 PM, Alex Deucher wrote:
> On Sat, Jun 22, 2013 at 11:53 AM, Martin Andersson wrote:
>> On Sat, Jun 22, 2013 at 12:22 PM, Marek Olšák wrote:
>>> Reviewed-by: Marek Olšák
>>>
>>> BTW, SMX is a write cache, to maybe it shouldn't be part of this patch.
>>
>> I made a li
Hi Alex,
rctx->framebuffer.state.nr_cbufs might not contain what you think it
does, because the framebuffer that needs flushing may have been
replaced by a new framebuffer and the cache flushing of the old
framebuffer usually takes place before the first draw to the new
framebuffer. To solve this,
On Sat, Jun 22, 2013 at 11:53 AM, Martin Andersson wrote:
> On Sat, Jun 22, 2013 at 12:22 PM, Marek Olšák wrote:
>> Reviewed-by: Marek Olšák
>>
>> BTW, SMX is a write cache, to maybe it shouldn't be part of this patch.
>
> I made a little experiment where i ran
> "ext_framebuffer_multisample-una
Signed-off-by: Ilia Mirkin
---
These changes make MPEG2 I-frames generate the correct macroblock data (as
compared to mplayer via xvmc). Other MPEG2 frames are still misparsed, and
MPEG1 I-frames have some errors (but largely match up).
src/gallium/auxiliary/vl/vl_mpeg12_bitstream.c | 84 ++
Currently libXvMCnouveau.so is missing nv30_screen_create. Add it in so
that it may be dlopen'd.
Signed-off-by: Ilia Mirkin
---
MPEG1/2 bitstream decoding is nowhere near working in vl. XvMC appears to work
flawlessly though, so let's make sure it's usable.
src/gallium/targets/xvmc-nouveau/Mak
https://bugs.freedesktop.org/show_bug.cgi?id=65898
--- Comment #4 from Mike Higgins ---
Eric:
Thanks for the links, a little over my head, but was reassured to see the
graphics card was doing something :)
intel_gpu_top output:
render clock: 500 Mhz sampler clock: 533 Mhz
r
12 matches
Mail list logo
