https://bugs.freedesktop.org/show_bug.cgi?id=75011
Priority: medium
Bug ID: 75011
Assignee: mesa-dev@lists.freedesktop.org
Summary: Performance drop since git-6d1cecb with radeonsi
Severity: normal
Classification: Unclassified
That's most likely an issue with st/vdpau. I implemented a small hack to
clear the black bars of a surface only once. No idea how exactly it
happens, but Grigoris patch seems to somehow break the logic there.
Anyway we need to rework this part when getting DRI3 anyway (much more
efficiently an
Fixed in my branch:
http://cgit.freedesktop.org/~mareko/mesa/log/?h=buffer-storage
Marek
On Sat, Feb 8, 2014 at 6:32 PM, Fredrik Höglund wrote:
> On Thursday 30 January 2014, Marek Olšák wrote:
>> From: Marek Olšák
>>
>> ---
>> src/mesa/main/api_validate.c | 2 +-
>> src/mesa/main/bufferobj
On Sat, Feb 15, 2014 at 5:10 AM, Christian König
wrote:
> That's most likely an issue with st/vdpau. I implemented a small hack to
> clear the black bars of a surface only once. No idea how exactly it happens,
> but Grigoris patch seems to somehow break the logic there.
>
> Anyway we need to rewor
https://bugs.freedesktop.org/show_bug.cgi?id=75011
Andreas Boll changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
Ilia Mirkin wrote:
On Sat, Feb 15, 2014 at 5:10 AM, Christian König
wrote:
That's most likely an issue with st/vdpau. I implemented a small hack to
clear the black bars of a surface only once. No idea how exactly it happens,
but Grigoris patch seems to somehow break the logic there.
Anyway we
Tom Stellard writes:
> From: Tom Stellard
>
> The offsets will be stored in the handles parameter. This makes
> it possible to use sub-buffers.
> ---
> src/gallium/drivers/r600/evergreen_compute.c | 2 +-
> src/gallium/drivers/radeonsi/si_compute.c | 1 +
> src/gallium/include/p
Andy Furniss wrote:
Ilia Mirkin wrote:
On Sat, Feb 15, 2014 at 5:10 AM, Christian König
wrote:
That's most likely an issue with st/vdpau. I implemented a small
hack to clear the black bars of a surface only once. No idea how
exactly it happens, but Grigoris patch seems to somehow break the
log
On Saturday 15 February 2014, Marek Olšák wrote:
> Fixed in my branch:
>
> http://cgit.freedesktop.org/~mareko/mesa/log/?h=buffer-storage
>
> Marek
LGTM.
Reviewed-by: Fredrik Höglund
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://li
On Saturday 15 February 2014, Marek Olšák wrote:
> Almost no drivers clear AccessFlags. This could be fixed with a
> follow-up patch, though it shouldn't block this series.
Agreed.
Fredrik
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http:/
From: Roland Scheidegger
The previous code used coords which were calculated as
(int) (f_coord * tex_size * 256) >> 8.
This is not only unnecessarily complex but can give the wrong texel due to
rounding for negative coords (as an example, after denormalization coords
from -1.0 to 0.0 should give
From: Jeff Muizelaar
The previous method for converting coords to ints was sligthly inaccurate
(effectively losing 1bit from the 8bit lerp weight). This is probably
especially noticeable when trying to draw a pixel-aligned texture.
As an example, for a 100x100 texture after dernormalization the t
On Sat, Feb 15, 2014 at 7:14 AM, Andy Furniss wrote:
> At the start or when I press f on mplayer to toggle between full/window
> I see a frame of old/uninitialised video mem - does this happen on nvidia?
I definitely see something funny. It seemed like the deinterlace was
essentially "turned off"
On 15.02.2014 13:14, Andy Furniss wrote:
Thanks Grigori for doing this - looks really good on HD stuff I've
tested and of course is easily fast enough, unlike anything on the CPU
at high res.
Any plans for the future?
Well, adding edge-guided spatial interpolation for the temporal-spatial
mo
Query of the driver support AVC_HIGH encode before reporting
the total number of supported components.
Signed-off-by: Emil Velikov
---
There is no point in advertising two components - decoder and
encoder if the latter does not exist. Check encoder's presence
and report accordingly.
-Emil
sr
- Bail out early (return 0 components) if there is no
decoder
- Check if the driver supports the bitstream XXX decoder
before using it.
Signed-off-by: Emil Velikov
---
Two issues with first one open to suggestions
- API does not state what one should do if their
driver support only encoding.
The nv84 code (vp2)
- bitstream h264
- idct and bitstream mpeg12
Generic video (vpe2)
- mc and idct mpeg12
Signed-off-by: Emil Velikov
---
Seems like some explicit checks would be more robust when
new code is added. Better to deny support for the user than
crash of feed junk data to the gpu.
Query of the driver support AVC_HIGH encode before reporting
the total number of supported components.
v2: drop if (name_specific_length) check
Signed-off-by: Emil Velikov
---
src/gallium/state_trackers/omx/entrypoint.c | 17 +++--
src/gallium/state_trackers/omx/vid_enc.c| 25 ++
On Sat, Feb 15, 2014 at 2:30 PM, Emil Velikov wrote:
> The nv84 code (vp2)
> - bitstream h264
> - idct and bitstream mpeg12
> Generic video (vpe2)
> - mc and idct mpeg12
>
> Signed-off-by: Emil Velikov
> ---
>
> Seems like some explicit checks would be more robust when
> new code is added. Bet
On 15/02/14 20:03, Ilia Mirkin wrote:
> On Sat, Feb 15, 2014 at 2:30 PM, Emil Velikov
> wrote:
>> The nv84 code (vp2)
>> - bitstream h264
>> - idct and bitstream mpeg12
>> Generic video (vpe2)
>> - mc and idct mpeg12
>>
>> Signed-off-by: Emil Velikov
>> ---
>>
>> Seems like some explicit chec
On Sat, Feb 15, 2014 at 3:17 PM, Emil Velikov wrote:
> On 15/02/14 20:03, Ilia Mirkin wrote:
>> On Sat, Feb 15, 2014 at 2:30 PM, Emil Velikov
>> wrote:
>>> The nv84 code (vp2)
>>> - bitstream h264
>>> - idct and bitstream mpeg12
>>> Generic video (vpe2)
>>> - mc and idct mpeg12
>>>
>>> Signed
Grigori Goronzy wrote:
On 15.02.2014 13:14, Andy Furniss wrote:
Thanks Grigori for doing this - looks really good on HD stuff I've
tested and of course is easily fast enough, unlike anything on the
CPU at high res.
Any plans for the future?
Well, adding edge-guided spatial interpolation for
https://bugs.freedesktop.org/show_bug.cgi?id=74085
--- Comment #4 from Benjamin Bellec ---
I took time to bisect, unfortunatly it seems this bug has always been here, as
far as CSS is playable with Mesa.
As of commit 7af4e18dcd3 (2011-07-11), CSS is playable and the bug was already
here.
As of c
https://bugs.freedesktop.org/show_bug.cgi?id=74085
--- Comment #5 from Benjamin Bellec ---
(In reply to comment #4)
> Maybe I could try to start Steam with previous commits on a RV770, but I
> guess that will not change anything?
"with older commits" I meant.
--
You are receiving this mail be
Signed-off-by: Ilia Mirkin
---
Tom, any objections to enabling xvmc by default again? You turned it off in
commit 6a19bb56e ("configure: Disable xvmc by default") complaining about the
tests failing. These all pass for me now on nouveau.
src/gallium/state_trackers/xvmc/tests/test_rendering.c |
25 matches
Mail list logo
