Thanks a lot for the fixes.
There is small issue, if fails to build with meson with 'auto' if tizonia
is installed but not bellagio because ENABLE_ST_OMX_BELLAGIO will remain
defined.
Though it can be added afterward, and the series is:
Tested-by: Julien Isorce
On 7 March 2018 at 1
>
>> >
>> > @Dylan, if possible, could you give an update for the Meson
>> build on
>> > the current set?
>> >
>> >
>> > Thanks,
>> >
>> > Leo
>> >
>> >
>> >
Hi Christian,
>> Otherwise I'm going to give it a few more days on the list and push it
if nobody objects.
Gentle ping ? So far the series are:
Acked-by: Leo Liu
Reviewed-by: Julien Isorce
Thx
Julien
On 30 November 2017 at 14:05, Leo Liu wrote:
>
>
> On 11/30/2017 06:
Hi Gurkirpal, I am glad to see you continue working on this out of the GSoC
project.
I have reviewed it already during that period so just giving my official
"the series is:"
Reviewed-by: Julien Isorce
On 30 November 2017 at 00:23, Dylan Baker wrote:
> Quoting Eric Engestrom (201
Hi Gurkirpal,
> Before refactoring process both the state trackers were in independent
directories.
> During earlier refactoring effort we decided to keep that directory
structure so it made
> sense to move them to auxiliary code. After that I moved them both under
st/omx.
> Since there could be a
the image.
Signed-off-by: Julien Isorce
---
src/mesa/drivers/dri/i965/intel_screen.c | 65 +++-
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index cdc36ad..88bd982 10
Thx for pointing that.
Gentle ping, anyone wants to mark 'reviewed' this patch ?
On 10 November 2017 at 16:18, Rafael Antognolli wrote:
> On Fri, Nov 10, 2017 at 10:46:03AM +, Julien Isorce wrote:
> > Thx for the suggestions.
> >
> > Anyone familiar with
Thx for the suggestions.
Anyone familiar with _mesa_get_format_block_size and _mesa_get_format_bytes
wants to review this patch ?
On 9 November 2017 at 17:10, Eric Engestrom
wrote:
> On Thursday, 2017-11-09 17:03:13 +0000, Julien Isorce wrote:
> > v2: add early return
port-sample_rgb -fmt=XR24 -auto
piglit ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
piglit ext_image_dma_buf_import-sample_yuv -fmt=YU12 -auto
piglit ext_image_dma_buf_import-sample_yuv -fmt=YV12 -auto
Signed-off-by: Julien Isorce
---
src/mesa/drivers/dri/i965/intel_screen.c
Thx
Julien
On 8 November 2017 at 17:18, Emil Velikov wrote:
> Hi Julien,
>
> On 8 November 2017 at 16:55, Julien Isorce
> wrote:
> > v2: add early return if (flag & MAP_INTERNAL_MASK)
> >
> > Already implemented for Gallium drivers.
> >
> > U
glit ext_image_dma_buf_import-sample_yuv -fmt=NV12 -auto
piglit ext_image_dma_buf_import-sample_yuv -fmt=YU12 -auto
piglit ext_image_dma_buf_import-sample_yuv -fmt=YV12 -auto
Signed-off-by: Julien Isorce
---
src/mesa/drivers/dri/i965/intel_screen.c | 68 +++-
1 file cha
Ah yes you are right, my mistake. I will update the patch after some more
testing. Thx.
On 8 November 2017 at 17:21, Chris Wilson wrote:
> Quoting Julien Isorce (2017-11-08 16:55:05)
> > v2: add early return if (flag & MAP_INTERNAL_MASK)
> >
> > Already implem
v2: add early return if (flag & MAP_INTERNAL_MASK)
Already implemented for Gallium drivers.
Useful for gbm_bo_(un)map.
Tested by porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
Signed-off-by: Julien Isorce
---
src/mesa/drivers/dri/i965/intel_screen.c
Already implemented for Gallium drivers.
Useful for gbm_bo_(un)map.
Tested by porting wayland/weston/clients/simple-dmabuf-drm.c to GBM.
Signed-off-by: Julien Isorce
---
src/mesa/drivers/dri/i965/intel_screen.c | 47 ++--
1 file changed, 45 insertions(+), 2
Hi,
This issue is tracked here https://bugs.freedesktop.org/s
how_bug.cgi?id=98285
This is due to a limitation in libva API which only supports 1 FD per
VaSurface.
It is enough for intel-driver because NV12 is only 1 bo. But in nouveau
driver, NV12 is 2 separates bo (omitting the interlaced pb).
pen()s the EGL and tries to export the eglImage into a dma_buf handle.
>
> No idea how to do this, but I'm pretty sure somebody on the mailing list
> should know the details how this can be solved.
>
> Regards,
> Christian.
>
>
> Am 13.07.2017 um 14:26 schrieb Julien I
>> Reviewed-and-Tested-by: Julien Isorce
>>
>
> Acked-by: Christian König
>
> Any objections that I push this one to master preliminary?
>
> Regards,
> Christian.
>
>
> ---
>> configure.ac | 49 +-
>>
compile empty source (target.c) for now.
>>>
>>> v2: Show error message when --enable-omx is used (Christian)
>>> Use single PKG_CHECK_MODULES for omx_tizonia checks (Emil)
>>> Use spaces instead of tabs
>>> Add checks aro
ts and
>> confirmed that patch works fine.
>>
>> Regards,
>> Boyuan
>>
>> -Original Message-
>> From: Liu, Leo
>> Sent: July-26-17 12:01 PM
>> To: Andy Furniss; Koenig, Christian; Julien Isorce;
>> mesa-dev@lists.freedesktop.o
The picture_is was assumed to be a frame number so in 0-31.
But the vaapi client gstreamer-vaapi uses the surfaces handles
as identifier which are unsigned int.
This bug can happen when using a lot of vaapi surfaces within
the same process. Indeed Mesa/st/va increments a counter for the
surface ID
Hi,
With Gurkirpal we have been blocked on this problem last week and that
would be great to get some input.
It is not really urgent because Gurkirpal switched to the encoder work for
the time being.
So the goal is from src/gallium/state_trackers/omx, to find a way to
retrieve the underlying stru
Reviewed-by: Julien Isorce
On 5 April 2017 at 20:03, Edmondo Tommasina
wrote:
> Flush the HUD value streams to the dump files after every newline.
>
> v2: check that fopen succeeded (Julien)
>
> Tested-by: Julien Isorce
> ---
> src/gallium/auxiliary/hud/hud_conte
I confirm it works, awesome! Thx!
Should you check that fopen succeeded ? because I think setvbuf would
crash otherwise.
That's said:
Tested-by: Julien Isorce
On 4 April 2017 at 21:52, Edmondo Tommasina
wrote:
> Flush the HUD value streams to the dump files after every newline.
>
, 2017 11:26, "Julien Isorce" wrote:
>
> Hi,
>
> I noticed that GALLIUM_HUD does not write hud values into files properly.
>
> The destination files look empty at least for 5 min and then are filed in
> with some burst. I wonder if it could be a problem with the
> G
Hi,
I noticed that GALLIUM_HUD does not write hud values into files properly.
The destination files look empty at least for 5 min and then are filed in
with some burst. I wonder if it could be a problem with the
GALLIUM_HUD_PERIOD which would be wrong when writing values into files. Or
write is n
Oops it should be just "return;" here.
On 28 March 2017 at 17:52, Julien Isorce wrote:
> - if (program->input_size || program->ir_type ==
> PIPE_SHADER_IR_NATIVE)
> - si_upload_compute_input(sctx, code_object, info);
> +
d_compute_input(sctx, code_object, info))) {
+ return false;
+ }
is the indentation ok ?
On 27 March 2017 at 16:39, Marek Olšák wrote:
> "&&" at the end of the previous line please.
>
> Reviewed-by: Marek Olšák
>
> Marek
>
> On Mon, Mar 27,
Signed-off-by: Julien Isorce
---
src/mesa/state_tracker/st_cb_bitmap.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index b2e2608..cf820e4 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa
by doing
a silent check. But defer fprintf where the error comes from, libdrm calls.
Signed-off-by: Julien Isorce
---
src/gallium/drivers/r600/r600_state_common.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600
Signed-off-by: Julien Isorce
---
src/gallium/drivers/radeonsi/si_compute.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 46476b6..a38138f 100644
--- a/src/gallium
s it really
> should be...), I think we should have an fprintf to stderr.
>
> Cheers,
> Nicolai
>
> On 24.03.2017 12:08, Julien Isorce wrote:
>
>> Like done in si_state_draw.c::si_draw_vbo
>>
>> Signed-off-by: Julien Isorce
>> ---
>> src/galliu
Signed-off-by: Julien Isorce
---
src/gallium/drivers/radeonsi/si_compute.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 19a9189..e3ccc55 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
Signed-off-by: Julien Isorce
---
src/mesa/state_tracker/st_cb_bitmap.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index b2e2608..3ce190e 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa
Signed-off-by: Julien Isorce
---
src/gallium/drivers/r600/r600_state.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_state.c
b/src/gallium/drivers/r600/r600_state.c
index 6139bd2..9ca113a 100644
--- a/src/gallium/drivers/r600/r600_state.c
+++ b
Like done in si_state_draw.c::si_draw_vbo
Signed-off-by: Julien Isorce
---
src/gallium/drivers/r600/r600_state_common.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/drivers/r600/r600_state_common.c
b/src/gallium/drivers/r600/r600_state_common.c
index 6f8279f..cedeb74
Introduced by ad13bd2e51a5dc01b0f8a0eb927022f0deac0a0c
Signed-off-by: Julien Isorce
---
src/gallium/drivers/r600/r600_shader.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index
Should I remove
https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/radeonsi/si_pipe.c#n687
then ? (if (!sscreen) return;)
On 20 March 2017 at 15:29, Marek Olšák wrote:
> NAK. sscreen is never NULL here.
>
> Marek
>
> On Thu, Mar 16, 2017 at 3:25 PM, Julien
CID 1313492
Signed-off-by: Julien Isorce
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
index f4ed3ce..f6d5c8a 100644
Few lines before there is a if (zstex && zstex->htile_buffer ...)
which tells that there are some situation where it can be NULL.
So let's check for its nullity in other places too. Spotted by
coverity:
CID 1237295
Signed-off-by: Julien Isorce
---
src/gallium/drivers/radeon
CID 1399479: Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking velems suggests that it may be null,
but it has already been dereferenced on all paths leading to the check.
Signed-off-by: Julien Isorce
---
src/gallium/drivers/radeonsi/si_descriptors.c | 15
CID 1354483
Signed-off-by: Julien Isorce
---
src/gallium/drivers/radeonsi/si_pipe.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index a9a7c8f..6cbaa72 100644
--- a/src/gallium
Like done in another place in that same file.
Not sure if this should be an assert though.
CID 1250588
Signed-off-by: Julien Isorce
---
src/gallium/drivers/r600/r600_shader.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src
Like in a few other places in that radeon_drm_bo.c file.
CID 715739.
Signed-off-by: Julien Isorce
---
src/gallium/winsys/radeon/drm/radeon_drm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_bo.c
b/src/gallium/winsys/radeon/drm
it.
https://scan.coverity.com/projects/mesa/view_defects
Julien Isorce (6):
radeon: initialize hole variable before calling container_of
r600_shader.c: check validity of the value returned by
eg_get_interpolator_index
si_pipe: do not dereference sscreen before checking if it is NULL.
rad
Follow-up of patch:
"radeon_cs_create_fence: check null return from radeon_winsys_bo_create"
radeon_drm_cs_flush
radeon_cs_create_fence
radeon_winsys_bo_create
Signed-off-by: Julien Isorce
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 24 +---
1 file c
quite confident with the first patch but unsure with the 2 others for the
teardown parts.
Julien Isorce (3):
radeon_cs_create_fence: check null return from radeon_winsys_bo_create
radeon_drm_cs_flush: check null return from radeon_cs_create_fence
hud_context: check NULL return from u_upload_alloc
_flush radeon_drm_cs.c
Signed-off-by: Julien Isorce
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
b/src/gallium/winsys/radeon/drm/radeon_drm_cs.c
index d431bfc..1545fd8 100644
--- a/src/gallium/
Fixes the following segmentation fault:
signal SIGSEGV: invalid address (fault address: 0x0)
frame #0: 0x7fffe718e117 radeonsi_dri.so hud_draw_background_quad
hud_context.c:170
167
168 assert(hud->bg.num_vertices + 4 <= hud->bg.max_num_vertices);
169
-> 170 vertices[num++] =
Follow-up of patch:
"radeon_cs_create_fence: check null return from radeon_winsys_bo_create"
radeon_drm_cs_flush
radeon_cs_create_fence
radeon_winsys_bo_create
Signed-off-by: Julien Isorce
---
src/gallium/winsys/radeon/drm/radeon_drm_cs.c | 22 +++---
1 file c
Hi,
Since 2012 commit ccff74971203b533bf16b46b49a9e61753f75e6c it is said:
"sample must be initialized, or else the result is undefined" in the
description of mesa/src/util/list.h::container_of .
But I can find a few places where it is used without initializing that
second parameter, i.e. like:
Hi Christian,
I pushed it before already. I can try to add a git notes if you want.
In any case thx for the review.
Cheers
Julien
On 18 October 2016 at 10:09, Christian König
wrote:
> Am 17.10.2016 um 21:40 schrieb Julien Isorce:
>
>
>
> On Monday, 17 October 2016, Mark
On Monday, 17 October 2016, Mark Thompson wrote:
> On 17/10/16 17:33, Julien Isorce wrote:
> > As specified in va.h, default value should be set on attributes
> > not present in the input list.
> >
> > Signed-off-by: Julien Isorce >
> > ---
> > s
On 17 October 2016 at 16:27, Mark Thompson wrote:
> On 17/10/16 16:13, Julien Isorce wrote:
> > Hi Mark,
> >
> > Yes I actually saw that too in the intel driver though I think it does
> not add
> > VA_RT_FORMAT_RGB32 ? Or I missed something ?
> > Maybe th
As specified in va.h, default value should be set on attributes
not present in the input list.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/config.c | 9 +
src/gallium/state_trackers/va/surface.c | 5 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git
sed if the VAConfigRTFormat attribute is not
> > provided by the user.
> > ---
> > On 17/10/16 15:21, Julien Isorce wrote:
> >> Hi Mark,
> >>
> >> Thx for the patch. I can see it has already landed.
> >>
> >> I just tried it with gstre
Hi Mark,
Thx for the patch. I can see it has already landed.
I just tried it with gstreamer-vaapi and it causes problem since they
create the config like this for VPP:
va_status = vaCreateConfig (filter->va_display, VAProfileNone,
VAEntrypointVideoProc, NULL, 0, &filter->va_config);
As yo
On 16 September 2016 at 08:43, Christian König
wrote:
> Am 15.09.2016 um 23:07 schrieb Julien Isorce:
>
>
>
> On 15 September 2016 at 16:02, Leo Liu wrote:
>
>>
>>
>> On 09/15/2016 10:43 AM, Andy Furniss wrote:
>>
>>> Since bf901a2
>>&g
On 15 September 2016 at 16:02, Leo Liu wrote:
>
>
> On 09/15/2016 10:43 AM, Andy Furniss wrote:
>
>> Since bf901a2
>> st/va: also honors interlaced preference when providing a video format
>> existing scripts and most use cases will need true.
>>
>> Signed-off-by: Andy Furniss
>> ---
>> src/gal
This fixes a crash when using the prefered video format with vaapisink
on Nvidia hardwares.
Also caught by the following assert:
nouveau_vp3_video.c:91: Assertion `templat->interlaced' failed.
TEST= gst-launch-1.0 videotestsrc ! video/x-raw, format=NV12 ! vaapisink
Signed-off-by: Julie
No encoder with nouveau driver so I cannot do a tunneling test
but at least this does not break the decoder part so the 4 patches are:
Tested-by: Julien Isorce
Thx!
On 6 July 2016 at 19:03, Leo Liu wrote:
> The idea of encode tunneling is to use video buffer directly for encoder,
&g
It happens when trying to use omxh264enc with nouveau driver
because it does not provide any encoder at the moment.
It crashes on enc_ReleaseTasks(&priv->free_tasks) because
at this time the list is not initialized.
So this patch make sure the lists are initialized.
Another way to fix this would
Thx Leo.
I confirm it works with nouveau driver so your fix is:
Tested-by: Julien Isorce
On 28 June 2016 at 02:27, Liu, Leo wrote:
> Hi Julien and Christian,
>
>
> I got a patch attached to fix the "fillout" problem, and please review.
>
>
> But we still nee
it got seg fault. Will take look
> further.
>
> Regards,
> Leo
>
>
>
> On 06/27/2016 04:16 AM, Julien Isorce wrote:
>
>> Signed-off-by: Julien Isorce
>> ---
>> src/gallium/state_trackers/omx/vid_dec.c | 51
>> --
Interlaced can be true for nouveau driver.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/omx/vid_dec.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec.c
b/src/gallium/state_trackers/omx
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/omx/vid_dec.c | 51
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/src/gallium/state_trackers/omx/vid_dec.c
b/src/gallium/state_trackers/omx/vid_dec.c
index 564ca2f..85ffb88 100644
Used by nouveau driver.
Similar patch was done for st/va:
851e7e12aa628d6781b5a3af2f2fc16ee73f435f
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/omx/vid_dec_h264.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gallium/state_trackers/omx/vid_dec_h264.c
b/src/gallium
with Bellagio library on Desktop with gstomxh264dec plugin.
Julien Isorce (3):
st/omx: retrieve preferred interlaced and buffer_formats
st/omx: add support for nouveau / interlaced
st/omx: count number of slices
src/gallium/state_trackers/omx/vid_dec.c | 77
Thx for the patch:
Reviewed-by: Julien Isorce
I'll push it today.
On 26 June 2016 at 08:02, Gurkirpal Singh wrote:
> Call to handle_table_get in vlVaDestroySurfaces can
> return NULL on failure.
>
> CID: 1243522
>
> Signed-off-by: Gurkirpal Singh
> ---
>
On 15 June 2016 at 14:07, Christian König wrote:
> Please split that up into multiple parts. E.g. adding the config
> structure, new image format support etc..
>
> Julien, can you take a look as well if you have time and work a bit with
> Boyuan to get this cleaned up?
>
Hi,
I'll be happy to do
Hi,
It seems this patch has been pushed recently. This is causing me problems
on a multi gpu configuration.
It is a laptop with intel and nvidia, graphic hardwares.
1: intel vaapi driver:
vainfo
2: st/va,nouveau:
DRI_PRIME=1 LIBVA_DRIVER_NAME=gallium vainfo
with that patch 0c0f841e5de27d01312f8
: DRI_PRIME=1 gst-launch vaapidecodebin ! glimagesink
Signed-off-by: Julien Isorce
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 3 +++
src/gallium/include/pipe/p_video_codec.h | 1 +
src/gallium/state_trackers/va/surface.c| 8
3 files changed, 12 insertions(+)
diff --git a/src/gallium
just replace the specific "bool disable_tiling" by a
generic bind flag ?
On 8 June 2016 at 14:07, Christian König wrote:
> Am 08.06.2016 um 14:20 schrieb Julien Isorce:
>
>
>
> On 8 June 2016 at 09:16, Christian König wrote:
>
>> Am 02.06.2016 um 16:00 schr
On 8 June 2016 at 09:16, Christian König wrote:
> Am 02.06.2016 um 16:00 schrieb Julien Isorce:
>
>> In order to do zero-copy between two different devices
>> the memory should not be tiled.
>>
>> This is currently no way to set pipe_resource template's flag
wrote:
> Am 02.06.2016 um 16:03 schrieb Julien Isorce:
>
>> Signed-off-by: Julien Isorce
>>
>
> Actually I'm not sure if that is correct.
>
> If you release the VABuffer of an exported resource you won't be able to
> properly close the handle with vlVaRelea
Instead of changing the format on the existing template
which makes error handling not nice and confuses coverity.
CoverityID: 1337953
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/image.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/buffer.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/gallium/state_trackers/va/buffer.c
b/src/gallium/state_trackers/va/buffer.c
index 2fd8661..7d3167b 100644
--- a/src/gallium/state_trackers/va
set or not the flag:
VA_SURFACE_EXTBUF_DESC_ENABLE_TILING
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/surface.c | 60 -
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/va/surface.c
b/src/gallium/st
an.
> >
> > Am 31.05.2016 um 14:51 schrieb Christian König:
> > > Yeah, that solution looks more correct to me.
> > >
> > > Christian.
> > >
> > > Am 31.05.2016 um 14:44 schrieb Julien Isorce:
> > > > Hi,
> > > > Thx for lookin
Hi,
Thx for looking at it but are you sure your diff compiles ?
Can you try this instead:
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -471,19 +471,19 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID
surface, VAImageID image,
if (format != surf-
Reviewed-by: Julien Isorce
I'll push it shortly. Thx
On 12 April 2016 at 23:24, Iurie Salomov wrote:
> From: iurie salomov
>
> Signed-off-by: Iurie Salomov
> ---
> src/gallium/state_trackers/va/context.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
On 12 April 2016 at 14:27, iurie wrote:
It should be "Firstname Lastname" , click on any commit here
https://cgit.freedesktop.org/mesa/mesa/log/ to compare or just type: git log
It is a common practice for most open source projects and sometimes a
requirement. Not sure if this is strictly require
On 11 April 2016 at 22:24, Iurie wrote:
> From d6a5bbd910dc19d4863dbac8eba5bdf07bd1c3ab Mon Sep 17 00:00:00 2001
> From: GreatMaster
>
Please put your real name and add signed-off stamp: *git config --global
user*.name "FirstName LastName"
Then run : git commit --amend --reset-author --no-edit
Hi Thomas and Emil, I tested it and pushed. Thx a lot.
On 6 April 2016 at 21:34, Thomas H.P. Andersen wrote:
>
>
> On Sun, Mar 6, 2016 at 10:08 AM, Thomas H.P. Andersen
> wrote:
>
>>
>>
>> On Sat, Mar 5, 2016 at 1:30 PM, Emil Velikov
>> wrote:
>>
>>> Hi Thomas,
>>>
>>> On 5 March 2016 at 12:07
Hi Lurie,
Thx for your interest.
In order to work on this project you would need either a AMD or NVIDIA
graphic hardware. Indeed current st/omx in Gallium, only work with these 2
hardwares and it would be out of scope of the project to add support for
another hardware.
In order to check that you
From: Julien Isorce
The counter was not set but used by the nouveau driver.
It is required otherwise visual output is garbage.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/picture.c| 8
src/gallium/state_trackers/va/picture_h264.c | 2 ++
src/gallium
On 23 December 2015 at 09:42, Christian König
wrote:
> On 23.12.2015 10:28, Julien Isorce wrote:
>
>> The counter was not set but used by the driver.
>> It is required otherwise visual output is garbage.
>>
>> Signed-off-by: Julien Isorce
>>
>
> One
The counter was not set but used by the driver.
It is required otherwise visual output is garbage.
Signed-off-by: Julien Isorce
---
src/gallium/state_trackers/va/picture.c| 22 ++
src/gallium/state_trackers/va/picture_h264.c | 2 ++
src/gallium/state_trackers/va
It allows to call nouveau_vp3_bsp_next multiple times
between one begin/end.
It is required to support st/va.
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h| 16 +++-
.../drivers/nouveau
- split nvc0_decoder_bsp in begin/next/end
- preserve content buffer when calling nvc0_decoder_bsp_next
- implement pipe_video_codec::begin_frame/end_frame
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nvc0/nvc0_video.c
On 17 December 2015 at 04:02, Ilia Mirkin wrote:
> On Wed, Dec 16, 2015 at 9:39 AM, Julien Isorce
> wrote:
> > It allows to call nouveau_vp3_bsp_next multiple times
> > between one begin/end.
> >
> > It is required to support st/va.
> >
> > https://
> On Wed, Dec 16, 2015 at 9:40 AM, Julien Isorce
> wrote:
> > https://bugs.freedesktop.org/show_bug.cgi?id=89969
> >
> > Signed-off-by: Julien Isorce
> > ---
> > src/gallium/drivers/nouveau/nouveau_vp3_video.h | 3 +++
> > src/gallium/drivers/nouveau
On 17 December 2015 at 04:13, Ilia Mirkin wrote:
> On Wed, Dec 16, 2015 at 9:39 AM, Julien Isorce
> wrote:
> > - split nvc0_decoder_bsp in begin/next/end
> > - preserve content buffer when calling nvc0_decoder_bsp_next
> > - implement pipe_video_codec::begin_frame
On 21 December 2015 at 15:10, Christian König
wrote:
> On 21.12.2015 11:05, Andy Furniss wrote:
>
>> Julien Isorce wrote:
>>
>>> Hi Christian,
>>>
>>> I have 2 remarks:
>>>
>>> 1: I am sure you have the clear answer to the follow
unref before you
continue to access it)
(Also I cannot see any lock/unlock in vlVaQueryVideoProcPipelineCaps)
Otherwise this patch is:
Reviewed-by: Julien Isorce
Tested-by: Julien Isorce
Cheers
Julien
On 18 December 2015 at 15:08, Emil Velikov wrote:
> Hi Christian,
>
> I'v
: VAEntrypointVLD
VAProfileVC1Main: VAEntrypointVLD
VAProfileVC1Advanced: VAEntrypointVLD
VAProfileH264Baseline : VAEntrypointVLD
VAProfileH264Main : VAEntrypointVLD
VAProfileH264High : VAEntrypointVLD
Signed-o
- split nvc0_decoder_bsp in begin/next/end
- preserve content buffer when calling nvc0_decoder_bsp_next
- implement pipe_video_codec::begin_frame/end_frame
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h | 3 +++
src/gallium/drivers/nouveau/nouveau_vp3_video_bsp.c | 17 +++--
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/src
test it.
Ilia Mirkin suggested to do it afterward.
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Julien Isorce (4):
nouveau: split nouveau_vp3_bsp in begin/next/end
nvc0: add support for st/va
nouveau: fix chunk decoding by updating number of slices
build: enable st/va with nouveau
It allows to call nouveau_vp3_bsp_next multiple times
between one begin/end.
It is required to support st/va.
https://bugs.freedesktop.org/show_bug.cgi?id=89969
Signed-off-by: Julien Isorce
---
src/gallium/drivers/nouveau/nouveau_vp3_video.h| 16 +++-
.../drivers/nouveau
aBuffer, so not possible to do that.
But in any case I think you are right we should not need thsi flush at all
so I am ok that you remove this flush. The problem should be elsewhere.
So with your v2 + my change in vlVaAcquireBufferHandle,
This patch is:
Reviewed-by: Julien Isorce
Tested-by
1 - 100 of 262 matches
Mail list logo
