Re: [Mesa-dev] Can't get OpenGL 3.x inside VMware Workstation 12 (Ubuntu guest)
On 11/11/2015 07:07 PM, Brian Paul wrote: > On 11/11/2015 10:44 AM, Emil Velikov wrote: >> On 11 November 2015 at 16:48, Brian Paul wrote: >>> On 11/11/2015 08:44 AM, Emil Velikov wrote: >> I have seen similar type of documents in the past, most of which going out of date very quickly due to distribution changes and/or others. Wondering how you'll feel about "check your distro and add svga to the gallium-drivers array" style of instructions ? >>> >>> >>> I'm afraid I don't quite understand what you're saying there. Can you >>> elaborate? >>> >>> >> Rather than walking through the requirements, configure and make/make >> install steps, just forward people to the distro specific wiki on "how >> to build mesa/kernel" and explicitly mention the differences: >> mesa: >> - XA must be enabled: --enable-xa >> - svga must be listed in the gallium drivers: >> --with-gallium-drivers=svga... >> >> kernel: >> - Set DRM_VMWGFX >> >> others... > > I guess I've never seen those wikis. I'd have to search for them, but > I really don't have the time now. > > We actually have an in-house shell script that installs all the > pre-req packages, pulls the git trees, builds and installs for a > variety of guest OSes. But it has some VMware-specific stuff that I'd > have to trim out before making public. > > >> >> Related: does the upstream [1] vmwgfx module work well when combined >> with upstream core drm across different versions ? Considering how >> well Thomas is handling upstreaming shouldn't the module from the >> kernel be recommended ? > > Either should be fine at this point but the build instructions cover > the case of one having an older distro that may not have the > GL3-enabled kernel module already. > The upstream[1] vmwgfx module should work well with any linux kernel dating back to 2.6.32 unless the distro has changed the kernel API from the base version. It ships with builtin stripped drm and ttm to handle compatibility issues, and is intended for people (mostly including ourselves and our QA team) that want to try out new features without installing a completely new kernel. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Can't get OpenGL 3.x inside VMware Workstation 12 (Ubuntu guest)
On 11/11/2015 08:51 PM, Brian Paul wrote: > On 11/11/2015 11:38 AM, Emil Velikov wrote: >> On 11 November 2015 at 18:25, Thomas Hellstrom >> wrote: >>> On 11/11/2015 07:07 PM, Brian Paul wrote: >>>> On 11/11/2015 10:44 AM, Emil Velikov wrote: >>>>> On 11 November 2015 at 16:48, Brian Paul wrote: >>>>>> On 11/11/2015 08:44 AM, Emil Velikov wrote: >>>>> >>>>>>> >>>>>>> I have seen similar type of documents in the past, most of which >>>>>>> going >>>>>>> out of date very quickly due to distribution changes and/or others. >>>>>>> Wondering how you'll feel about "check your distro and add svga >>>>>>> to the >>>>>>> gallium-drivers array" style of instructions ? >>>>>> >>>>>> >>>>>> I'm afraid I don't quite understand what you're saying there. >>>>>> Can you >>>>>> elaborate? >>>>>> >>>>>> >>>>> Rather than walking through the requirements, configure and make/make >>>>> install steps, just forward people to the distro specific wiki on >>>>> "how >>>>> to build mesa/kernel" and explicitly mention the differences: >>>>> mesa: >>>>> - XA must be enabled: --enable-xa >>>>> - svga must be listed in the gallium drivers: >>>>> --with-gallium-drivers=svga... >>>>> >>>>> kernel: >>>>>- Set DRM_VMWGFX >>>>> >>>>> others... >>>> >>>> I guess I've never seen those wikis. I'd have to search for them, but >>>> I really don't have the time now. >>>> >>>> We actually have an in-house shell script that installs all the >>>> pre-req packages, pulls the git trees, builds and installs for a >>>> variety of guest OSes. But it has some VMware-specific stuff that I'd >>>> have to trim out before making public. >>>> >>>> >>>>> >>>>> Related: does the upstream [1] vmwgfx module work well when combined >>>>> with upstream core drm across different versions ? Considering how >>>>> well Thomas is handling upstreaming shouldn't the module from the >>>>> kernel be recommended ? >>>> >>>> Either should be fine at this point but the build instructions cover >>>> the case of one having an older distro that may not have the >>>> GL3-enabled kernel module already. >>>> >>> >>> The upstream[1] vmwgfx module should work well with any linux kernel >>> dating back to 2.6.32 unless the distro has changed the kernel API from >>> the base version. It ships with builtin stripped drm and ttm to handle >>> compatibility issues, and is intended for people (mostly including >>> ourselves and our QA team) that want to try out new features without >>> installing a completely new kernel. >>> >> Ok seems that my point is too subtle, so I'll try from another angle. >> >> The wiki instructions say "nuke he vmwgfx.ko module" and implicitly >> "keep drm.ko". If we ignore the unlikely cases where either one and/or >> both is built-in, we can have a case where the new vmwgfx is build >> against core drm from the upstream, yet the downstream drm module >> is/gets loaded. As core drm often goes through various changes, you >> can see how bad things are likely to happen. > Actually they are unlikely to happen since this scenario was taken into account when the standalone vmwgfx module was designed, and unless we have a bug it should be safe (I've seen two duplicate TTM symbols exported in 3.19, but that's cosmetic only until another TTM aware driver is loaded, which is currently not likely). When built, only internal drm / ttm headers are used, no internal drm or ttm symbols are exported (except as stated above) and all drm and ttm references are internally resolved except two, namely those that allow binding to core drm's sysfs, so that the driver's sysfs interface shows up where it should; among other things for Mir compatibility. It's true that if these two single DRM functions change their interface, we need to handle that, but that's a small interface to watch over; The driver is simply designed to interoperate with core drm and TTM. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] vdpau_interop extension oddities
Hi, Christian, I'm looking through the mesa vdpau interop code and found something that looks strange to me: (dmabuf part) For video surfaces, it looks like vdpau exports a handle to a 2D_ARRAY texture. Later in the mesa state tracker, that handle is used to back a "fake" single slice 2D texture from which we create views like if it were an array texture, using the layer_override. I guess this would cause numerous problems when trying to render to these textures or using texSubImage etc. Wouldn't the correct solution be to have vdpau export a single layer of the array texture (using the whandle offset pointing to the layer start) which is then reinterpreted by the driver, not the state tracker, as a true non-array texture. And if for some reason the driver doesn't support reinterpreting and offseting like this wouldn't it be possible to hide the layer_override inside the driver for surface, sampler_view and transfer object purposes, as part of the texture internal format? Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] vdpau_interop extension oddities
Hi, Christian! Thanks for your reply. I'll look through the code again! /Thomas On 02/01/2017 04:22 PM, Christian König wrote: > Hi Thomas, > > I'm on sick leave, but will try to quickly answer your questions. > > But don't be disappointed if you don't hear back from me before Monday. > > Am 01.02.2017 um 15:56 schrieb Thomas Hellstrom: >> Hi, Christian, >> >> I'm looking through the mesa vdpau interop code and found something that >> looks strange to me: >> >> (dmabuf part) >> >> For video surfaces, it looks like vdpau exports a handle to a 2D_ARRAY >> texture. >> Later in the mesa state tracker, that handle is used to back a "fake" >> single slice 2D texture from which we create views like if it were an >> array texture, using the layer_override. I guess this would cause >> numerous problems when trying to render to these textures or using >> texSubImage etc. > > Hui? That's not how I remembered it. > > For the dma-buf part we export one layer of a 2D_ARRAY texture and > then import that as "normal" 2D texture. > > The layer_override is only for the old code path used by Nouveau, e.g. > exporting the pipe objects directly and then access only a certain layer. > >> Wouldn't the correct solution be to have vdpau export a single layer of >> the array texture (using the whandle offset pointing to the layer start) >> which is then reinterpreted by the driver, not the state tracker, as a >> true non-array texture. > > Actually that is exactly as it should be, yes. > >> And if for some reason the driver doesn't support reinterpreting and >> offseting like this wouldn't it be possible to hide the layer_override >> inside the driver for surface, sampler_view and transfer object >> purposes, as part of the texture internal format? > > As noted above the layer_override should only be used for the old code > path. > > Could be that we accidentally set layer_override in the new code path > as well, but that would clearly be a bug. > > Regards, > Christian. > >> >> Thanks, >> >> Thomas >> >> >> >> >> ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] vdpau_interop extension oddities
Hi, Again, (No need answering while on sick leave!). On 02/01/2017 04:39 PM, Thomas Hellstrom wrote: > Hi, Christian! > > Thanks for your reply. I'll look through the code again! > > /Thomas > > > On 02/01/2017 04:22 PM, Christian König wrote: >> Hi Thomas, >> >> I'm on sick leave, but will try to quickly answer your questions. >> >> But don't be disappointed if you don't hear back from me before Monday. >> >> Am 01.02.2017 um 15:56 schrieb Thomas Hellstrom: >>> Hi, Christian, >>> >>> I'm looking through the mesa vdpau interop code and found something that >>> looks strange to me: >>> >>> (dmabuf part) >>> >>> For video surfaces, it looks like vdpau exports a handle to a 2D_ARRAY >>> texture. >>> Later in the mesa state tracker, that handle is used to back a "fake" >>> single slice 2D texture from which we create views like if it were an >>> array texture, using the layer_override. I guess this would cause >>> numerous problems when trying to render to these textures or using >>> texSubImage etc. >> Hui? That's not how I remembered it. >> >> For the dma-buf part we export one layer of a 2D_ARRAY texture and >> then import that as "normal" 2D texture. Here it looks like we always export the first layer... whandle.layer = surf->u.tex.first_layer; (vdpau / surface.c) should be whandle.layer = surf->u.tex.first_layer + ( plane & 1); >> >> The layer_override is only for the old code path used by Nouveau, e.g. >> exporting the pipe objects directly and then access only a certain layer. You're right. The layer override is only active for the old code path. So if I understand correctly the end result would be that both field textures are identical? /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] vdpau_interop extension oddities
On 02/01/2017 04:54 PM, Christian König wrote: > Am 01.02.2017 um 16:50 schrieb Thomas Hellstrom: >> Hi, Again, >> >> (No need answering while on sick leave!). > > Actually I'm bored, but can't concentrate on coding when my body > temperature isn't in the normal range :( > >>>> Hui? That's not how I remembered it. >>>> >>>> For the dma-buf part we export one layer of a 2D_ARRAY texture and >>>> then import that as "normal" 2D texture. >> Here it looks like we always export the first layer... >> >> whandle.layer = surf->u.tex.first_layer; (vdpau / surface.c) > > If I remember correctly surf is selected based on plane and so > surf->u.tex.first_layer should be either 0 or 1 anyway. > Ah. You're right. I misread tex.first_layer as being the first layer in the texture. Not the surface first layer. Thanks for the explanation! Thomas > Regards, > Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 0/8] gallium: A number of video code fixes
A couple of fixes / improvements for things I've encountered while looking through and testing the video code in preparation for a virtual hardware video driver. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/8] gallium/vl Fix brightness matrix description
The brightness matrix doesn't actually match the procamp matrix and what's calculated in vl_csc_get_matrix. Signed-off-by: Thomas Hellstrom Reviewed-by: Sinclair Yeh --- src/gallium/auxiliary/vl/vl_csc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/gallium/auxiliary/vl/vl_csc.c b/src/gallium/auxiliary/vl/vl_csc.c index c8efe28..1587e6c 100644 --- a/src/gallium/auxiliary/vl/vl_csc.c +++ b/src/gallium/auxiliary/vl/vl_csc.c @@ -59,10 +59,10 @@ * [ 0, 0, 0, 1] * * brightness - * [ 1, 0, 0, b] - * [ 0, 1, 0, 0] - * [ 0, 0, 1, 0] - * [ 0, 0, 0, 1] + * [ 1, 0, 0, b/c] + * [ 0, 1, 0, 0] + * [ 0, 0, 1, 0] + * [ 0, 0, 0, 1] * * saturation * [ 1, 0, 0, 0] -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/8] gallium/vl: Don't map vertex buffers on creation
It will cause multiple simultaneous maps of the same vertex buffer and flushed-while-mapped warnings. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- src/gallium/auxiliary/vl/vl_vertex_buffers.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/gallium/auxiliary/vl/vl_vertex_buffers.c b/src/gallium/auxiliary/vl/vl_vertex_buffers.c index 13d3f8c..1721227 100644 --- a/src/gallium/auxiliary/vl/vl_vertex_buffers.c +++ b/src/gallium/auxiliary/vl/vl_vertex_buffers.c @@ -241,7 +241,6 @@ vl_vb_init(struct vl_vertex_buffer *buffer, struct pipe_context *pipe, goto error_mv; } - vl_vb_map(buffer, pipe); return true; error_mv: -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/8] gallium/vl: Simplify usage of full range matrices
When looking at the full range matrices, it becomes obvious that the difference
between the standard matrices and the full range matrices is that the full
range matrices are multiplied by 1.164. Together with offsetting the y value
with -16/255, this will scale and offset RGB with the desired quantities.
However, the standard SMPTE 240M matrix seems to differ a bit since the
U and V coefficients are only multiplied with 1.138 to get the full range
matrix. This would actually alter the color somewhat so I figure that's an
error. The full range matrix is consistent with Nvidia's VDPAU implementation.
We can also incorporate the ybias in the brightness simplifying the
calculation somewhat.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
src/gallium/auxiliary/vl/vl_csc.c | 55 ---
1 file changed, 17 insertions(+), 38 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_csc.c
b/src/gallium/auxiliary/vl/vl_csc.c
index 1587e6c..d70ab14 100644
--- a/src/gallium/auxiliary/vl/vl_csc.c
+++ b/src/gallium/auxiliary/vl/vl_csc.c
@@ -108,18 +108,6 @@ static const vl_csc_matrix bt_601 =
};
/*
- * Converts ITU-R BT.601 YCbCr pixels to RGB pixels where:
- * Y is in [16,235], Cb and Cr are in [16,240]
- * R, G, and B are in [0,255]
- */
-static const vl_csc_matrix bt_601_full =
-{
- { 1.164f, 0.0f,1.596f, 0.0f, },
- { 1.164f, -0.391f, -0.813f, 0.0f, },
- { 1.164f, 2.018f, 0.0f, 0.0f, }
-};
-
-/*
* Converts ITU-R BT.709 YCbCr pixels to RGB pixels where:
* Y is in [16,235], Cb and Cr are in [16,240]
* R, G, and B are in [16,235]
@@ -132,29 +120,15 @@ static const vl_csc_matrix bt_709 =
};
/*
- * Converts ITU-R BT.709 YCbCr pixels to RGB pixels where:
+ * Converts SMPTE 240M YCbCr pixels to RGB pixels where:
* Y is in [16,235], Cb and Cr are in [16,240]
- * R, G, and B are in [0,255]
+ * R, G, and B are in [16,235]
*/
-static const vl_csc_matrix bt_709_full =
-{
- { 1.164f, 0.0f,1.793f, 0.0f, },
- { 1.164f, -0.213f, -0.534f, 0.0f, },
- { 1.164f, 2.115f, 0.0f, 0.0f, }
-};
-
static const vl_csc_matrix smpte240m =
{
- { 1.0f, 0.0f,1.582f, 0.0f, },
- { 1.0f, -0.228f, -0.478f, 0.0f, },
- { 1.0f, 1.833f, 0.0f, 0.0f, }
-};
-
-static const vl_csc_matrix smpte240m_full =
-{
- { 1.164f, 0.0f,1.794f, 0.0f, },
- { 1.164f, -0.258f, -0.543f, 0.0f, },
- { 1.164f, 2.079f, 0.0f, 0.0f, }
+ { 1.0f, 0.0f,1.541f, 0.0f, },
+ { 1.0f, -0.221f, -0.466f, 0.0f, },
+ { 1.0f, 1.785f, 0.0f, 0.0f, }
};
static const vl_csc_matrix identity =
@@ -176,7 +150,6 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
bool full_range,
vl_csc_matrix *matrix)
{
- float ybias = full_range ? -16.0f/255.0f : 0.0f;
float cbbias = -128.0f/255.0f;
float crbias = -128.0f/255.0f;
@@ -188,17 +161,23 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
const vl_csc_matrix *cstd;
+ if (full_range) {
+ c *= 1.164f; /* Adjust for the y range */
+ b *= 1.164f; /* Adjust for the y range */
+ b -= c * 16.0f / 255.0f; /* Adjust for the y bias */
+ }
+
assert(matrix);
switch (cs) {
case VL_CSC_COLOR_STANDARD_BT_601:
- cstd = full_range ? &bt_601_full : &bt_601;
+ cstd = &bt_601;
break;
case VL_CSC_COLOR_STANDARD_BT_709:
- cstd = full_range ? &bt_709_full : &bt_709;
+ cstd = &bt_709;
break;
case VL_CSC_COLOR_STANDARD_SMPTE_240M:
- cstd = full_range ? &smpte240m_full : &smpte240m;
+ cstd = &smpte240m;
break;
case VL_CSC_COLOR_STANDARD_IDENTITY:
default:
@@ -210,21 +189,21 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
(*matrix)[0][0] = c * (*cstd)[0][0];
(*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s *
sinf(h);
(*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s *
sinf(h);
- (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * (b + c * ybias) +
+ (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * b +
(*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
(*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
(*matrix)[1][0] = c * (*cstd)[1][0];
(*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s *
sinf(h);
(*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s *
sinf(h);
- (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * (b + c * ybias) +
+ (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * b +
(*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
(*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
(*matrix)[2][0] = c * (*cstd)[2][0];
(*matri
[Mesa-dev] [PATCH 7/8] st/vdpau: Fix multithreading
The vdpau state tracker allows multiple threads access to the same gallium
context simultaneously. We can fix this either by locking the same mutex
each time the context is used or by using a different gallium context for
each mutex domain. Here we do the latter, although I'm not sure that's really
the best option.
Signed-off-by: Thomas Hellstrom
Acked-by: Sinclair Yeh
---
src/gallium/state_trackers/vdpau/decode.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/vdpau/decode.c
b/src/gallium/state_trackers/vdpau/decode.c
index f85bce8..2a07d17 100644
--- a/src/gallium/state_trackers/vdpau/decode.c
+++ b/src/gallium/state_trackers/vdpau/decode.c
@@ -68,7 +68,6 @@ vlVdpDecoderCreate(VdpDevice device,
if (!dev)
return VDP_STATUS_INVALID_HANDLE;
- pipe = dev->context;
screen = dev->vscreen->pscreen;
pipe_mutex_lock(dev->mutex);
@@ -123,6 +122,12 @@ vlVdpDecoderCreate(VdpDevice device,
templat.level = u_get_h264_level(templat.width, templat.height,
&templat.max_references);
+ pipe = screen->context_create(screen, dev->vscreen, 0);
+ if (!pipe) {
+ ret = VDP_STATUS_RESOURCES;
+ goto error_context;
+ }
+
vldecoder->decoder = pipe->create_video_codec(pipe, &templat);
if (!vldecoder->decoder) {
@@ -145,6 +150,8 @@ error_handle:
vldecoder->decoder->destroy(vldecoder->decoder);
error_decoder:
+ pipe->destroy(pipe);
+error_context:
pipe_mutex_unlock(dev->mutex);
DeviceReference(&vldecoder->device, NULL);
FREE(vldecoder);
@@ -158,15 +165,18 @@ VdpStatus
vlVdpDecoderDestroy(VdpDecoder decoder)
{
vlVdpDecoder *vldecoder;
+ struct pipe_context *pipe;
vldecoder = (vlVdpDecoder *)vlGetDataHTAB(decoder);
if (!vldecoder)
return VDP_STATUS_INVALID_HANDLE;
+ pipe = vldecoder->decoder->context;
pipe_mutex_lock(vldecoder->mutex);
vldecoder->decoder->destroy(vldecoder->decoder);
pipe_mutex_unlock(vldecoder->mutex);
pipe_mutex_destroy(vldecoder->mutex);
+ pipe->destroy(pipe);
vlRemoveDataHTAB(decoder);
DeviceReference(&vldecoder->device, NULL);
@@ -674,10 +684,20 @@ vlVdpDecoderRender(VdpDecoder decoder,
if (ret != VDP_STATUS_OK)
return ret;
+ /*
+* Since we use separate contexts for the two mutex domains, we need
+* to flush to make sure rendering operations happen in order.
+* In particular, so that a frame is rendered before it is presented.
+*/
+ pipe_mutex_lock(vldecoder->device->mutex);
+ vldecoder->device->context->flush(vldecoder->device->context, NULL, 0);
+ pipe_mutex_unlock(vldecoder->device->mutex);
+
pipe_mutex_lock(vldecoder->mutex);
dec->begin_frame(dec, vlsurf->video_buffer, &desc.base);
dec->decode_bitstream(dec, vlsurf->video_buffer, &desc.base,
bitstream_buffer_count, buffers, sizes);
dec->end_frame(dec, vlsurf->video_buffer, &desc.base);
+ dec->flush(dec);
pipe_mutex_unlock(vldecoder->mutex);
return ret;
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/8] gallium/vl: Parameter substitution in the csc matrix computation
Makes the code significantly more readable.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
src/gallium/auxiliary/vl/vl_csc.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_csc.c
b/src/gallium/auxiliary/vl/vl_csc.c
index d70ab14..e4395d0 100644
--- a/src/gallium/auxiliary/vl/vl_csc.c
+++ b/src/gallium/auxiliary/vl/vl_csc.c
@@ -158,6 +158,7 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
float s = p->saturation;
float b = p->brightness;
float h = p->hue;
+ float x, y;
const vl_csc_matrix *cstd;
@@ -167,6 +168,10 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
b -= c * 16.0f / 255.0f; /* Adjust for the y bias */
}
+ /* Parameter substitutions */
+ x = c * s * cosf(h);
+ y = c * s * sinf(h);
+
assert(matrix);
switch (cs) {
@@ -187,23 +192,23 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
}
(*matrix)[0][0] = c * (*cstd)[0][0];
- (*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s *
sinf(h);
- (*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s *
sinf(h);
+ (*matrix)[0][1] = (*cstd)[0][1] * x - (*cstd)[0][2] * y;
+ (*matrix)[0][2] = (*cstd)[0][2] * x + (*cstd)[0][1] * y;
(*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * b +
- (*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*cstd)[0][1] * (x * cbbias + y * crbias) +
+ (*cstd)[0][2] * (x * crbias - y * cbbias);
(*matrix)[1][0] = c * (*cstd)[1][0];
- (*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s *
sinf(h);
- (*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s *
sinf(h);
+ (*matrix)[1][1] = (*cstd)[1][1] * x - (*cstd)[1][2] * y;
+ (*matrix)[1][2] = (*cstd)[1][2] * x + (*cstd)[1][1] * y;
(*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * b +
- (*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*cstd)[1][1] * (x * cbbias + y * crbias) +
+ (*cstd)[1][2] * (x * crbias - y * cbbias);
(*matrix)[2][0] = c * (*cstd)[2][0];
- (*matrix)[2][1] = c * (*cstd)[2][1] * s * cosf(h) - c * (*cstd)[2][2] * s *
sinf(h);
- (*matrix)[2][2] = c * (*cstd)[2][2] * s * cosf(h) + c * (*cstd)[2][1] * s *
sinf(h);
+ (*matrix)[2][1] = (*cstd)[2][1] * x - (*cstd)[2][2] * y;
+ (*matrix)[2][2] = (*cstd)[2][2] * x + (*cstd)[2][1] * y;
(*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * b +
- (*cstd)[2][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[2][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*cstd)[2][1] * (x * cbbias + y * crbias) +
+ (*cstd)[2][2] * (x * crbias - y * cbbias);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/8] gallium/vl: Add sampler views to video filter fragment shaders
Needed for at least the svga driver. Signed-off-by: Thomas Hellstrom Reviewed-by: Brian Paul --- src/gallium/auxiliary/vl/vl_bicubic_filter.c | 5 + src/gallium/auxiliary/vl/vl_matrix_filter.c | 5 + src/gallium/auxiliary/vl/vl_median_filter.c | 5 + 3 files changed, 15 insertions(+) diff --git a/src/gallium/auxiliary/vl/vl_bicubic_filter.c b/src/gallium/auxiliary/vl/vl_bicubic_filter.c index 570f153..ae29208 100644 --- a/src/gallium/auxiliary/vl/vl_bicubic_filter.c +++ b/src/gallium/auxiliary/vl/vl_bicubic_filter.c @@ -174,6 +174,11 @@ create_frag_shader(struct vl_bicubic_filter *filter, unsigned video_width, i_vtex = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX, TGSI_INTERPOLATE_LINEAR); sampler = ureg_DECL_sampler(shader, 0); + ureg_DECL_sampler_view(shader, 0, TGSI_TEXTURE_2D, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT); for (i = 0; i < 23; ++i) t_array[i] = ureg_DECL_temporary(shader); diff --git a/src/gallium/auxiliary/vl/vl_matrix_filter.c b/src/gallium/auxiliary/vl/vl_matrix_filter.c index e331cb7..11ec816 100644 --- a/src/gallium/auxiliary/vl/vl_matrix_filter.c +++ b/src/gallium/auxiliary/vl/vl_matrix_filter.c @@ -95,6 +95,11 @@ create_frag_shader(struct vl_matrix_filter *filter, unsigned num_offsets, i_vtex = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX, TGSI_INTERPOLATE_LINEAR); sampler = ureg_DECL_sampler(shader, 0); + ureg_DECL_sampler_view(shader, 0, TGSI_TEXTURE_2D, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT); for (i = 0; i < num_offsets; ++i) if (matrix_values[i] != 0.0f) diff --git a/src/gallium/auxiliary/vl/vl_median_filter.c b/src/gallium/auxiliary/vl/vl_median_filter.c index f7477b7..0183b875 100644 --- a/src/gallium/auxiliary/vl/vl_median_filter.c +++ b/src/gallium/auxiliary/vl/vl_median_filter.c @@ -107,6 +107,11 @@ create_frag_shader(struct vl_median_filter *filter, i_vtex = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX, TGSI_INTERPOLATE_LINEAR); sampler = ureg_DECL_sampler(shader, 0); + ureg_DECL_sampler_view(shader, 0, TGSI_TEXTURE_2D, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT, + TGSI_RETURN_TYPE_FLOAT); for (i = 0; i < num_offsets; ++i) t_array[i] = ureg_DECL_temporary(shader); -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/8] gallium/vl: declare sampler views in compositor shaders
The svga driver relies on the existence of these sampler views.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
src/gallium/auxiliary/vl/vl_compositor.c | 37 +++-
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_compositor.c
b/src/gallium/auxiliary/vl/vl_compositor.c
index f98b185..693d685 100644
--- a/src/gallium/auxiliary/vl/vl_compositor.c
+++ b/src/gallium/auxiliary/vl/vl_compositor.c
@@ -137,9 +137,15 @@ create_frag_shader_weave(struct ureg_program *shader,
struct ureg_dst fragment)
i_tc[0] = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTOP,
TGSI_INTERPOLATE_LINEAR);
i_tc[1] = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VBOTTOM,
TGSI_INTERPOLATE_LINEAR);
- for (i = 0; i < 3; ++i)
+ for (i = 0; i < 3; ++i) {
sampler[i] = ureg_DECL_sampler(shader, i);
-
+ ureg_DECL_sampler_view(shader, i, TGSI_TEXTURE_2D_ARRAY,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
+
for (i = 0; i < 2; ++i) {
t_tc[i] = ureg_DECL_temporary(shader);
t_texel[i] = ureg_DECL_temporary(shader);
@@ -248,9 +254,15 @@ create_frag_shader_video_buffer(struct vl_compositor *c)
return false;
tc = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX,
TGSI_INTERPOLATE_LINEAR);
- for (i = 0; i < 3; ++i)
+ for (i = 0; i < 3; ++i) {
sampler[i] = ureg_DECL_sampler(shader, i);
-
+ ureg_DECL_sampler_view(shader, i, TGSI_TEXTURE_2D_ARRAY,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+ }
+
texel = ureg_DECL_temporary(shader);
fragment = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, 0);
@@ -342,8 +354,18 @@ create_frag_shader_palette(struct vl_compositor *c, bool
include_cc)
tc = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX,
TGSI_INTERPOLATE_LINEAR);
sampler = ureg_DECL_sampler(shader, 0);
+ ureg_DECL_sampler_view(shader, 0, TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
palette = ureg_DECL_sampler(shader, 1);
-
+ ureg_DECL_sampler_view(shader, 1, TGSI_TEXTURE_1D,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
+
texel = ureg_DECL_temporary(shader);
fragment = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, 0);
@@ -384,6 +406,11 @@ create_frag_shader_rgba(struct vl_compositor *c)
tc = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_GENERIC, VS_O_VTEX,
TGSI_INTERPOLATE_LINEAR);
color = ureg_DECL_fs_input(shader, TGSI_SEMANTIC_COLOR, VS_O_COLOR,
TGSI_INTERPOLATE_LINEAR);
sampler = ureg_DECL_sampler(shader, 0);
+ ureg_DECL_sampler_view(shader, 0, TGSI_TEXTURE_2D,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT,
+ TGSI_RETURN_TYPE_FLOAT);
texel = ureg_DECL_temporary(shader);
fragment = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, 0);
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 8/8] gallium/vl: Simplify the matrix filter fragment shader
It looks like it was partly copied from the median filter fragment shader
and unnecessesarily saved a lot of temporary values.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
src/gallium/auxiliary/vl/vl_matrix_filter.c | 56 +
1 file changed, 16 insertions(+), 40 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_matrix_filter.c
b/src/gallium/auxiliary/vl/vl_matrix_filter.c
index 11ec816..b498d1f 100644
--- a/src/gallium/auxiliary/vl/vl_matrix_filter.c
+++ b/src/gallium/auxiliary/vl/vl_matrix_filter.c
@@ -81,15 +81,13 @@ create_frag_shader(struct vl_matrix_filter *filter,
unsigned num_offsets,
struct ureg_program *shader;
struct ureg_src i_vtex;
struct ureg_src sampler;
- struct ureg_dst *t_array = MALLOC(sizeof(struct ureg_dst) * num_offsets);
+ struct ureg_dst tmp;
struct ureg_dst t_sum;
struct ureg_dst o_fragment;
- bool first;
unsigned i;
shader = ureg_create(PIPE_SHADER_FRAGMENT);
if (!shader) {
- FREE(t_array);
return NULL;
}
@@ -101,54 +99,32 @@ create_frag_shader(struct vl_matrix_filter *filter,
unsigned num_offsets,
TGSI_RETURN_TYPE_FLOAT,
TGSI_RETURN_TYPE_FLOAT);
- for (i = 0; i < num_offsets; ++i)
- if (matrix_values[i] != 0.0f)
- t_array[i] = ureg_DECL_temporary(shader);
-
+ tmp = ureg_DECL_temporary(shader);
+ t_sum = ureg_DECL_temporary(shader);
o_fragment = ureg_DECL_output(shader, TGSI_SEMANTIC_COLOR, 0);
- /*
-* t_array[0..*] = vtex + offset[0..*]
-* t_array[0..*] = tex(t_array[0..*], sampler)
-* o_fragment = sum(t_array[0..*] * matrix_values[0..*])
-*/
-
+ ureg_MOV(shader, t_sum, ureg_imm1f(shader, 0.0f));
for (i = 0; i < num_offsets; ++i) {
- if (matrix_values[i] != 0.0f && !is_vec_zero(offsets[i])) {
- ureg_ADD(shader, ureg_writemask(t_array[i], TGSI_WRITEMASK_XY),
+ if (matrix_values[i] == 0.0f)
+ continue;
+
+ if (!is_vec_zero(offsets[i])) {
+ ureg_ADD(shader, ureg_writemask(tmp, TGSI_WRITEMASK_XY),
i_vtex, ureg_imm2f(shader, offsets[i].x, offsets[i].y));
- ureg_MOV(shader, ureg_writemask(t_array[i], TGSI_WRITEMASK_ZW),
+ ureg_MOV(shader, ureg_writemask(tmp, TGSI_WRITEMASK_ZW),
ureg_imm1f(shader, 0.0f));
+ ureg_TEX(shader, tmp, TGSI_TEXTURE_2D, ureg_src(tmp), sampler);
+ } else {
+ ureg_TEX(shader, tmp, TGSI_TEXTURE_2D, i_vtex, sampler);
}
+ ureg_MAD(shader, t_sum, ureg_src(tmp), ureg_imm1f(shader,
matrix_values[i]),
+ ureg_src(t_sum));
}
- for (i = 0; i < num_offsets; ++i) {
- if (matrix_values[i] != 0.0f) {
- struct ureg_src src = is_vec_zero(offsets[i]) ? i_vtex :
ureg_src(t_array[i]);
- ureg_TEX(shader, t_array[i], TGSI_TEXTURE_2D, src, sampler);
- }
- }
-
- for (i = 0, first = true; i < num_offsets; ++i) {
- if (matrix_values[i] != 0.0f) {
- if (first) {
-t_sum = t_array[i];
-ureg_MUL(shader, t_sum, ureg_src(t_array[i]),
- ureg_imm1f(shader, matrix_values[i]));
-first = false;
- } else
-ureg_MAD(shader, t_sum, ureg_src(t_array[i]),
- ureg_imm1f(shader, matrix_values[i]), ureg_src(t_sum));
- }
- }
- if (first)
- ureg_MOV(shader, o_fragment, ureg_imm1f(shader, 0.0f));
- else
- ureg_MOV(shader, o_fragment, ureg_src(t_sum));
+ ureg_MOV(shader, o_fragment, ureg_src(t_sum));
ureg_END(shader);
- FREE(t_array);
return ureg_create_shader_and_destroy(shader, filter->pipe);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] gallium: A number of video code fixes
On 02/22/2017 09:56 AM, Christian König wrote: > Am 21.02.2017 um 21:52 schrieb Thomas Hellstrom: >> A couple of fixes / improvements for things I've encountered while >> looking >> through and testing the video code in preparation for a virtual >> hardware video >> driver. > > Reviewed-by: Christian König for the whole > set. Thanks for the review, Christian. /Thomas > >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=DwIDaQ&c=uilaK90D4TOVoH58JNXRgQ&r=wnSlgOCqfpNS4d02vP68_E9q2BNMCwfD2OZ_6dCFVQQ&m=9Bp0jormPCx4wB_f8c8lmZnYcCTy9PWS69Zsk78KQ80&s=mVPwf5JzzaZ1PEE6SE-4pcDZe0FZgXEq42dcklzYpW4&e= > > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/vdpau: Don't reallocate video surfaces on putBitsYCbCr format mismatch
mplayer likes putting YV12 data, and if there is a buffer format mismatch,
the vdpau state tracker would try to reallocate the video surface as an
YV12 surface. A virtual driver doesn't like reallocating and doesn't like YV12
surfaces, so before trying the reallocation, check whether we can instead do
an YV12 to NV12 format conversion.
Also advertize that we actually can do the getBits and putBits conversion.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
src/gallium/auxiliary/util/u_video.h | 42 +
src/gallium/state_trackers/vdpau/query.c | 13
src/gallium/state_trackers/vdpau/surface.c | 50 +-
3 files changed, 98 insertions(+), 7 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_video.h
b/src/gallium/auxiliary/util/u_video.h
index 99a8fd6..7cd6268 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -107,6 +107,48 @@ u_copy_nv12_to_yv12(void *const *destination_data,
}
}
+/**
+ * \brief Copy YV12 chroma data while converting it NV12
+ *
+ * Given a set of YV12 source pointers and -pitches, copy the data to a
+ * layout typical for NV12 video buffers.
+ *
+ * \param source data[in] The plane data pointers. Array of 3.
+ * \param source_pitches[in] The plane pitches. Array of 3.
+ * \param dst_plane[in] The destination plane to copy to. For NV12 always 1.
+ * \param dst_field[in] The destination field if interlaced.
+ * \param dst_stride[in] The destination stride for this plane.
+ * \param num_fields[in] The number of fields in the video buffer.
+ * \param dst[in] The destination plane pointer.
+ * \param width[in] The source plane width.
+ * \param height[in] The source plane height.
+ */
+static inline void
+u_copy_nv12_from_yv12(const void *const *source_data,
+ uint32_t const *source_pitches,
+ int dst_plane, int dst_field,
+ int dst_stride, int num_fields,
+ uint8_t *dst,
+ int width, int height)
+{
+ int x, y;
+ unsigned u_stride = source_pitches[2] * num_fields;
+ unsigned v_stride = source_pitches[1] * num_fields;
+ uint8_t *u_src = (uint8_t *)source_data[2] + source_pitches[2] * dst_field;
+ uint8_t *v_src = (uint8_t *)source_data[1] + source_pitches[1] * dst_field;
+
+ /* TODO: SIMD */
+ for (y = 0; y < height; y++) {
+ for (x = 0; x < width; x++) {
+ dst[2*x] = u_src[x];
+ dst[2*x+1] = v_src[x];
+ }
+ u_src += u_stride;
+ v_src += v_stride;
+ dst += dst_stride;
+ }
+}
+
static inline void
u_copy_yv12_to_nv12(void *const *destination_data,
uint32_t const *destination_pitches,
diff --git a/src/gallium/state_trackers/vdpau/query.c
b/src/gallium/state_trackers/vdpau/query.c
index e69c9b1..435cafd 100644
--- a/src/gallium/state_trackers/vdpau/query.c
+++ b/src/gallium/state_trackers/vdpau/query.c
@@ -123,8 +123,21 @@
vlVdpVideoSurfaceQueryGetPutBitsYCbCrCapabilities(VdpDevice device, VdpChromaTyp
switch(bits_ycbcr_format) {
case VDP_YCBCR_FORMAT_NV12:
+ *is_supported = surface_chroma_type == VDP_CHROMA_TYPE_420;
+ break;
+
case VDP_YCBCR_FORMAT_YV12:
*is_supported = surface_chroma_type == VDP_CHROMA_TYPE_420;
+
+ /* We can convert YV12 to NV12 on the fly! */
+ if (*is_supported &&
+ pscreen->is_video_format_supported(pscreen,
+ PIPE_FORMAT_NV12,
+ PIPE_VIDEO_PROFILE_UNKNOWN,
+ PIPE_VIDEO_ENTRYPOINT_BITSTREAM))
{
+ pipe_mutex_unlock(dev->mutex);
+ return VDP_STATUS_OK;
+ }
break;
case VDP_YCBCR_FORMAT_UYVY:
diff --git a/src/gallium/state_trackers/vdpau/surface.c
b/src/gallium/state_trackers/vdpau/surface.c
index 9a80605..927fbcb 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -304,9 +304,11 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
uint32_t const *source_pitches)
{
enum pipe_format pformat = FormatYCBCRToPipe(source_ycbcr_format);
+ enum getbits_conversion conversion = CONVERSION_NONE;
struct pipe_context *pipe;
struct pipe_sampler_view **sampler_views;
unsigned i, j;
+ unsigned usage = PIPE_TRANSFER_WRITE;
vlVdpSurface *p_surf = vlGetDataHTAB(surface);
if (!p_surf)
@@ -320,7 +322,16 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
return VDP_STATUS_INVALID_POINTER;
pipe_mutex_lock(p_surf->device->mutex);
- if (p_surf->video_buffer == NULL || pformat !=
p_surf->video_buffer->buffer_format) {
+
+ if (pformat != p_surf->video_buffer->buffer_format) {
+ if (pformat == PIPE_FORMAT_YV12 &&
+ p_surf->video_b
[Mesa-dev] [PATCH 2/2] st/va: Fix up YV12 to NV12 putImage conversion
Use the utility u_copy_nv12_from_yv12 to implement this similarly to
how it's been done in the VPAU state tracker. The old code mixed up
planes and fields and didn't correctly handle video surfaces in
interlaced format.
Signed-off-by: Thomas Hellstrom
---
src/gallium/auxiliary/util/u_video.h | 37 ---
src/gallium/state_trackers/va/image.c | 48 ---
2 files changed, 28 insertions(+), 57 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_video.h
b/src/gallium/auxiliary/util/u_video.h
index 7cd6268..251e144 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -173,43 +173,6 @@ u_copy_yv12_to_nv12(void *const *destination_data,
}
static inline void
-u_copy_yv12_img_to_nv12_surf(ubyte *const *src,
- ubyte *dst,
- unsigned width,
- unsigned height,
- unsigned src_stride,
- unsigned dst_stride,
- int field)
-{
- if (field == 0) {
- ubyte *src_0 = src[field];
- for (int i = 0; i < height ; i++) {
- memcpy(dst, src_0, width);
- dst += dst_stride;
- src_0 += src_stride;
- }
- } else if (field == 1) {
- const ubyte *src_1 = src[field];
- const ubyte *src_2 = src[field+1];
- bool odd = true;
- for (unsigned i = 0; i < height ; i++) {
- for (unsigned j = 0; j < width*2 ; j++) {
-if (odd == false) {
- dst[j] = src_1[j/2];
- odd = true;
-} else {
- dst[j] = src_2[j/2];
- odd = false;
-}
- }
- dst += dst_stride;
- src_1 += src_stride;
- src_2 += src_stride;
- }
- }
-}
-
-static inline void
u_copy_swap422_packed(void *const *destination_data,
uint32_t const *destination_pitches,
int src_plane, int src_field,
diff --git a/src/gallium/state_trackers/va/image.c
b/src/gallium/state_trackers/va/image.c
index bd60d3e..47d31de 100644
--- a/src/gallium/state_trackers/va/image.c
+++ b/src/gallium/state_trackers/va/image.c
@@ -513,28 +513,36 @@ vlVaPutImage(VADriverContextP ctx, VASurfaceID surface,
VAImageID image,
for (i = 0; i < vaimage->num_planes; ++i) {
unsigned width, height;
+ struct pipe_resource *tex;
+
if (!views[i]) continue;
- vlVaVideoSurfaceSize(surf, i, &width, &height);
- if (((format == PIPE_FORMAT_YV12) || (format == PIPE_FORMAT_IYUV)) &&
-(surf->buffer->buffer_format == PIPE_FORMAT_NV12)) {
- struct pipe_transfer *transfer = NULL;
- uint8_t *map = NULL;
- struct pipe_box dst_box_1 = {0, 0, 0, width, height, 1};
- map = drv->pipe->transfer_map(drv->pipe,
- views[i]->texture,
- 0,
- PIPE_TRANSFER_DISCARD_RANGE,
- &dst_box_1, &transfer);
- if (map == NULL)
-return VA_STATUS_ERROR_OPERATION_FAILED;
+ tex = views[i]->texture;
- u_copy_yv12_img_to_nv12_surf ((ubyte * const*)data, map, width,
height,
- pitches[i], transfer->stride, i);
- pipe_transfer_unmap(drv->pipe, transfer);
- } else {
- for (j = 0; j < views[i]->texture->array_size; ++j) {
-struct pipe_box dst_box = {0, 0, j, width, height, 1};
-drv->pipe->texture_subdata(drv->pipe, views[i]->texture, 0,
+ vlVaVideoSurfaceSize(surf, i, &width, &height);
+ for (j = 0; j < tex->array_size; ++j) {
+ struct pipe_box dst_box = {0, 0, j, width, height, 1};
+
+ if (((format == PIPE_FORMAT_YV12) || (format == PIPE_FORMAT_IYUV))
+ && (surf->buffer->buffer_format == PIPE_FORMAT_NV12)
+ && i == 1) {
+struct pipe_transfer *transfer = NULL;
+uint8_t *map = NULL;
+
+map = drv->pipe->transfer_map(drv->pipe,
+ tex,
+ 0,
+ PIPE_TRANSFER_WRITE |
+ PIPE_TRANSFER_DISCARD_RANGE,
+ &dst_box, &transfer);
+if (map == NULL)
+ return VA_STATUS_ERROR_OPERATION_FAILED;
+
+u_copy_nv12_from_yv12((const void * const*) data, pitches, i, j,
+ transfer->stride, tex->array_size,
+ map, dst_box.width, dst_box.height);
+pipe_transfer_unmap(drv->pipe,
Re: [Mesa-dev] [PATCH 1/2] st/vdpau: Don't reallocate video surfaces on putBitsYCbCr format mismatch
On 02/22/2017 03:00 PM, Christian König wrote: > Am 22.02.2017 um 14:42 schrieb Thomas Hellstrom: >> mplayer likes putting YV12 data, and if there is a buffer format >> mismatch, >> the vdpau state tracker would try to reallocate the video surface as an >> YV12 surface. A virtual driver doesn't like reallocating and doesn't >> like YV12 >> surfaces, so before trying the reallocation, check whether we can >> instead do >> an YV12 to NV12 format conversion. >> >> Also advertize that we actually can do the getBits and putBits >> conversion. >> >> Signed-off-by: Thomas Hellstrom >> Reviewed-by: Sinclair Yeh > > NAK, the internal format of the surfaces should follow what the > application has put into it as much as possible. That has quite some > performance advantages. > > You should only do the conversation if the backend driver can't handle > the desired format. > > Regards, > Christian. OK. I'll respin. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/vdpau: Provide YV12 to NV12 putBits conversion v2
mplayer likes putting YV12 data, and if there is a buffer format mismatch,
the vdpau state tracker would try to reallocate the video surface as an
YV12 surface. A virtual driver doesn't like reallocating and doesn't like YV12
surfaces, so if we can't support YV12, try an YV12 to NV12 conversion
instead.
Also advertize that we actually can do the getBits and putBits conversion.
v2: A previous version of this patch prioritized conversion before
reallocating. This has been changed to prioritize reallocating in this version.
Cc: Christian König
Signed-off-by: Thomas Hellstrom
---
src/gallium/auxiliary/util/u_video.h | 42 +
src/gallium/state_trackers/vdpau/query.c | 13 +
src/gallium/state_trackers/vdpau/surface.c | 94 --
3 files changed, 130 insertions(+), 19 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_video.h
b/src/gallium/auxiliary/util/u_video.h
index 99a8fd6..7cd6268 100644
--- a/src/gallium/auxiliary/util/u_video.h
+++ b/src/gallium/auxiliary/util/u_video.h
@@ -107,6 +107,48 @@ u_copy_nv12_to_yv12(void *const *destination_data,
}
}
+/**
+ * \brief Copy YV12 chroma data while converting it NV12
+ *
+ * Given a set of YV12 source pointers and -pitches, copy the data to a
+ * layout typical for NV12 video buffers.
+ *
+ * \param source data[in] The plane data pointers. Array of 3.
+ * \param source_pitches[in] The plane pitches. Array of 3.
+ * \param dst_plane[in] The destination plane to copy to. For NV12 always 1.
+ * \param dst_field[in] The destination field if interlaced.
+ * \param dst_stride[in] The destination stride for this plane.
+ * \param num_fields[in] The number of fields in the video buffer.
+ * \param dst[in] The destination plane pointer.
+ * \param width[in] The source plane width.
+ * \param height[in] The source plane height.
+ */
+static inline void
+u_copy_nv12_from_yv12(const void *const *source_data,
+ uint32_t const *source_pitches,
+ int dst_plane, int dst_field,
+ int dst_stride, int num_fields,
+ uint8_t *dst,
+ int width, int height)
+{
+ int x, y;
+ unsigned u_stride = source_pitches[2] * num_fields;
+ unsigned v_stride = source_pitches[1] * num_fields;
+ uint8_t *u_src = (uint8_t *)source_data[2] + source_pitches[2] * dst_field;
+ uint8_t *v_src = (uint8_t *)source_data[1] + source_pitches[1] * dst_field;
+
+ /* TODO: SIMD */
+ for (y = 0; y < height; y++) {
+ for (x = 0; x < width; x++) {
+ dst[2*x] = u_src[x];
+ dst[2*x+1] = v_src[x];
+ }
+ u_src += u_stride;
+ v_src += v_stride;
+ dst += dst_stride;
+ }
+}
+
static inline void
u_copy_yv12_to_nv12(void *const *destination_data,
uint32_t const *destination_pitches,
diff --git a/src/gallium/state_trackers/vdpau/query.c
b/src/gallium/state_trackers/vdpau/query.c
index e69c9b1..435cafd 100644
--- a/src/gallium/state_trackers/vdpau/query.c
+++ b/src/gallium/state_trackers/vdpau/query.c
@@ -123,8 +123,21 @@
vlVdpVideoSurfaceQueryGetPutBitsYCbCrCapabilities(VdpDevice device, VdpChromaTyp
switch(bits_ycbcr_format) {
case VDP_YCBCR_FORMAT_NV12:
+ *is_supported = surface_chroma_type == VDP_CHROMA_TYPE_420;
+ break;
+
case VDP_YCBCR_FORMAT_YV12:
*is_supported = surface_chroma_type == VDP_CHROMA_TYPE_420;
+
+ /* We can convert YV12 to NV12 on the fly! */
+ if (*is_supported &&
+ pscreen->is_video_format_supported(pscreen,
+ PIPE_FORMAT_NV12,
+ PIPE_VIDEO_PROFILE_UNKNOWN,
+ PIPE_VIDEO_ENTRYPOINT_BITSTREAM))
{
+ pipe_mutex_unlock(dev->mutex);
+ return VDP_STATUS_OK;
+ }
break;
case VDP_YCBCR_FORMAT_UYVY:
diff --git a/src/gallium/state_trackers/vdpau/surface.c
b/src/gallium/state_trackers/vdpau/surface.c
index 9a80605..e0dff4e 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -304,9 +304,11 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
uint32_t const *source_pitches)
{
enum pipe_format pformat = FormatYCBCRToPipe(source_ycbcr_format);
+ enum getbits_conversion conversion = CONVERSION_NONE;
struct pipe_context *pipe;
struct pipe_sampler_view **sampler_views;
unsigned i, j;
+ unsigned usage = PIPE_TRANSFER_WRITE;
vlVdpSurface *p_surf = vlGetDataHTAB(surface);
if (!p_surf)
@@ -320,24 +322,53 @@ vlVdpVideoSurfacePutBitsYCbCr(VdpVideoSurface surface,
return VDP_STATUS_INVALID_POINTER;
pipe_mutex_lock(p_surf->device->mutex);
- if (p_surf->video_buffer == NULL || pformat !=
p_surf->video_buffer->buffer_format) {
- /* destroy the old one */
- if (p_
Re: [Mesa-dev] [PATCH 0/8] gallium: A number of video code fixes
On 02/22/2017 04:00 PM, Emil Velikov wrote:
> On 22 February 2017 at 09:30, Thomas Hellstrom wrote:
>> On 02/22/2017 09:56 AM, Christian König wrote:
>>> Am 21.02.2017 um 21:52 schrieb Thomas Hellstrom:
>>>> A couple of fixes / improvements for things I've encountered while
>>>> looking
>>>> through and testing the video code in preparation for a virtual
>>>> hardware video
>>>> driver.
>>> Reviewed-by: Christian König for the whole
>>> set.
>> Thanks for the review, Christian.
> Worth getting the lot to -stable ? Adding either "cc: mesa-stable..."
> or "Fixes: $sha1 ("$commit summary")" will do.
>
> Haven't looked at the series, so not sure how much of the work is
> safe/applicable.
>
> Thanks
> Emil
Hi, Emil,
There is only one significant bugfix in that series, (the vdpau
multithreading fix), but I'm not sure how and if it affects the current
drivers.
I hit this problem with mpv --vo vdpau --hwdec vdpau .
In any case it should probably sit in master for a while before we
decide to crossport.
/Thomas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] gallium: A number of video code fixes
On 02/22/2017 04:46 PM, Christian König wrote:
> Am 22.02.2017 um 16:31 schrieb Thomas Hellstrom:
>> On 02/22/2017 04:00 PM, Emil Velikov wrote:
>>> On 22 February 2017 at 09:30, Thomas Hellstrom
>>> wrote:
>>>> On 02/22/2017 09:56 AM, Christian König wrote:
>>>>> Am 21.02.2017 um 21:52 schrieb Thomas Hellstrom:
>>>>>> A couple of fixes / improvements for things I've encountered while
>>>>>> looking
>>>>>> through and testing the video code in preparation for a virtual
>>>>>> hardware video
>>>>>> driver.
>>>>> Reviewed-by: Christian König for the whole
>>>>> set.
>>>> Thanks for the review, Christian.
>>> Worth getting the lot to -stable ? Adding either "cc: mesa-stable..."
>>> or "Fixes: $sha1 ("$commit summary")" will do.
>>>
>>> Haven't looked at the series, so not sure how much of the work is
>>> safe/applicable.
>>>
>>> Thanks
>>> Emil
>> Hi, Emil,
>>
>> There is only one significant bugfix in that series, (the vdpau
>> multithreading fix), but I'm not sure how and if it affects the current
>> drivers.
>
> Actually thinking more about it that change might be incorrect after all.
>
> The pipe a decoder is created from can be accessed concurrently
> together with the decoder.
The problem is the gallium pipe contexts, like GL's are not allowed to
be used from separate threads without synchronization. At least no other
state trackers I'm aware of are doing that, and if we were allowing it
it would cause a lot of additional costly locking. What was happening in
our case was that the postprocessing thread and the decoding thread were
submitting commands simultaneously wreaking havoc in the pipe context's
relocation lists and command buffers.
>
> E.g. you can hammer on the pipe from thread A and on the decoder from
> thread B at the same time and that is fine.
Unless the decoder tries to manipulate the pipe's state and command queue.
>
>
> Otherwise you run into a bunch of stalling problems with Kodi for
> example.
>
> Your solution of creating a separate pipe object might work as well,
> but I think that could cause problems with the cached sampler views
> later on.
Agreed. If the decoder is using the cached views for rendering purposes
we're in trouble.
Another solution would be to holding a single lock while rendering using
a context and if we take care to release the locks without waiting for
GPU I think the latency incurred would not be too large.
IMO the proper solution would be to do something with the
get_sampler_views* / get_surfaces* interface. In its simplest form they
could take an additional pipe argument.
/Thomas
>
> Regards,
> Christian.
>
>> I hit this problem with mpv --vo vdpau --hwdec vdpau .
>>
>> In any case it should probably sit in master for a while before we
>> decide to crossport.
>>
>> /Thomas
>>
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/8] gallium: A number of video code fixes
On 02/22/2017 05:54 PM, Christian König wrote:
> Am 22.02.2017 um 17:23 schrieb Thomas Hellstrom:
>> On 02/22/2017 04:46 PM, Christian König wrote:
>>> Am 22.02.2017 um 16:31 schrieb Thomas Hellstrom:
>>>> On 02/22/2017 04:00 PM, Emil Velikov wrote:
>>>>> On 22 February 2017 at 09:30, Thomas Hellstrom
>>>>> wrote:
>>>>>> On 02/22/2017 09:56 AM, Christian König wrote:
>>>>>>> Am 21.02.2017 um 21:52 schrieb Thomas Hellstrom:
>>>>>>>> A couple of fixes / improvements for things I've encountered while
>>>>>>>> looking
>>>>>>>> through and testing the video code in preparation for a virtual
>>>>>>>> hardware video
>>>>>>>> driver.
>>>>>>> Reviewed-by: Christian König for the
>>>>>>> whole
>>>>>>> set.
>>>>>> Thanks for the review, Christian.
>>>>> Worth getting the lot to -stable ? Adding either "cc: mesa-stable..."
>>>>> or "Fixes: $sha1 ("$commit summary")" will do.
>>>>>
>>>>> Haven't looked at the series, so not sure how much of the work is
>>>>> safe/applicable.
>>>>>
>>>>> Thanks
>>>>> Emil
>>>> Hi, Emil,
>>>>
>>>> There is only one significant bugfix in that series, (the vdpau
>>>> multithreading fix), but I'm not sure how and if it affects the
>>>> current
>>>> drivers.
>>> Actually thinking more about it that change might be incorrect after
>>> all.
>>>
>>> The pipe a decoder is created from can be accessed concurrently
>>> together with the decoder.
>> The problem is the gallium pipe contexts, like GL's are not allowed to
>> be used from separate threads without synchronization. At least no other
>> state trackers I'm aware of are doing that, and if we were allowing it
>> it would cause a lot of additional costly locking. What was happening in
>> our case was that the postprocessing thread and the decoding thread were
>> submitting commands simultaneously wreaking havoc in the pipe context's
>> relocation lists and command buffers.
>>
>>> E.g. you can hammer on the pipe from thread A and on the decoder from
>>> thread B at the same time and that is fine.
>> Unless the decoder tries to manipulate the pipe's state and command
>> queue.
>
> Which is forbidden. See the shader based MPEG2 implementation for an
> example how to properly handle that.
>
> Actually the decoder should be created from the screen object, not
> from the pipe object.
>
> That it uses the pipe object has only historical reasons and should be
> fixed sooner or later, but as you noted below as well we would need to
> fix the video buffer interface for this.
OK. Then I feel confident reverting this change and instead create a new
pipe object from within the driver decoder. Does that sound OK with you?
/Thomas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Putbits patches
Hi, Christian! Are you OK with the updated Putbits patches? https://lists.freedesktop.org/archives/mesa-dev/2017-February/145269.html https://lists.freedesktop.org/archives/mesa-dev/2017-February/145258.html Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] xa: add xa_surface_from_handle2
Hi! On 08/01/2015 07:16 PM, Emil Velikov wrote: > On 22 July 2015 at 00:00, Rob Clark wrote: >> From: Rob Clark >> >> Like xa_surface_from_handle(), but takes a handle type, rather than >> hard-coding 'shared' handle. This is needed to fix bugs seen with >> xf86-video-freedreno with xrandr rotation, for example. The root issue >> is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle >> associated with the drm_file will result in two unique handles for the >> same bo. Which causes all sorts of follow-on fail. >> >> Cc: "10.5 10.6" >> Signed-off-by: Rob Clark >> --- >> Note: it would be good to get this in stable too, since I have a patch >> for xf86-video-freedreno which will depend on this. >> > Bth, I'm not too excited about having new APIs in the stable branch, > despite them being trivial as this one. > Regardless it would be nice to get a pair of eyes looking in this direction. > > The patch does exactly what it says on the tin, although I do wonder > if we should bump XA_TRACKER_VERSION_MINOR ? I haven't had time yet to look at the patch itself (I'm on vacation and back next week), but having XA recognize handle types, in particular dma-buf fds is, IMO a good thing. Regarding adding new interfaces to XA, the XA documentation is pretty explicit about how this should be handled and recognized, with version numbers. As long as all XA users follow this, it should be pretty straightforward also in a stable mesa branch. IIRC, the XA minor must be bumped in this case, and an out-of-mesa-tree user can't rely on the symbol being present, since an old libxatracker with the same major number might be present, but needs to use dlsym() or something similar. /Thomas > > Thanks > Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] xa: don't leak fences
Hi!
On 07/10/2015 01:12 PM, Marek Olšák wrote:
> I wonder... do we still need XA considering that everybody can just
> use glamor instead?
>
> Marek
Just back from vacation so I late reply.
In the case of VMware/vmwgfx, the rendering setup latency is huge.
Glamor tries to accelerate everything.
saa+xa tries to accelerate as little as possible following the
(admittedly questionable) statement I read somewhere that
Xrender-like acceleration is always faster if it can be done in pure
software. The vmware saa implementation tries to be reasonably smart and
do xrender operation in software and final presents and composition in
hardware with the nice effect that some Xrender benchmarks actually run
faster in the virtual Machine than on its host. As screens grow larger,
however, this approach may well tend to be a dead end.
Not long ago I tried using Xwayland with glamor on vmwgfx and I was
surprised and encouraged by how snappy it looked. I haven't tried
modesetting+glamor+vmwgfx in a while but last time I tried it had all
sorts of rendering artefacts.
But anyway, at some point and after careful benchmarking we can probably
move vmwgfx over to glamor and ditch XA, But XA needs to stay around for
now.
Thanks,
Thomas
>
> On Wed, Jul 8, 2015 at 7:39 PM, Rob Clark wrote:
>> From: Rob Clark
>>
>> XA was never unref'ing last_fence in the various call paths to
>> pipe->flush(). Add this to xa_context_flush() and update the other
>> open-coded calls to pipe->flush() to use xa_context_flush() instead.
>>
>> This fixes a memory leak reported with xf86-video-freedreno.
>>
>> Reported-by: Nicolas Dechesne
>> Cc: "10.5 10.6"
>> Signed-off-by: Rob Clark
>> ---
>> src/gallium/state_trackers/xa/xa_context.c | 6 +-
>> src/gallium/state_trackers/xa/xa_tracker.c | 2 +-
>> src/gallium/state_trackers/xa/xa_yuv.c | 2 +-
>> 3 files changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/xa/xa_context.c
>> b/src/gallium/state_trackers/xa/xa_context.c
>> index fd49c82..ebfb290 100644
>> --- a/src/gallium/state_trackers/xa/xa_context.c
>> +++ b/src/gallium/state_trackers/xa/xa_context.c
>> @@ -37,7 +37,11 @@
>> XA_EXPORT void
>> xa_context_flush(struct xa_context *ctx)
>> {
>> - ctx->pipe->flush(ctx->pipe, &ctx->last_fence, 0);
>> +if (ctx->last_fence) {
>> +struct pipe_screen *screen = ctx->xa->screen;
>> +screen->fence_reference(screen, &ctx->last_fence, NULL);
>> +}
>> +ctx->pipe->flush(ctx->pipe, &ctx->last_fence, 0);
>> }
>>
>> XA_EXPORT struct xa_context *
>> diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
>> b/src/gallium/state_trackers/xa/xa_tracker.c
>> index a384c1c..1df1da7 100644
>> --- a/src/gallium/state_trackers/xa/xa_tracker.c
>> +++ b/src/gallium/state_trackers/xa/xa_tracker.c
>> @@ -464,7 +464,7 @@ xa_surface_redefine(struct xa_surface *srf,
>> xa_min(save_height, template->height0), &src_box);
>> pipe->resource_copy_region(pipe, texture,
>>0, 0, 0, 0, srf->tex, 0, &src_box);
>> - pipe->flush(pipe, &xa->default_ctx->last_fence, 0);
>> + xa_context_flush(xa->default_ctx);
>> }
>>
>> pipe_resource_reference(&srf->tex, texture);
>> diff --git a/src/gallium/state_trackers/xa/xa_yuv.c
>> b/src/gallium/state_trackers/xa/xa_yuv.c
>> index 1519639..97a1833 100644
>> --- a/src/gallium/state_trackers/xa/xa_yuv.c
>> +++ b/src/gallium/state_trackers/xa/xa_yuv.c
>> @@ -154,7 +154,7 @@ xa_yuv_planar_blit(struct xa_context *r,
>> box++;
>> }
>>
>> -r->pipe->flush(r->pipe, &r->last_fence, 0);
>> +xa_context_flush(r);
>>
>> xa_ctx_sampler_views_destroy(r);
>> xa_ctx_srf_destroy(r);
>> --
>> 2.4.3
>>
>> ___
>> mesa-dev mailing list
>> mesa-dev@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=Te7648QdywS9RDPz53hgZS3QRABaJXfScb_lMEYP9Kw&s=rMOrpIBCc9Q9J9i5caDyFx5KBTLy6sIv5nb3cfKlMS8&e=
>>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=BQIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=vpukPkBtpoNQp2IUKuFviOmPNYWVKmen3Jeeu55zmEA&m=Te7648QdywS9RDPz53hgZS3QRABaJXfScb_lMEYP9Kw&s=rMOrpIBCc9Q9J9i5caDyFx5KBTLy6sIv5nb3cfKlMS8&e=
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/postprocess: Fix resource freeing
The code was triggering asserts in DEBUG builds of the SVGA driver since
the reference count of the resource was never decremented before destroy.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
---
src/gallium/auxiliary/postprocess/pp_mlaa.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/postprocess/pp_mlaa.c
b/src/gallium/auxiliary/postprocess/pp_mlaa.c
index 502fcf1..0edd01f 100644
--- a/src/gallium/auxiliary/postprocess/pp_mlaa.c
+++ b/src/gallium/auxiliary/postprocess/pp_mlaa.c
@@ -353,13 +353,11 @@ void
pp_jimenezmlaa_free(struct pp_queue_t *ppq, unsigned int n)
{
if (ppq->areamaptex) {
- ppq->p->screen->resource_destroy(ppq->p->screen, ppq->areamaptex);
- ppq->areamaptex = NULL;
+ pipe_resource_reference(&ppq->areamaptex, NULL);
}
if (ppq->constbuf) {
- ppq->p->screen->resource_destroy(ppq->p->screen, ppq->constbuf);
- ppq->constbuf = NULL;
+ pipe_resource_reference(&ppq->constbuf, NULL);
}
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Delayed rendering in st/vdpau
Hi, Christian, I remember some time ago you briefly explained what the delayed rendering in st/vdpau is all about, but I can't seem to find that email. Could you point me to a description or briefly detail what it is all about, and also why it doesn't seem to be needed when vdpau uses filters? Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 10/15] gbm: Create a DRI image for dumb buffers, too.
Hi!
As discussed also offline, this is not a good thing to do, for the
following reasons:
1) The bo handle does not necessarily represent a gem object. Calling
gem_flink on such a handle is illegal.
2) Dumb bos and BO_USE_RENDERING may be totally different objects.
It's incorrect to assume that a dumb bo handle can be typecasted to a
rendering BO handle.
This is to avoid having to deal with coherence issues without having
enough information to make it efficient.
There currently is no accepted API to allow direct mmaping of a
GBM_BO_USE_RENDERING.
If we should invent one, it would need synchronization infomation, like
damaged- and readback regions.
So this is a NAK.
Thanks,
Thomas
On 07/20/2013 01:40 PM, Christopher James Halse Rogers wrote:
We want this so we can hand out CPU-mappable buffers to clients, but still
use EGL in the server to composite said buffers.
---
src/gbm/backends/dri/gbm_dri.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index 8b71cca..8ca7b54 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -318,9 +318,9 @@ gbm_dri_bo_destroy(struct gbm_bo *_bo)
struct gbm_dri_bo *bo = gbm_dri_bo(_bo);
struct drm_mode_destroy_dumb arg;
- if (bo->image != NULL) {
+ if (bo->image)
dri->image->destroyImage(bo->image);
- } else {
+ if (bo->map) {
munmap(bo->map, bo->size);
memset(&arg, 0, sizeof(arg));
arg.handle = bo->handle;
@@ -532,6 +532,25 @@ create_dumb(struct gbm_device *gbm,
if (bo->map == MAP_FAILED)
goto destroy_dumb;
+ if (usage & GBM_BO_USE_RENDERING)
+ {
+ struct drm_gem_flink flink_arg;
+ memset(&flink_arg, 0, sizeof(flink_arg));
+ flink_arg.handle = bo->handle;
+ ret = drmIoctl(dri->base.base.fd, DRM_IOCTL_GEM_FLINK, &flink_arg);
+ if (ret)
+ goto destroy_dumb;
+
+ bo->image = dri->image->createImageFromName(dri->screen,
+ width, height,
+ gbm_to_dri_format(format),
+ flink_arg.name,
+ bo->base.base.stride / 4,
+ bo);
+
+ if (!bo->image)
+ goto destroy_dumb;
+ }
return &bo->base.base;
destroy_dumb:
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] DRI Image v7 support for gallium drivers
On 10/08/2013 12:48 AM, christopher.halse.rog...@canonical.com wrote: This is a prerequisite for the Mir EGL platform, which I'm sure everyone is excited about. It's also necessary for Wayland hybrid graphics support. Sorry for replying this late, I just started looking at this patch series. I saw an earlier discussion about how to tell whether a driver supports fd sharing, and that boiled down to the state tracker querying the winsys, or rather the bootstrapper directly for that support. There actually is an API for this, the drm driver descriptor. Please have a look at state_tracker/drm_driver.h and how DRM_CONF_THROTTLE is handled in the target code and in the dri state tracker. It would be possible to add a DRM_CONF_SHARE_FD (or similar) enum to indicate support for this sharing type, if you want to expose support for DRI_IMAGE V7 on a per driver basis. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 9/9] svga/winsys: Implement surface sharing using prime fd handles
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
From: Thomas Hellstrom
This needs a prime-aware vmwgfx kernel module to work properly.
(With additions by Christopher James Halse Rogers )
Signed-off-by: Thomas Hellstrom
---
src/gallium/targets/dri-vmwgfx/target.c | 13 +
src/gallium/winsys/svga/drm/vmw_screen_dri.c | 79 +---
2 files changed, 74 insertions(+), 18 deletions(-)
diff --git a/src/gallium/targets/dri-vmwgfx/target.c
b/src/gallium/targets/dri-vmwgfx/target.c
index e01e465..aaf37b0 100644
--- a/src/gallium/targets/dri-vmwgfx/target.c
+++ b/src/gallium/targets/dri-vmwgfx/target.c
@@ -31,11 +31,24 @@ static const struct drm_conf_ret throttle_ret = {
.val.val_int = 2,
};
+/* Technically this requires kernel support that is not yet
+ * widespread.
+ *
+ * We could check for support in create_screen and return the correct
+ * value, but for now just return true in all cases.
+ */
Good point. I will bump the drm vmwgfx driver minor to advertise prime
support,
but this is fine for now.
+static const struct drm_conf_ret share_fd_ret = {
+ .type = DRM_CONF_BOOL,
+ .val.val_int = true,
+};
+
static const struct drm_conf_ret *drm_configuration(enum drm_conf conf)
{
switch (conf) {
case DRM_CONF_THROTTLE:
return &throttle_ret;
+ case DRM_CONF_SHARE_FD:
+ return &share_fd_ret;
default:
break;
}
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 6323a8a..a17cdf7 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -40,6 +40,7 @@
#include
#include
+#include
struct dri1_api_version {
int major;
@@ -160,37 +161,57 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen
*sws,
union drm_vmw_surface_reference_arg arg;
struct drm_vmw_surface_arg *req = &arg.req;
struct drm_vmw_surface_create_req *rep = &arg.rep;
+uint32_t handle = 0;
int ret;
int i;
-if (whandle->type != DRM_API_HANDLE_TYPE_SHARED) {
-vmw_error("Attempt to import unknown handle type %d\n",
- whandle->type);
-return NULL;
+switch (whandle->type) {
+case DRM_API_HANDLE_TYPE_SHARED:
+case DRM_API_HANDLE_TYPE_KMS:
+ handle = whandle->handle;
+ break;
+case DRM_API_HANDLE_TYPE_FD:
+ ret = drmPrimeFDToHandle(vws->ioctl.drm_fd, whandle->handle,
+&handle);
+ if (ret) {
+ vmw_error("Failed to get handle from prime fd %d.\n",
+ (int) whandle->handle);
+ return NULL;
+ }
+ break;
+default:
+ vmw_error("Attempt to import unsupported handle type %d.\n",
+ whandle->type);
+ return NULL;
}
-/**
- * The vmware device specific handle is the hardware SID.
- * FIXME: We probably want to move this to the ioctl implementations.
- */
-
memset(&arg, 0, sizeof(arg));
-req->sid = whandle->handle;
+req->sid = handle;
ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_REF_SURFACE,
&arg, sizeof(arg));
+/*
+ * Need to close the handle we got from prime.
+ */
+if (whandle->type == DRM_API_HANDLE_TYPE_FD)
+ vmw_ioctl_surface_destroy(vws, handle);
+
if (ret) {
-vmw_error("Failed referencing shared surface. SID %d.\n"
- "Error %d (%s).\n",
- whandle->handle, ret, strerror(-ret));
- return NULL;
+ /*
+* Any attempt to share something other than a surface, like a dumb
+* kms buffer, should fail here.
+*/
+ vmw_error("Failed referencing shared surface. SID %d.\n"
+ "Error %d (%s).\n",
+ handle, ret, strerror(-ret));
+ return NULL;
}
if (rep->mip_levels[0] != 1) {
vmw_error("Incorrect number of mipmap levels on shared surface."
" SID %d, levels %d\n",
- whandle->handle, rep->mip_levels[0]);
+ handle, rep->mip_levels[0]);
goto out_mip;
}
@@ -198,7 +219,7 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen *sws,
if (rep->mip_levels[i] != 0) {
vmw_error("Incorrect number of faces levels on shared surface."
" SID %d, face %d present.\n",
- whandle->handle, i);
+ handle, i);
goto out_mip;
}
}
@@ -210,14 +231,15 @@ vmw_drm_surface_from_handle(struct svga_winsys_screen
*sws,
pipe_reference_init(&vsrf->refcnt, 1);
p_atomic_set(&
Re: [Mesa-dev] [PATCH 3/9] gallium/dri2: Set winsys_handle type to KMS for stride query.
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote:
From: Christopher James Halse Rogers
Otherwise the default is TYPE_SHARED, which will flink the bo. This seems
rather unnecessary for a simple stride query.
Is there no way we can cache this stuff in a __DRIimage? Changing the
calling conventions to adapt to poor implementations seems like
the wrong way to go. What if other drivers use a slow approach to get
the KMS handle?
/Thomas
---
src/gallium/state_trackers/dri/drm/dri2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index 42c863b..db034bd 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -691,6 +691,7 @@ dri2_query_image(__DRIimage *image, int attrib, int *value)
switch (attrib) {
case __DRI_IMAGE_ATTRIB_STRIDE:
+ whandle.type = DRM_API_HANDLE_TYPE_KMS;
image->texture->screen->resource_get_handle(image->texture->screen,
image->texture, &whandle);
*value = whandle.stride;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/9] DRI Image 7 support for gallium
On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote: Now includes support for Image 6 as a bonus feature, and 7 is only exposed on the gallium drivers which support dma-buf import/export. Still useful for Wayland-Prime and Mir, now also useful for DRI3000 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev For the series (but some driver guys should check the driver prime implementations, particularly gem handle closing), and perhaps if there's a better fix for patch 3 Reviewed-by: Thomas Hellstrom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] XA tracker pipe-loader woes.
Hi, Rob It turns out that your patch st/xa: use pipe-loader to get screen, makes the xa tracker close the X server driver's drm file descriptor when XA initialization fails or when XA is closed. This breaks X for example on Ubuntu 14.10 if 3D is disabled (typically on ESX). Pretty nasty bug for us. I'm not sure about the correct fix. Personally I don't think the pipe loader should close the file descriptor on cleanup. If people insist on it doing so, we can either intentionally leak pipe loader state or we can perhaps dup() the file descriptor before opening the loader. I'm not completely sure how DRM responds to that, though. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] XA tracker pipe-loader woes.
On 07/02/2014 12:50 PM, Maarten Lankhorst wrote: > op 02-07-14 12:34, Thomas Hellstrom schreef: >> Hi, Rob >> >> It turns out that your patch st/xa: use pipe-loader to get screen, >> makes the xa tracker close the X server driver's drm file descriptor when >> XA initialization fails or when XA is closed. >> >> This breaks X for example on Ubuntu 14.10 if 3D is disabled (typically >> on ESX). Pretty nasty bug for us. >> >> I'm not sure about the correct fix. Personally I don't think the pipe >> loader should close the file descriptor on cleanup. >> If people insist on it doing so, we can either intentionally leak pipe >> loader state or we can perhaps dup() the file descriptor before opening >> the loader. I'm not completely sure how DRM responds to that, though. >> > duping fd's is fine, you get the same underlying file, but the kernel state > doesn't change at all. > Nouveau uses this solution too, and it works for us. :-) > > ~Maarten Thanks. Good to know. Although I still think it's incorrect of the pipe-loader to hijack the file descriptor in that way. /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Don't close the drm fd on failure
If XA fails to initialize with pipe_loader enabled, the pipe_loader's cleanup function will close the drm file descriptor. That's pretty bad because the file descriptor will probably be the X server driver's only connection to drm. Temporarily solve this by dup()'ing the file descriptor before handing it over to the pipe loader. This fixes freedesktop.org bugzilla bug #80645. Cc: "10.2" Signed-off-by: Thomas Hellstrom --- src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/xa/xa_tracker.c b/src/gallium/state_trackers/xa/xa_tracker.c index 6e4312e..268d56b 100644 --- a/src/gallium/state_trackers/xa/xa_tracker.c +++ b/src/gallium/state_trackers/xa/xa_tracker.c @@ -26,6 +26,7 @@ * Thomas Hellstrom */ +#include #include "xa_tracker.h" #include "xa_priv.h" #include "pipe/p_state.h" @@ -140,6 +141,7 @@ xa_tracker_create(int drm_fd) struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); enum xa_surface_type stype; unsigned int num_formats; +int loader_fd; if (!xa) return NULL; @@ -147,7 +149,10 @@ xa_tracker_create(int drm_fd) #if GALLIUM_STATIC_TARGETS xa->screen = dd_create_screen(drm_fd); #else -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) +loader_fd = dup(drm_fd); +if (loader_fd == -1) +return NULL; +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); #endif if (!xa->screen) -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Don't close the drm fd on failure v2
If XA fails to initialize with pipe_loader enabled, the pipe_loader's cleanup function will close the drm file descriptor. That's pretty bad because the file descriptor will probably be the X server driver's only connection to drm. Temporarily solve this by dup()'ing the file descriptor before handing it over to the pipe loader. This fixes freedesktop.org bugzilla bug #80645. v2: Fix CC addresses. Cc: "10.2" Signed-off-by: Thomas Hellstrom --- src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/xa/xa_tracker.c b/src/gallium/state_trackers/xa/xa_tracker.c index 6e4312e..268d56b 100644 --- a/src/gallium/state_trackers/xa/xa_tracker.c +++ b/src/gallium/state_trackers/xa/xa_tracker.c @@ -26,6 +26,7 @@ * Thomas Hellstrom */ +#include #include "xa_tracker.h" #include "xa_priv.h" #include "pipe/p_state.h" @@ -140,6 +141,7 @@ xa_tracker_create(int drm_fd) struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); enum xa_surface_type stype; unsigned int num_formats; +int loader_fd; if (!xa) return NULL; @@ -147,7 +149,10 @@ xa_tracker_create(int drm_fd) #if GALLIUM_STATIC_TARGETS xa->screen = dd_create_screen(drm_fd); #else -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) +loader_fd = dup(drm_fd); +if (loader_fd == -1) +return NULL; +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); #endif if (!xa->screen) -- 2.0.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Another important XA patch
Hi, Carl, Patch st/xa: Don't close the drm fd on failure v2 causes some conflicts when backported to 10.2. Let me know if you need help resolving them, or if you want me to push a backported version to 10.2. Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: Don't unnecessarily reemit BindGBShader commands v2
The Linux winsys can no longer relocate shader code, so avoid
reemitting BindGBShader commands. They are costly.
v2: Correctly handle errors from SVGA3D_BindGBShader()
Reported-by: Michael Banack
Signed-off-by: Thomas Hellstrom
Tested-by: Brian Paul
Reviewed-by: Brian Paul
Reviewed-by: Jakob Bornecrantz
---
src/gallium/drivers/svga/svga_shader.c | 9 -
src/gallium/drivers/svga/svga_state_fs.c | 8
src/gallium/drivers/svga/svga_state_vs.c | 11 ---
3 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_shader.c
b/src/gallium/drivers/svga/svga_shader.c
index 6b6b441..46efa07 100644
--- a/src/gallium/drivers/svga/svga_shader.c
+++ b/src/gallium/drivers/svga/svga_shader.c
@@ -45,13 +45,20 @@ svga_define_shader(struct svga_context *svga,
if (svga_have_gb_objects(svga)) {
struct svga_winsys_screen *sws = svga_screen(svga->pipe.screen)->sws;
+ enum pipe_error ret;
variant->gb_shader = sws->shader_create(sws, type,
variant->tokens, codeLen);
if (!variant->gb_shader)
return PIPE_ERROR_OUT_OF_MEMORY;
- return PIPE_OK;
+ ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
+ if (ret != PIPE_OK) {
+ sws->shader_destroy(sws, variant->gb_shader);
+ variant->gb_shader = NULL;
+ }
+
+ return ret;
}
else {
enum pipe_error ret;
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 8f419fa..e714c07 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -402,14 +402,6 @@ emit_hw_fs(struct svga_context *svga, unsigned dirty)
if (variant != svga->state.hw_draw.fs) {
if (svga_have_gb_objects(svga)) {
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
- if (ret != PIPE_OK)
-return ret;
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
variant->gb_shader);
if (ret != PIPE_OK)
diff --git a/src/gallium/drivers/svga/svga_state_vs.c
b/src/gallium/drivers/svga/svga_state_vs.c
index 125903b..545c9d7 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -243,17 +243,6 @@ emit_hw_vs(struct svga_context *svga, unsigned dirty)
if (svga_have_gb_objects(svga)) {
struct svga_winsys_gb_shader *gbshader =
variant ? variant->gb_shader : NULL;
-
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- if (gbshader) {
-ret = SVGA3D_BindGBShader(svga->swc, gbshader);
-if (ret != PIPE_OK)
- return ret;
- }
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
if (ret != PIPE_OK)
return ret;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] svga: Don't unnecessarily reemit BindGBShader commands v2
The Linux winsys can no longer relocate shader code, so avoid
reemitting BindGBShader commands. They are costly.
v2: Correctly handle errors from SVGA3D_BindGBShader()
Reported-by: Michael Banack
Signed-off-by: Thomas Hellstrom
Tested-by: Brian Paul
Reviewed-by: Brian Paul
Reviewed-by: Jakob Bornecrantz
---
src/gallium/drivers/svga/svga_shader.c | 9 -
src/gallium/drivers/svga/svga_state_fs.c | 8
src/gallium/drivers/svga/svga_state_vs.c | 11 ---
3 files changed, 8 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_shader.c
b/src/gallium/drivers/svga/svga_shader.c
index 6b6b441..46efa07 100644
--- a/src/gallium/drivers/svga/svga_shader.c
+++ b/src/gallium/drivers/svga/svga_shader.c
@@ -45,13 +45,20 @@ svga_define_shader(struct svga_context *svga,
if (svga_have_gb_objects(svga)) {
struct svga_winsys_screen *sws = svga_screen(svga->pipe.screen)->sws;
+ enum pipe_error ret;
variant->gb_shader = sws->shader_create(sws, type,
variant->tokens, codeLen);
if (!variant->gb_shader)
return PIPE_ERROR_OUT_OF_MEMORY;
- return PIPE_OK;
+ ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
+ if (ret != PIPE_OK) {
+ sws->shader_destroy(sws, variant->gb_shader);
+ variant->gb_shader = NULL;
+ }
+
+ return ret;
}
else {
enum pipe_error ret;
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 8f419fa..e714c07 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -402,14 +402,6 @@ emit_hw_fs(struct svga_context *svga, unsigned dirty)
if (variant != svga->state.hw_draw.fs) {
if (svga_have_gb_objects(svga)) {
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- ret = SVGA3D_BindGBShader(svga->swc, variant->gb_shader);
- if (ret != PIPE_OK)
-return ret;
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_PS,
variant->gb_shader);
if (ret != PIPE_OK)
diff --git a/src/gallium/drivers/svga/svga_state_vs.c
b/src/gallium/drivers/svga/svga_state_vs.c
index 125903b..545c9d7 100644
--- a/src/gallium/drivers/svga/svga_state_vs.c
+++ b/src/gallium/drivers/svga/svga_state_vs.c
@@ -243,17 +243,6 @@ emit_hw_vs(struct svga_context *svga, unsigned dirty)
if (svga_have_gb_objects(svga)) {
struct svga_winsys_gb_shader *gbshader =
variant ? variant->gb_shader : NULL;
-
- /*
- * Bind is necessary here only because pipebuffer_fenced may move
- * the shader contents around
- */
- if (gbshader) {
-ret = SVGA3D_BindGBShader(svga->swc, gbshader);
-if (ret != PIPE_OK)
- return ret;
- }
-
ret = SVGA3D_SetGBShader(svga->swc, SVGA3D_SHADERTYPE_VS, gbshader);
if (ret != PIPE_OK)
return ret;
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Another important XA patch
Hi! On 07/04/2014 04:59 AM, Carl Worth wrote: > Thomas Hellstrom writes: >> Patch st/xa: Don't close the drm fd on failure v2 causes some conflicts >> when backported to 10.2. Let me know if >> you need help resolving them, or if you want me to push a backported >> version to 10.2. > > Thanks for the heads-up, Thomas. > > The conflict resolution seemed quite straightforward. Take a look and > let me know if you think I botched anything. > > -Carl Looks good to me. Thanks! Thomas > > From ff02e7995c09278be06c34d596d3d8ca11e26ded Mon Sep 17 00:00:00 2001 > From: Thomas Hellstrom > Date: Thu, 3 Jul 2014 02:07:36 -0700 > Subject: [PATCH] st/xa: Don't close the drm fd on failure v2 > > If XA fails to initialize with pipe_loader enabled, the pipe_loader's > cleanup function will close the drm file descriptor. That's pretty bad > because the file descriptor will probably be the X server driver's only > connection to drm. Temporarily solve this by dup()'ing the file descriptor > before handing it over to the pipe loader. > > This fixes freedesktop.org bugzilla bug #80645. > > v2: Fix CC addresses. > > Cc: "10.2" > Signed-off-by: Thomas Hellstrom > Reviewed-by: Jakob Bornecrantz > (cherry picked from commit 35cf3831d71770211f29da6608313dc1f6213d7b) > > Conflicts: > src/gallium/state_trackers/xa/xa_tracker.c > --- > src/gallium/state_trackers/xa/xa_tracker.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/src/gallium/state_trackers/xa/xa_tracker.c b/src/gallium/state_trackers/xa/xa_tracker.c > index 9add584..be16964 100644 > --- a/src/gallium/state_trackers/xa/xa_tracker.c > +++ b/src/gallium/state_trackers/xa/xa_tracker.c > @@ -26,6 +26,7 @@ > * Thomas Hellstrom > */ > > +#include > #include "xa_tracker.h" > #include "xa_priv.h" > #include "pipe/p_state.h" > @@ -140,11 +141,15 @@ xa_tracker_create(int drm_fd) > struct xa_tracker *xa = calloc(1, sizeof(struct xa_tracker)); > enum xa_surface_type stype; > unsigned int num_formats; > +int loader_fd; > > if (!xa) > return NULL; > > -if (pipe_loader_drm_probe_fd(&xa->dev, drm_fd, false)) > +loader_fd = dup(drm_fd); > +if (loader_fd == -1) > +return NULL; > +if (pipe_loader_drm_probe_fd(&xa->dev, loader_fd, false)) > xa->screen = pipe_loader_create_screen(xa->dev, PIPE_SEARCH_DIR); > if (!xa->screen) > goto out_no_screen; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] dri2 and vtSema
Hi! I'm not completely sure what's the correct list for this nowadays, so forgive me for crossposting. I've got an interesting problem in that when any dri2 operations are carried out while the X server is switched away, they are pushed all the way down to the kernel graphics driver, which doesn't like that because the X server has "given up" the hardware. So what's the mechanism supposed to stop that? Ideally I'd like to suspend the client on the X server connection /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/9] gallium/dri2: Set winsys_handle type to KMS for stride query.
On 11/25/2013 05:06 AM, Christopher James Halse Rogers wrote: On Thu, 2013-11-21 at 14:12 +0100, Thomas Hellstrom wrote: On 11/21/2013 05:11 AM, christopher.halse.rog...@canonical.com wrote: From: Christopher James Halse Rogers Otherwise the default is TYPE_SHARED, which will flink the bo. This seems rather unnecessary for a simple stride query. Is there no way we can cache this stuff in a __DRIimage? Changing the calling conventions to adapt to poor implementations seems like the wrong way to go. What if other drivers use a slow approach to get the KMS handle? Do you want me to add some extra gallium API to get this sort of image metadata without using what's essentially a side-effect of resource_get_handle? If this isn't a theoretical concern I can certainly do so It's more of a theoretical concern. We can certainly revisit this at a later time. Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallium/dri: Support DRI Image extension version 7 (v3)
On 11/25/2013 05:38 AM, Ben Skeggs wrote: On Mon, Nov 25, 2013 at 1:57 PM, wrote: From: Christopher James Halse Rogers http://cgit.freedesktop.org/~keithp/mesa/log/?h=dri3 Ben, Christopher's patches have apparently been on the mesa dev lists since April, with various reviews and comments, and also supporting most (all ?) prime-aware drivers. Is there any chance that you could sync the overlapping work in Keith's tree so we don't end up with two "competing" patchsets to review, aiming at doing more or less the same thing? Thanks Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/dri: Check for kernel support before enabling fd sharing
The dri2 state tracker is checking for driver support before enabling
dri2ImageExtension version 7. This commit adds a check that also the
kernel driver supports fd sharing through prime.
Note that this adds a libdrm dependency on dri2.c.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/dri/drm/dri2.c | 13 +++--
src/gallium/targets/dri-vmwgfx/target.c |6 --
2 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/dri/drm/dri2.c
b/src/gallium/state_trackers/dri/drm/dri2.c
index 8ff77b3..b9f6928 100644
--- a/src/gallium/state_trackers/dri/drm/dri2.c
+++ b/src/gallium/state_trackers/dri/drm/dri2.c
@@ -28,6 +28,7 @@
* Chia-I Wu
*/
+#include
#include "util/u_memory.h"
#include "util/u_inlines.h"
#include "util/u_format.h"
@@ -1051,10 +1052,18 @@ dri2_init_screen(__DRIscreen * sPriv)
screen->default_throttle_frames = throttle_ret->val.val_int;
}
+#ifdef DRM_CAP_PRIME /* Old libdrm? */
if (dmabuf_ret && dmabuf_ret->val.val_bool) {
- dri2ImageExtension.base.version = 7;
- dri2ImageExtension.createImageFromFds = dri2_from_fds;
+ uint64_t cap;
+
+ if (drmGetCap(sPriv->fd, DRM_CAP_PRIME, &cap) == 0 &&
+ !!(cap & DRM_PRIME_CAP_IMPORT)) {
+
+ dri2ImageExtension.base.version = 7;
+ dri2ImageExtension.createImageFromFds = dri2_from_fds;
+ }
}
+#endif /* DRM_CAP_PRIME */
sPriv->extensions = dri_screen_extensions;
diff --git a/src/gallium/targets/dri-vmwgfx/target.c
b/src/gallium/targets/dri-vmwgfx/target.c
index aaf37b0..e3fbda1 100644
--- a/src/gallium/targets/dri-vmwgfx/target.c
+++ b/src/gallium/targets/dri-vmwgfx/target.c
@@ -31,12 +31,6 @@ static const struct drm_conf_ret throttle_ret = {
.val.val_int = 2,
};
-/* Technically this requires kernel support that is not yet
- * widespread.
- *
- * We could check for support in create_screen and return the correct
- * value, but for now just return true in all cases.
- */
static const struct drm_conf_ret share_fd_ret = {
.type = DRM_CONF_BOOL,
.val.val_int = true,
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/svga: Replace the query mm buffer pool with a slab pool
This is to avoid running out of query buffer space due to winsys
limitations.
Reported-and-tested-by: Brian Paul
Signed-off-by: Thomas Hellstrom
Cc: "10.1"
---
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
index c97b71f..e49262a 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
@@ -76,15 +76,19 @@ vmw_pools_cleanup(struct vmw_winsys_screen *vws)
*
* Typically this pool should be created on demand when we
* detect that the app will be using queries. There's nothing
- * special with this pool other than the backing kernel buffer size,
- * which is limited to 8192.
+ * special with this pool other than the backing kernel buffer sizes,
+ * which are limited to 8192.
*/
boolean
vmw_query_pools_init(struct vmw_winsys_screen *vws)
{
- vws->pools.query_mm = mm_bufmgr_create(vws->pools.gmr,
- VMW_QUERY_POOL_SIZE,
- 3 /* 8 alignment */);
+ struct pb_desc desc;
+
+ desc.alignment = 16;
+ desc.usage = ~(VMW_BUFFER_USAGE_SHARED | VMW_BUFFER_USAGE_SYNC);
+
+ vws->pools.query_mm = pb_slab_range_manager_create(vws->pools.gmr, 16, 128,
+ 8192, &desc);
if (!vws->pools.query_mm)
return FALSE;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/svga: Replace the query mm buffer pool with a slab pool v2
This is to avoid running out of query buffer space due to winsys
limitations.
v2: Correct email addresses.
Reported-and-tested-by: Brian Paul
Signed-off-by: Thomas Hellstrom
Cc: "10.1"
---
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
index c97b71f..e49262a 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
@@ -76,15 +76,19 @@ vmw_pools_cleanup(struct vmw_winsys_screen *vws)
*
* Typically this pool should be created on demand when we
* detect that the app will be using queries. There's nothing
- * special with this pool other than the backing kernel buffer size,
- * which is limited to 8192.
+ * special with this pool other than the backing kernel buffer sizes,
+ * which are limited to 8192.
*/
boolean
vmw_query_pools_init(struct vmw_winsys_screen *vws)
{
- vws->pools.query_mm = mm_bufmgr_create(vws->pools.gmr,
- VMW_QUERY_POOL_SIZE,
- 3 /* 8 alignment */);
+ struct pb_desc desc;
+
+ desc.alignment = 16;
+ desc.usage = ~(VMW_BUFFER_USAGE_SHARED | VMW_BUFFER_USAGE_SYNC);
+
+ vws->pools.query_mm = pb_slab_range_manager_create(vws->pools.gmr, 16, 128,
+ 8192, &desc);
if (!vws->pools.query_mm)
return FALSE;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/4] XA composite and perf improvements
On 04/01/2014 06:18 PM, Rob Clark wrote: > On Tue, Apr 1, 2014 at 12:14 PM, Zack Rusin wrote: >> - Original Message - >>> From: Rob Clark >>> >>> While still more of a stop-gap solution (until glamor) for freedreno, >>> with these few relatively simple changes I get a pretty big performance >>> boost (~40%) for xf86-video-freedreno. >> That looks great to me. Nice work. >> But to be honest the only thing I remember about this code is that it has >> been written in C and I'm probably like 40% certain of that. > heheh, fair enough > > well, let me know if there is anything I can do to help test (don't > suppose you have a linux vmware player image somewhere setup with > everything to build/install latest mesa? ;-)) > > I do have a branch here that you could pull if you want to test: > > https://urldefense.proofpoint.com/v1/url?u=https://github.com/freedreno/mesa/commits/xa&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=HhXBh%2BiRTHozYnKRPiENV4eZDXlB4PW%2Bk1blIb9xOhg%3D%0A&s=713e8e2e4558ecd2d53d9874dc7d3e19f13dbb2834b05d98cadb49208acf6089 > git://github.com/freedreno/mesa.git xa > > BR, > -R Hi, Rob! Nice work! I can do some testing later this week. In our xorg driver / DDX, we have a special "rendercheck" mode that disables the migration heuristics and always enable hardware acceleration. Although unfortunately I don't think there are any solid fill hooks. I'll also try to review the patches as soon as I have some time. some quick questions: Did you run the newly enabled accelerated operations through "rendercheck"? What does the performance look like on the "modesetting" driver with shadow framebuffer enabled, compared to freedreno with acceleration enabled? Thanks, Thomas > >> z ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/svga: Replace the query mm buffer pool with a slab pool v3
This is to avoid running out of query buffer space due to winsys
limitations. Instead of a fixed size per screen pool of query buffers,
use a slab allocator that allocates a new slab if we run out of space
in the first one.
v2: Correct email addresses.
v3: s/8192/VMW_QUERY_POOL_SIZE/. Improve documentation and log message.
Reported-and-tested-by: Brian Paul
Signed-off-by: Thomas Hellstrom
Cc: "10.1"
---
src/gallium/winsys/svga/drm/vmw_screen_pools.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
index c97b71f..50d2a81 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_pools.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_pools.c
@@ -76,15 +76,23 @@ vmw_pools_cleanup(struct vmw_winsys_screen *vws)
*
* Typically this pool should be created on demand when we
* detect that the app will be using queries. There's nothing
- * special with this pool other than the backing kernel buffer size,
- * which is limited to 8192.
+ * special with this pool other than the backing kernel buffer sizes,
+ * which are limited to 8192.
+ * If there is a performance issue with allocation and freeing of the
+ * query slabs, it should be easily fixable by allocating them out
+ * of a buffer cache.
*/
boolean
vmw_query_pools_init(struct vmw_winsys_screen *vws)
{
- vws->pools.query_mm = mm_bufmgr_create(vws->pools.gmr,
- VMW_QUERY_POOL_SIZE,
- 3 /* 8 alignment */);
+ struct pb_desc desc;
+
+ desc.alignment = 16;
+ desc.usage = ~(VMW_BUFFER_USAGE_SHARED | VMW_BUFFER_USAGE_SYNC);
+
+ vws->pools.query_mm = pb_slab_range_manager_create(vws->pools.gmr, 16, 128,
+ VMW_QUERY_POOL_SIZE,
+ &desc);
if (!vws->pools.query_mm)
return FALSE;
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] xa: remove unneeded args
On 04/01/2014 05:04 PM, Rob Clark wrote:
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> src/gallium/state_trackers/xa/xa_composite.c | 3 +--
> src/gallium/state_trackers/xa/xa_context.c | 5 +
> src/gallium/state_trackers/xa/xa_priv.h | 3 +--
> src/gallium/state_trackers/xa/xa_renderer.c | 7 ---
> src/gallium/state_trackers/xa/xa_yuv.c | 2 +-
> 5 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xa/xa_composite.c
> b/src/gallium/state_trackers/xa/xa_composite.c
> index f63cf49..19e7309 100644
> --- a/src/gallium/state_trackers/xa/xa_composite.c
> +++ b/src/gallium/state_trackers/xa/xa_composite.c
> @@ -482,8 +482,7 @@ xa_composite_prepare(struct xa_context *ctx,
> return ret;
>
> ctx->dst = dst_srf;
> -renderer_bind_destination(ctx, ctx->srf, ctx->srf->width,
> - ctx->srf->height);
> +renderer_bind_destination(ctx, ctx->srf);
>
> ret = bind_composite_blend_state(ctx, comp);
> if (ret != XA_ERR_NONE)
> diff --git a/src/gallium/state_trackers/xa/xa_context.c
> b/src/gallium/state_trackers/xa/xa_context.c
> index c2dc53b..ee32676 100644
> --- a/src/gallium/state_trackers/xa/xa_context.c
> +++ b/src/gallium/state_trackers/xa/xa_context.c
> @@ -281,7 +281,6 @@ xa_solid_prepare(struct xa_context *ctx, struct
> xa_surface *dst,
> {
> unsigned vs_traits, fs_traits;
> struct xa_shader shader;
> -int width, height;
> int ret;
>
> ret = xa_ctx_srf_create(ctx, dst);
> @@ -295,8 +294,6 @@ xa_solid_prepare(struct xa_context *ctx, struct
> xa_surface *dst,
> ctx->has_solid_color = 1;
>
> ctx->dst = dst;
> -width = ctx->srf->width;
> -height = ctx->srf->height;
>
> #if 0
> debug_printf("Color Pixel=(%d, %d, %d, %d), RGBA=(%f, %f, %f, %f)\n",
> @@ -309,7 +306,7 @@ xa_solid_prepare(struct xa_context *ctx, struct
> xa_surface *dst,
> vs_traits = VS_SOLID_FILL;
> fs_traits = FS_SOLID_FILL;
>
> -renderer_bind_destination(ctx, ctx->srf, width, height);
> +renderer_bind_destination(ctx, ctx->srf);
> bind_solid_blend_state(ctx);
> cso_set_samplers(ctx->cso, PIPE_SHADER_FRAGMENT, 0, NULL);
> cso_set_sampler_views(ctx->cso, PIPE_SHADER_FRAGMENT, 0, NULL);
> diff --git a/src/gallium/state_trackers/xa/xa_priv.h
> b/src/gallium/state_trackers/xa/xa_priv.h
> index 348a98e..15aedb5 100644
> --- a/src/gallium/state_trackers/xa/xa_priv.h
> +++ b/src/gallium/state_trackers/xa/xa_priv.h
> @@ -241,8 +241,7 @@ void renderer_draw_yuv(struct xa_context *r,
> struct xa_surface *srf[]);
>
> void renderer_bind_destination(struct xa_context *r,
> -struct pipe_surface *surface, int width,
> -int height);
> +struct pipe_surface *surface);
>
> void renderer_init_state(struct xa_context *r);
> void renderer_copy_prepare(struct xa_context *r,
> diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
> b/src/gallium/state_trackers/xa/xa_renderer.c
> index 056648a..e1da28c 100644
> --- a/src/gallium/state_trackers/xa/xa_renderer.c
> +++ b/src/gallium/state_trackers/xa/xa_renderer.c
> @@ -351,8 +351,10 @@ setup_vertex_data_yuv(struct xa_context *r,
> */
> void
> renderer_bind_destination(struct xa_context *r,
> - struct pipe_surface *surface, int width, int height)
> + struct pipe_surface *surface)
> {
> +int width = surface->width;
> +int height = surface->height;
>
> struct pipe_framebuffer_state fb;
> struct pipe_viewport_state viewport;
> @@ -461,8 +463,7 @@ renderer_copy_prepare(struct xa_context *r,
> cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
> }
>
> -renderer_bind_destination(r, dst_surface,
> - dst_surface->width, dst_surface->height);
> +renderer_bind_destination(r, dst_surface);
>
> /* texture/sampler view */
> {
> diff --git a/src/gallium/state_trackers/xa/xa_yuv.c
> b/src/gallium/state_trackers/xa/xa_yuv.c
> index 9c7c4d6..43f56ff 100644
> --- a/src/gallium/state_trackers/xa/xa_yuv.c
> +++ b/src/gallium/state_trackers/xa/xa_yuv.c
> @@ -131,7 +131,7 @@ xa_yuv_planar_blit(struct xa_context *r,
> if (ret != XA_ERR_NONE)
> return -XA_ERR_NORES;
>
> -renderer_bind_destination(r, r->srf, r->srf->width, r->srf->height);
> +renderer_bind_destination(r, r->srf);
> xa_yuv_bind_blend_state(r);
> xa_yuv_bind_shaders(r);
> xa_yuv_bind_samplers(r, yuv);
Reviewed-by: Thomas Hellstrom
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] xa: scissor to help tilers
r->dst->tex->width0; > + r->scissor.maxy = r->dst->tex->height0; > +} > + > +r->pipe->set_scissor_states(r->pipe, 0, 1, &r->scissor); > + > cso_set_vertex_elements(r->cso, r->attrs_per_vertex, r->velems); > util_draw_user_vertex_buffer(r->cso, r->buffer, PIPE_PRIM_QUADS, > num_verts, /* verts */ > r->attrs_per_vertex); /* attribs/vert > */ > r->buffer_size = 0; > + > +xa_scissor_reset(r); > } > > static INLINE void > @@ -111,6 +122,7 @@ renderer_init_state(struct xa_context *r) > raster.half_pixel_center = 1; > raster.bottom_edge_rule = 1; > raster.depth_clip = 1; > +raster.scissor = 1; > cso_set_rasterizer(r->cso, &raster); > > /* vertex elements state */ > @@ -359,6 +371,8 @@ renderer_bind_destination(struct xa_context *r, > struct pipe_framebuffer_state fb; > struct pipe_viewport_state viewport; > > +xa_scissor_reset(r); > + > /* Framebuffer uses actual surface width/height > */ > memset(&fb, 0, sizeof fb); Otherwise, Reviewed-by: Thomas Hellstrom ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] xa: reuse surfaces
On 04/01/2014 05:04 PM, Rob Clark wrote:
> From: Rob Clark
>
> Otherwise it will trick the gallium driver into thinking that the render
> target has actually changed (due to different pipe_surface pointing to
> same underlying pipe_resource). This is really badness for tiling GPUs
> like adreno.
Rob, if we want to cache gallium surfaces like this, we need to
condition it on the same context being used.
We can't reuse a surface created with one context for rendering with
another context. (I know the mesa state tracker needs to
fix this up as well).
While this can be done easily within XA for non-shared xa_surfaces, I
wonder what happens in the case of
shared xa_surfaces? More specifically, is rendering allowed to be cached
in the gallium surface until explicitly flushed to the texture? (I'm
unsure about gallium surface semantics here).
/Thomas
> Signed-off-by: Rob Clark
> ---
> src/gallium/state_trackers/xa/xa_context.c | 35
> +++---
> src/gallium/state_trackers/xa/xa_priv.h| 3 ++-
> src/gallium/state_trackers/xa/xa_tracker.c | 1 +
> 3 files changed, 30 insertions(+), 9 deletions(-)
>
> diff --git a/src/gallium/state_trackers/xa/xa_context.c
> b/src/gallium/state_trackers/xa/xa_context.c
> index 867999a..18f0b85 100644
> --- a/src/gallium/state_trackers/xa/xa_context.c
> +++ b/src/gallium/state_trackers/xa/xa_context.c
> @@ -179,6 +179,25 @@ xa_surface_unmap(struct xa_surface *srf)
> }
> }
>
> +static int
> +xa_srf_create(struct xa_context *ctx, struct xa_surface *srf)
> +{
> +struct pipe_screen *screen = ctx->pipe->screen;
> +struct pipe_surface srf_templ;
> +
> +if (!screen->is_format_supported(screen, srf->tex->format,
> + PIPE_TEXTURE_2D, 0,
> + PIPE_BIND_RENDER_TARGET))
> + return -XA_ERR_INVAL;
> +
> +u_surface_default_template(&srf_templ, srf->tex);
> +srf->srf = ctx->pipe->create_surface(ctx->pipe, srf->tex, &srf_templ);
> +if (!srf->srf)
> + return -XA_ERR_NORES;
> +
> +return XA_ERR_NONE;
> +}
> +
> int
> xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
> {
> @@ -188,15 +207,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct
> xa_surface *dst)
> if (ctx->srf)
> return -XA_ERR_INVAL;
>
> -if (!screen->is_format_supported(screen, dst->tex->format,
> - PIPE_TEXTURE_2D, 0,
> - PIPE_BIND_RENDER_TARGET))
> - return -XA_ERR_INVAL;
> +if (!dst->srf) {
> + int ret = xa_srf_create(ctx, dst);
> + if (ret != XA_ERR_NONE)
> + return ret;
> +}
>
> -u_surface_default_template(&srf_templ, dst->tex);
> -ctx->srf = ctx->pipe->create_surface(ctx->pipe, dst->tex, &srf_templ);
> -if (!ctx->srf)
> - return -XA_ERR_NORES;
> +assert(dst->srf);
> +
> +pipe_surface_reference(&ctx->srf, dst->srf);
>
> return XA_ERR_NONE;
> }
> diff --git a/src/gallium/state_trackers/xa/xa_priv.h
> b/src/gallium/state_trackers/xa/xa_priv.h
> index 7a43386..5ade6c1 100644
> --- a/src/gallium/state_trackers/xa/xa_priv.h
> +++ b/src/gallium/state_trackers/xa/xa_priv.h
> @@ -46,7 +46,7 @@
> #define XA_EXPORT
> #endif
>
> -#define XA_VB_SIZE (100 * 4 * 3 * 4)
> +#define XA_VB_SIZE (170 * 4 * 3 * 4)
> #define XA_LAST_SURFACE_TYPE (xa_type_yuv_component + 1)
> #define XA_MAX_SAMPLERS 3
>
> @@ -65,6 +65,7 @@ struct xa_surface {
> struct pipe_resource template;
> struct xa_tracker *xa;
> struct pipe_resource *tex;
> +struct pipe_surface *srf;
> struct pipe_transfer *transfer;
> unsigned int flags;
> struct xa_format_descriptor fdesc;
> diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
> b/src/gallium/state_trackers/xa/xa_tracker.c
> index 9add584..7fed20a 100644
> --- a/src/gallium/state_trackers/xa/xa_tracker.c
> +++ b/src/gallium/state_trackers/xa/xa_tracker.c
> @@ -474,6 +474,7 @@ xa_surface_unref(struct xa_surface *srf)
> if (srf == NULL || --srf->refcount) {
> return;
> }
> +pipe_surface_reference(&srf->srf, NULL);
> pipe_resource_reference(&srf->tex, NULL);
> free(srf);
> }
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] xa: reuse surfaces
On 04/02/2014 04:40 PM, Rob Clark wrote:
> On Wed, Apr 2, 2014 at 3:47 AM, Thomas Hellstrom
> wrote:
>> On 04/01/2014 05:04 PM, Rob Clark wrote:
>>> From: Rob Clark
>>>
>>> Otherwise it will trick the gallium driver into thinking that the render
>>> target has actually changed (due to different pipe_surface pointing to
>>> same underlying pipe_resource). This is really badness for tiling GPUs
>>> like adreno.
>> Rob, if we want to cache gallium surfaces like this, we need to
>> condition it on the same context being used.
>> We can't reuse a surface created with one context for rendering with
>> another context. (I know the mesa state tracker needs to
>> fix this up as well).
> oh.. ugg.. do we have any cases where multiple XA contexts are used?
> Or could we take the easy way out and somehow forbid that?
Hmm. It was designed around the idea of multiple XA contexts so if at
all possible I think we should
continue to allow that..
>
>> While this can be done easily within XA for non-shared xa_surfaces, I
>> wonder what happens in the case of
>> shared xa_surfaces? More specifically, is rendering allowed to be cached
>> in the gallium surface until explicitly flushed to the texture? (I'm
>> unsure about gallium surface semantics here).
> I'm not quite sure either. I need to flush rendering whenever the
> render target actually changes (I'm just trying to prevent flushing
> when the render target doesn't change, but only the pipe_surface ptr
> does). If you are using that surface as a texture, then presumably
> you needed to change the render target.
>
> I'm less sure about other drivers.
>
> I suppose a different approach would simply be to cache the most
> recent pipe_surface. So whenever the render target does actually
> change, we create a new pipe_surface. But we avoid creating a new
> surface for the same render target when it doesn't change.
>
> BR,
> -R
>
>
Something along the line of the attached patch? That would keep a
reference on the destination surface until context destruction, but I
guess the driver would do that anyway, since it's a render target...
/Thomas
>From 26cb8fc9b19c023b5666d1c105888263b0b14d23 Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom
Date: Wed, 2 Apr 2014 19:50:09 +0200
Subject: [PATCH 4/4] st/xa: Cache render target surface
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling GPUs
like adreno.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_context.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_context.c b/src/gallium/state_trackers/xa/xa_context.c
index 867999a..37de45b 100644
--- a/src/gallium/state_trackers/xa/xa_context.c
+++ b/src/gallium/state_trackers/xa/xa_context.c
@@ -78,6 +78,8 @@ xa_context_destroy(struct xa_context *r)
}
xa_ctx_sampler_views_destroy(r);
+if (r->srf)
+pipe_surface_reference(&r->srf, NULL);
if (r->cso) {
cso_release_all(r->cso);
@@ -185,8 +187,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
struct pipe_screen *screen = ctx->pipe->screen;
struct pipe_surface srf_templ;
-if (ctx->srf)
- return -XA_ERR_INVAL;
+/*
+ * Cache surfaces unless we change render target
+ */
+if (ctx->srf) {
+if (ctx->srf->texture == dst->tex)
+return XA_ERR_NONE;
+
+pipe_surface_reference(&ctx->srf, NULL);
+}
if (!screen->is_format_supported(screen, dst->tex->format,
PIPE_TEXTURE_2D, 0,
@@ -204,7 +213,10 @@ xa_ctx_srf_create(struct xa_context *ctx, struct xa_surface *dst)
void
xa_ctx_srf_destroy(struct xa_context *ctx)
{
-pipe_surface_reference(&ctx->srf, NULL);
+/*
+ * Cache surfaces unless we change render target.
+ * Final destruction on context destroy.
+ */
}
XA_EXPORT int
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] xa: handle solid-fill src/mask
On 04/01/2014 05:04 PM, Rob Clark wrote:
> From: Rob Clark
>
> Add support to property handle solid-fill src and/or mask. Without this
> we fallback to sw a lot for common things like text rendering.
>
> Signed-off-by: Rob Clark
> ---
> src/gallium/state_trackers/xa/xa_composite.c | 88
> src/gallium/state_trackers/xa/xa_priv.h | 7 +-
> src/gallium/state_trackers/xa/xa_renderer.c | 289
> ---
> src/gallium/state_trackers/xa/xa_tgsi.c | 31 ++-
> 4 files changed, 242 insertions(+), 173 deletions(-)
Rob,
While testing this patch it looks like we sometimes set two samplers,
and the first one is NULL.
The SVGA driver asserts on that condition.
We might need to move the active sampler to the first entry in that
case, and adjust tex coords and shader accordingly.
I'll discuss with BrianP.
/Thomas
> diff --git a/src/gallium/state_trackers/xa/xa_composite.c
> b/src/gallium/state_trackers/xa/xa_composite.c
> index abe5be2..f63cf49 100644
> --- a/src/gallium/state_trackers/xa/xa_composite.c
> +++ b/src/gallium/state_trackers/xa/xa_composite.c
> @@ -111,12 +111,6 @@ blend_for_op(struct xa_composite_blend *blend,
> boolean supported = FALSE;
>
> /*
> - * Temporarily disable component alpha since it appears buggy.
> - */
> -if (mask_pic && mask_pic->component_alpha)
> - return FALSE;
> -
> -/*
> * our default in case something goes wrong
> */
> *blend = xa_blends[XA_BLEND_OP_OVER];
> @@ -125,6 +119,7 @@ blend_for_op(struct xa_composite_blend *blend,
> if (xa_blends[i].op == op) {
> *blend = xa_blends[i];
> supported = TRUE;
> + break;
> }
> }
>
> @@ -227,14 +222,6 @@ xa_composite_check_accelerated(const struct xa_composite
> *comp)
> if (src_pic->src_pict) {
> if (src_pic->src_pict->type != xa_src_pict_solid_fill)
> return -XA_ERR_INVAL;
> -
> - /*
> - * Currently we don't support solid fill with a mask.
> - * We can easily do that, but that would require shader,
> - * sampler view setup and vertex setup modification.
> - */
> - if (comp->mask)
> - return -XA_ERR_INVAL;
> }
>
> if (blend_for_op(&blend, comp->op, comp->src, comp->mask, comp->dst)) {
> @@ -322,6 +309,12 @@ picture_format_fixups(struct xa_picture *src_pic,
> }
>
> static int
> +is_solid_fill(struct xa_picture *pic)
> +{
> +return pic->src_pict && (pic->src_pict->type == xa_src_pict_solid_fill);
> +}
> +
> +static int
> bind_shaders(struct xa_context *ctx, const struct xa_composite *comp)
> {
> unsigned vs_traits = 0, fs_traits = 0;
> @@ -336,8 +329,8 @@ bind_shaders(struct xa_context *ctx, const struct
> xa_composite *comp)
> fs_traits |= FS_SRC_REPEAT_NONE;
>
> if (src_pic->src_pict) {
> - if (src_pic->src_pict->type == xa_src_pict_solid_fill) {
> - fs_traits |= FS_SOLID_FILL | FS_FILL;
> + if (is_solid_fill(src_pic)) {
> + fs_traits |= FS_SOLID_FILL;
> vs_traits |= VS_SOLID_FILL;
> xa_pixel_to_float4(src_pic->src_pict->solid_fill.color,
> ctx->solid_color);
> @@ -358,9 +351,17 @@ bind_shaders(struct xa_context *ctx, const struct
> xa_composite *comp)
> mask_pic->has_transform)
> fs_traits |= FS_MASK_REPEAT_NONE;
>
> + if (is_solid_fill(mask_pic)) {
> + fs_traits |= FS_SOLID_MASK;
> + vs_traits |= VS_SOLID_MASK;
> + xa_pixel_to_float4(mask_pic->src_pict->solid_fill.color,
> +ctx->solid_mask);
> + ctx->has_solid_mask = TRUE;
> + }
> +
> if (mask_pic->component_alpha) {
> struct xa_composite_blend blend;
> - if (!blend_for_op(&blend, comp->op, src_pic, mask_pic, NULL))
> + if (!blend_for_op(&blend, comp->op, src_pic, mask_pic, comp->dst))
> return -XA_ERR_INVAL;
>
> if (blend.alpha_src) {
> @@ -399,7 +400,7 @@ bind_samplers(struct xa_context *ctx,
> memset(&mask_sampler, 0, sizeof(struct pipe_sampler_state));
>
> if (src_pic) {
> - if (ctx->has_solid_color) {
> + if (is_solid_fill(src_pic)) {
> samplers[0] = NULL;
> pipe_sampler_view_reference(&ctx->bound_sampler_views[0], NULL);
> } else {
> @@ -427,27 +428,31 @@ bind_samplers(struct xa_context *ctx,
> }
>
> if (mask_pic) {
> - unsigned mask_wrap = xa_repeat_to_gallium(mask_pic->wrap);
> - int filter;
> -
> - (void) xa_filter_to_gallium(mask_pic->filter, &filter);
> -
> - mask_sampler.wrap_s = mask_wrap;
> - mask_sampler.wrap_t = mask_wrap;
> - mask_sampler.min_img_filter = filter;
> - mask_sampler.mag_img_filter = filter;
> - src_sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NEAREST;
> - mask_sampler.normalized_coords = 1;
> - samplers[1] = &mask_sampler;
> - ctx->num_bound_samplers = 2;
[Mesa-dev] [PATCH] st/xa: Fix advertized version number and try to avoid future discrepancies
The xa version number had to be set in two places. In configure.ac and in
xa_tracker.h. Furthermore, xa_tracker.h is an installed header so we can't
use mesa internal defines. So therefore, at configure time, modify the
xa_tracker.h header to use the version given by configure.ac
Signed-off-by: Thomas Hellstrom
---
configure.ac |1 +
src/gallium/state_trackers/xa/xa_tracker.h| 200 -
src/gallium/state_trackers/xa/xa_tracker.h.in | 200 +
3 files changed, 201 insertions(+), 200 deletions(-)
delete mode 100644 src/gallium/state_trackers/xa/xa_tracker.h
create mode 100644 src/gallium/state_trackers/xa/xa_tracker.h.in
diff --git a/configure.ac b/configure.ac
index af1b0d1..9b665b0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2055,6 +2055,7 @@ AC_CONFIG_FILES([Makefile
src/gallium/state_trackers/vdpau/Makefile
src/gallium/state_trackers/vega/Makefile
src/gallium/state_trackers/xa/Makefile
+src/gallium/state_trackers/xa/xa_tracker.h
src/gallium/state_trackers/xvmc/Makefile
src/gallium/targets/Makefile
src/gallium/targets/dri-freedreno/Makefile
diff --git a/src/gallium/state_trackers/xa/xa_tracker.h
b/src/gallium/state_trackers/xa/xa_tracker.h
deleted file mode 100644
index 43e56ff..000
--- a/src/gallium/state_trackers/xa/xa_tracker.h
+++ /dev/null
@@ -1,200 +0,0 @@
-/**
- * Copyright 2009-2011 VMware, Inc. All rights reserved.
- *
- * Permission is hereby granted, free of charge, to any person
- * obtaining a copy of this software and associated documentation
- * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use, copy,
- * modify, merge, publish, distribute, sublicense, and/or sell copies
- * of the Software, and to permit persons to whom the Software is
- * furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice shall be
- * included in all copies or substantial portions of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
- * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
- * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
- * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
- * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
- * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
- * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
- * SOFTWARE.
- *
- * The format encoding idea is partially borrowed from libpixman, but it is not
- * considered a "substantial part of the software", so the pixman copyright
- * is left out for simplicity, and acknowledgment is instead given in this way.
- *
- *
- * Authors:
- * Zack Rusin
- * Thomas Hellstrom
- */
-
-#ifndef _XA_TRACKER_H_
-#define _XA_TRACKER_H_
-
-#include
-
-#define XA_TRACKER_VERSION_MAJOR 2
-#define XA_TRACKER_VERSION_MINOR 1
-#define XA_TRACKER_VERSION_PATCH 0
-
-#define XA_FLAG_SHARED (1 << 0)
-#define XA_FLAG_RENDER_TARGET (1 << 1)
-#define XA_FLAG_SCANOUT(1 << 2)
-
-#define XA_MAP_READ (1 << 0)
-#define XA_MAP_WRITE(1 << 1)
-#define XA_MAP_MAP_DIRECTLY (1 << 2)
-#define XA_MAP_UNSYNCHRONIZED (1 << 3)
-#define XA_MAP_DONTBLOCK(1 << 4)
-#define XA_MAP_DISCARD_WHOLE_RESOURCE (1 << 5)
-
-#define XA_ERR_NONE0
-#define XA_ERR_NORES 1
-#define XA_ERR_INVAL 2
-#define XA_ERR_BUSY3
-
-enum xa_surface_type {
-xa_type_other,
-xa_type_a,
-xa_type_argb,
-xa_type_abgr,
-xa_type_bgra,
-xa_type_z,
-xa_type_zs,
-xa_type_sz,
-xa_type_yuv_component
-};
-
-/*
- * Note that these formats should not be assumed to be binary compatible with
- * pixman formats, but with the below macros and a format type map,
- * conversion should be simple. Macros for now. We might replace with
- * inline functions.
- */
-
-#define xa_format(bpp,type,a,r,g,b)(((bpp) << 24) | \
-((type) << 16) | \
-((a) << 12) |\
-((r) << 8) | \
-((g) << 4) | \
-((b)))
-/*
- * Non-RGBA one- and two component formats.
- */
-
-#define xa_format_c(bpp,type,c1,c2) (((bpp) << 24) | \
-((type) << 16) | \
-((c1) << 8) |
Re: [Mesa-dev] [PATCH] st/xa: Fix advertized version number and try to avoid future discrepancies
On 04/03/2014 04:49 PM, Rob Clark wrote: > On Thu, Apr 3, 2014 at 2:05 AM, Thomas Hellstrom > wrote: >> The xa version number had to be set in two places. In configure.ac and in >> xa_tracker.h. Furthermore, xa_tracker.h is an installed header so we can't >> use mesa internal defines. So therefore, at configure time, modify the >> xa_tracker.h header to use the version given by configure.ac >> >> Signed-off-by: Thomas Hellstrom > btw, I was kicking around adding an API to query the actual version at > runtime (in case, for example, I wanted to only attempt to use > composite from DDX with newer XA versions).. > > Probably build-time version checks using the .pc file would be enough, > but I think a run-time version check could turn out to be useful > > BR, > -R > Hi, There's an xa_tracker_version() function that probably can be used for that? BTW, was that a Reviewed-By:? Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 00/10] Map support for GBM bos
NAK! No generic mmap() APIs of GBM bos, please. The reason is that this impossible to implement in an efficient way on non-coherent architectures, and once the interface is there, people will start using it and ignore the non-coherent architectures. And these will, in the end, have to implement a horrendous solution to this problem. This problem has been discussed on the dri-devel list, linaro-mm-sig and on the mesa-list before when the Mir developers attempted to add another variant of an mmap interface. /Thomas On 04/04/2014 10:36 AM, Ander Conselvan de Oliveira wrote: > From: Ander Conselvan de Oliveira > > Changes from previous version: > > - removed the extra gbm egl platform; > > - set errno to ENOSYS when the map/unmap capability is not implemented. > > Thanks, > Ander > > Ander Conselvan de Oliveira (9): > gbm: Set errno on errors > gbm: Move private pointer from gbm_dri_surface to gbm_surface > egl: Protect use of gbm_dri with ifdef HAVE_DRM_PLATFORM > gbm: Add a native intel backend > gbm_drm: Keep a reference to drm native objects > dri, i965: Add an extension for sharing the drm bufmgr > dri, i965: Add entry point for creating image from native handle > egl/drm: Add support for native gbm backends > gbm: Add entry points for mapping and unmapping bos > > Neil Roberts (1): > wayland: Fix the logic in disabling the prime capability > > include/GL/internal/dri_interface.h | 24 ++- > src/egl/drivers/dri2/egl_dri2.c | 11 +- > src/egl/drivers/dri2/egl_dri2.h | 8 +- > src/egl/drivers/dri2/platform_drm.c | 252 -- > src/egl/drivers/dri2/platform_wayland.c | 2 +- > src/gbm/Makefile.am | 14 +- > src/gbm/backends/dri/gbm_dri.c| 49 +++-- > src/gbm/backends/dri/gbm_driint.h | 2 - > src/gbm/backends/intel/gbm_intel.c| 286 > ++ > src/gbm/backends/intel/gbm_intel.h| 76 > src/gbm/main/backend.c| 2 + > src/gbm/main/common_drm.h | 13 ++ > src/gbm/main/gbm.c| 56 +- > src/gbm/main/gbm.h| 10 ++ > src/gbm/main/gbmint.h | 4 + > src/mesa/drivers/dri/common/dri_util.c| 2 + > src/mesa/drivers/dri/common/dri_util.h| 1 + > src/mesa/drivers/dri/i965/intel_regions.c | 50 +++--- > src/mesa/drivers/dri/i965/intel_regions.h | 6 + > src/mesa/drivers/dri/i965/intel_screen.c | 46 - > 20 files changed, 807 insertions(+), 107 deletions(-) > create mode 100644 src/gbm/backends/intel/gbm_intel.c > create mode 100644 src/gbm/backends/intel/gbm_intel.h > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xa: Fix advertized version number and try to avoid future discrepancies
On 04/04/2014 12:13 PM, Emil Velikov wrote: > On 03/04/14 07:05, Thomas Hellstrom wrote: >> The xa version number had to be set in two places. In configure.ac and in >> xa_tracker.h. Furthermore, xa_tracker.h is an installed header so we can't >> use mesa internal defines. So therefore, at configure time, modify the >> xa_tracker.h header to use the version given by configure.ac >> > Can we please keep source files out of autoconf/automake ? It's never a good > idea IMHO. While this works with automake, I'm guessing that it will fail with > scons and the android. > > All that is needed is the three defines to be set by the build scripts - > similar to the way vdpau does it. > > In the long term we can move all the library versions into a centralised place > (perhaps inside the VERSION file) to avoid duplication/miss-match across our > lovely build systems. > > And... seems like I was too late and you've pushed the patch already. > > -Emil > > Hi. Sorry about the breakage here. I'm out of office for the weekend, and can't fix until monday so please revert if you need to. Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: replace sampler assertion with conditional
On 04/04/2014 01:19 AM, Brian Paul wrote:
> For TEX instructions, the set of samplers and sampler views should
> be consistent. The XA state tracker sometimes passes an inconsistent
> set of samplers and sampler views.
I might be wrong, but I don't think the XA tracker sends an inconsistent
set here.
> Rather than assert and die, issue
> a warning.
>
> v2: add debugging code to detect inconsistent state.
> ---
> src/gallium/drivers/svga/svga_state_fs.c | 31
> ++
> 1 file changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_state_fs.c
> b/src/gallium/drivers/svga/svga_state_fs.c
> index 1cdd44f..8837951 100644
> --- a/src/gallium/drivers/svga/svga_state_fs.c
> +++ b/src/gallium/drivers/svga/svga_state_fs.c
> @@ -237,15 +237,38 @@ make_fs_key(const struct svga_context *svga,
> if (svga->curr.blend->need_white_fragments) {
>key->white_fragments = 1;
> }
> -
> +
> +#ifdef DEBUG
> + /*
> +* We expect a consistent set of samplers and sampler views.
> +* Do some debug checks/warnings here.
> +*/
> + {
> + unsigned i, n = MAX2(svga->curr.num_sampler_views,
> + svga->curr.num_samplers);
> + if (svga->curr.num_sampler_views != svga->curr.num_samplers) {
> + debug_printf("svga: mismatched number of sampler views (%u) "
> + "vs. samplers (%u)\n",
> + svga->curr.num_sampler_views,
> + svga->curr.num_samplers);
> + }
> + for (i = 0; i < n; i++) {
> + if ((svga->curr.sampler_views[i] == NULL) !=
> + (svga->curr.sampler[i] == NULL))
> +debug_printf("sampler_view[%u] = %p but sampler[%u] = %p\n",
> + i, svga->curr.sampler_views[i],
> + i, svga->curr.sampler[i]);
> + }
> + }
> +#endif
> +
> /* XXX: want to limit this to the textures that the shader actually
> * refers to.
> *
> * SVGA_NEW_TEXTURE_BINDING | SVGA_NEW_SAMPLER
> */
> for (i = 0; i < svga->curr.num_sampler_views; i++) {
> - if (svga->curr.sampler_views[i]) {
> - assert(svga->curr.sampler[i]);
> + if (svga->curr.sampler_views[i] && svga->curr.sampler[i]) {
> assert(svga->curr.sampler_views[i]->texture);
> key->tex[i].texture_target =
> svga->curr.sampler_views[i]->texture->target;
> if (!svga->curr.sampler[i]->normalized_coords) {
> @@ -264,7 +287,7 @@ make_fs_key(const struct svga_context *svga,
>
> idx = 0;
> for (i = 0; i < svga->curr.num_samplers; ++i) {
> - if (svga->curr.sampler_views[i]) {
> + if (svga->curr.sampler_views[i] && svga->curr.sampler[i]) {
> struct pipe_resource *tex = svga->curr.sampler_views[i]->texture;
> struct svga_texture *stex = svga_texture(tex);
> SVGA3dSurfaceFormat format = stex->key.format;
Looks good otherwise
Reviewed-by: Thomas Hellstrom
/Thomas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] winsys/svga: Update the vmwgfx_drm.h header to latest version from kernel
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmwgfx_drm.h | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
index e42b3f5..73ad205 100644
--- a/src/gallium/winsys/svga/drm/vmwgfx_drm.h
+++ b/src/gallium/winsys/svga/drm/vmwgfx_drm.h
@@ -87,6 +87,16 @@
#define DRM_VMW_PARAM_MAX_SURF_MEMORY 7
#define DRM_VMW_PARAM_3D_CAPS_SIZE 8
#define DRM_VMW_PARAM_MAX_MOB_MEMORY 9
+#define DRM_VMW_PARAM_MAX_MOB_SIZE 10
+
+/**
+ * enum drm_vmw_handle_type - handle type for ref ioctls
+ *
+ */
+enum drm_vmw_handle_type {
+ DRM_VMW_HANDLE_LEGACY = 0,
+ DRM_VMW_HANDLE_PRIME = 1
+};
/**
* struct drm_vmw_getparam_arg
@@ -176,6 +186,7 @@ struct drm_vmw_surface_create_req {
* struct drm_wmv_surface_arg
*
* @sid: Surface id of created surface or surface to destroy or reference.
+ * @handle_type: Handle type for DRM_VMW_REF_SURFACE Ioctl.
*
* Output data from the DRM_VMW_CREATE_SURFACE Ioctl.
* Input argument to the DRM_VMW_UNREF_SURFACE Ioctl.
@@ -184,7 +195,7 @@ struct drm_vmw_surface_create_req {
struct drm_vmw_surface_arg {
int32_t sid;
- uint32_t pad64;
+ enum drm_vmw_handle_type handle_type;
};
/**
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] winsys/svga: Fix prime surface references also for guest-backed surfaces
Implement guest-backed surface sharing using prime fds. Previously only
legacy surfaces could use this functionality. Also use the vmwgfx 2.6
single-ioctl prime fd reference if available.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/winsys/svga/drm/vmw_screen.h | 4 +-
src/gallium/winsys/svga/drm/vmw_screen_dri.c | 7 ++-
src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 76 +-
3 files changed, 81 insertions(+), 6 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen.h
b/src/gallium/winsys/svga/drm/vmw_screen.h
index b68bf43..1a39039 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen.h
+++ b/src/gallium/winsys/svga/drm/vmw_screen.h
@@ -74,6 +74,7 @@ struct vmw_winsys_screen
struct vmw_cap_3d *cap_3d;
uint64_t max_mob_memory;
uint64_t max_surface_memory;
+ boolean have_drm_2_6;
} ioctl;
struct {
@@ -138,10 +139,11 @@ vmw_ioctl_gb_surface_create(struct vmw_winsys_screen *vws,
int
vmw_ioctl_gb_surface_ref(struct vmw_winsys_screen *vws,
- uint32_t handle,
+ const struct winsys_handle *whandle,
SVGA3dSurfaceFlags *flags,
SVGA3dSurfaceFormat *format,
uint32_t *numMipLevels,
+ uint32_t *handle,
struct vmw_region **p_region);
void
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
index 0f5a955..79a1b3e 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c
@@ -183,10 +183,11 @@ vmw_drm_gb_surface_from_handle(struct svga_winsys_screen
*sws,
struct vmw_buffer_desc desc;
struct pb_manager *provider = vws->pools.gmr;
struct pb_buffer *pb_buf;
+uint32_t handle;
int ret;
-ret = vmw_ioctl_gb_surface_ref(vws, whandle->handle, &flags, format,
- &mip_levels, &desc.region);
+ret = vmw_ioctl_gb_surface_ref(vws, whandle, &flags, format,
+ &mip_levels, &handle, &desc.region);
if (ret) {
fprintf(stderr, "Failed referencing shared surface. SID %d.\n"
@@ -209,7 +210,7 @@ vmw_drm_gb_surface_from_handle(struct svga_winsys_screen
*sws,
pipe_reference_init(&vsrf->refcnt, 1);
p_atomic_set(&vsrf->validated, 0);
vsrf->screen = vws;
-vsrf->sid = whandle->handle;
+vsrf->sid = handle;
vsrf->size = vmw_region_size(desc.region);
/*
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index 2866a29..9c0abe9 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -37,6 +37,7 @@
#include "util/u_memory.h"
#include "util/u_math.h"
#include "svgadump/svga_dump.h"
+#include "state_tracker/drm_driver.h"
#include "vmw_screen.h"
#include "vmw_context.h"
#include "vmw_fence.h"
@@ -251,6 +252,63 @@ out_fail_create:
}
/**
+ * vmw_ioctl_surface_req - Fill in a struct surface_req
+ *
+ * @vws: Winsys screen
+ * @whandle: Surface handle
+ * @req: The struct surface req to fill in
+ * @needs_unref: This call takes a kernel surface reference that needs to
+ * be unreferenced.
+ *
+ * Returns 0 on success, negative error type otherwise.
+ * Fills in the surface_req structure according to handle type and kernel
+ * capabilities.
+ */
+static int
+vmw_ioctl_surface_req(const struct vmw_winsys_screen *vws,
+ const struct winsys_handle *whandle,
+ struct drm_vmw_surface_arg *req,
+ boolean *needs_unref)
+{
+ int ret;
+
+ switch(whandle->type) {
+ case DRM_API_HANDLE_TYPE_SHARED:
+ case DRM_API_HANDLE_TYPE_KMS:
+ *needs_unref = FALSE;
+ req->handle_type = DRM_VMW_HANDLE_LEGACY;
+ req->sid = whandle->handle;
+ break;
+ case DRM_API_HANDLE_TYPE_FD:
+ if (!vws->ioctl.have_drm_2_6) {
+ uint32_t handle;
+
+ ret = drmPrimeFDToHandle(vws->ioctl.drm_fd, whandle->handle, &handle);
+ if (ret) {
+vmw_error("Failed to get handle from prime fd %d.\n",
+ (int) whandle->handle);
+return -EINVAL;
+ }
+
+ *needs_unref = TRUE;
+ req->handle_type = DRM_VMW_HANDLE_LEGACY;
+ req->sid = handle;
+ } else {
+ *needs_unref = FALSE;
+ req->handle_type = DRM_VMW_HANDLE_PRIME;
+ req->sid = whandle->handle;
+ }
+ break;
+ default:
+ vmw_error("Attempt to import unsupported handle type %d.\n",
+whandle->type);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
[Mesa-dev] [PATCH] st/xa: Bind destination before setting new state
Binding a new destination may cause the svga driver to emit draw calls
while propagating the surface. Make sure this doesn't happen in the middle
of sampler state setup where state may be incosistent.
In practice, surface propagation should never happen here and even if it did,
it wouldn't be a valid reason for the svga driver to emit partially set up
state, but to avoid future uncertainties, make sure this doesn't happen
anyway.
Found while auditing the state tracker for inconsistent sampler state /
sampler view setup.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_renderer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index b775509..d22851f 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -406,6 +406,9 @@ renderer_copy_prepare(struct xa_context *r,
PIPE_BIND_RENDER_TARGET));
(void)screen;
+renderer_bind_destination(r, dst_surface,
+ dst_surface->width, dst_surface->height);
+
/* set misc state we care about */
{
struct pipe_blend_state blend;
@@ -435,9 +438,6 @@ renderer_copy_prepare(struct xa_context *r,
cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
}
-renderer_bind_destination(r, dst_surface,
- dst_surface->width, dst_surface->height);
-
/* texture/sampler view */
{
struct pipe_sampler_view templ;
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] Revert "st/xa: Fix advertized version number and try to avoid future discrepancies"
On 04/07/2014 02:44 PM, Emil Velikov wrote: > Parsing source files through build systems is never a good idea. > Especially when the issue can be resolved by adding a couple of > definitions to CPPFLAGS via the build system. I've nothing against reverting the commit, but the log message is incorrect, xa_tracker.h is an installed header and thus must include the correct defines. (see my commit message). If we don't parse it using autoconf, we need to use sed or some other tool to fix the header. Otherwise Acked-by: Thomas Hellstrom /Thomas > > This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c. > > Cc: Thomas Hellstrom > --- > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/xa: Move version information into a single place
On 04/07/2014 02:44 PM, Emil Velikov wrote: > Previously the version was specified in configure.ac as well as > one of the xa headers. Thus incleasing the risk of discrepancies > when a developer bumps one but forgets about the other. > > Currently only automake builds the xa state-tracker + targets, > and we should move the version definitions to a build system > independent file (similar to VERSION) once any of the other two > decide to join the fun. > > Cc: Thomas Hellstrom > Signed-off-by: Emil Velikov Hi! nak. The users of libxatracker expects to find those defines in the header. /Thomas > --- > src/gallium/state_trackers/xa/Makefile.am | 6 +- > src/gallium/state_trackers/xa/xa_tracker.h | 4 > 2 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/src/gallium/state_trackers/xa/Makefile.am > b/src/gallium/state_trackers/xa/Makefile.am > index 72486b9..d24fcd4 100644 > --- a/src/gallium/state_trackers/xa/Makefile.am > +++ b/src/gallium/state_trackers/xa/Makefile.am > @@ -26,7 +26,11 @@ include $(top_srcdir)/src/gallium/Automake.inc > AM_CFLAGS = \ > -Wall -pedantic \ > $(GALLIUM_CFLAGS) \ > - $(VISIBILITY_CFLAGS) > + $(VISIBILITY_CFLAGS) \ > + -DXA_TRACKER_VERSION_MAJOR=$(XA_MAJOR) \ > + -DXA_TRACKER_VERSION_MINOR=$(XA_MINOR) \ > + -DXA_TRACKER_VERSION_PATCH=$(XA_TINY) > + > > AM_CPPFLAGS = \ > $(GALLIUM_PIPE_LOADER_DEFINES) \ > diff --git a/src/gallium/state_trackers/xa/xa_tracker.h > b/src/gallium/state_trackers/xa/xa_tracker.h > index 43e56ff..74ee878 100644 > --- a/src/gallium/state_trackers/xa/xa_tracker.h > +++ b/src/gallium/state_trackers/xa/xa_tracker.h > @@ -36,10 +36,6 @@ > > #include > > -#define XA_TRACKER_VERSION_MAJOR 2 > -#define XA_TRACKER_VERSION_MINOR 1 > -#define XA_TRACKER_VERSION_PATCH 0 > - > #define XA_FLAG_SHARED (1 << 0) > #define XA_FLAG_RENDER_TARGET (1 << 1) > #define XA_FLAG_SCANOUT(1 << 2) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] winsys/svga: Update the vmwgfx_drm.h header to latest version from kernel
On 04/07/2014 02:49 PM, Emil Velikov wrote: > On 07/04/14 10:50, Thomas Hellstrom wrote: >> Cc: "10.1" >> Signed-off-by: Thomas Hellstrom > Rather silly question: > > Why do you guys pull this header inside mesa and over using the one provided > by libdrm ? AFAICS every other driver seems to do the latter. Basically to avoid a new release of libdrm when we change the header. There is no other vmware-specific libdrm code... Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Make sure unused samplers are set to NULL
renderer_copy_prepare was setting the first sampler but never telling
the cso code how many samplers were actually used. Fix this.
Cc: "10.1"
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_renderer.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index 9ba78be..bbd35f0 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -422,6 +422,7 @@ renderer_copy_prepare(struct xa_context *r,
/* sampler */
{
struct pipe_sampler_state sampler;
+const struct pipe_sampler_state *p_sampler = &sampler;
memset(&sampler, 0, sizeof(sampler));
sampler.wrap_s = PIPE_TEX_WRAP_CLAMP_TO_EDGE;
@@ -431,8 +432,8 @@ renderer_copy_prepare(struct xa_context *r,
sampler.min_img_filter = PIPE_TEX_FILTER_NEAREST;
sampler.mag_img_filter = PIPE_TEX_FILTER_NEAREST;
sampler.normalized_coords = 1;
- cso_single_sampler(r->cso, PIPE_SHADER_FRAGMENT, 0, &sampler);
- cso_single_sampler_done(r->cso, PIPE_SHADER_FRAGMENT);
+cso_set_samplers(r->cso, PIPE_SHADER_FRAGMENT, 1, &p_sampler);
+r->num_bound_samplers = 1;
}
renderer_bind_destination(r, dst_surface,
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Partially revert "st/xa: Fix advertized version number and try to avoid future discrepancies"
Hi! Thanks, This looks good to me. Reviewed-by: Thomas Hellstrom /Thomas On 04/07/2014 03:45 PM, Emil Velikov wrote: > This reverts commit 61bedc3d6b08943f015f9d590c07a6af36c2a92c. > > As the header is the one defining the API/ABI and is distributed > during installation, we should be using it rather than re-defining > the XA version in configure.ac. > > Bump the version in the header to 2.2.0, to reflect what was the > original intent of commit 42158926c6d7d3ddbe61b9a04d60544ff1b50a96. > > Cc: Thomas Hellstrom > Signed-off-by: Emil Velikov > --- > > Yikes, thanks for the reminder Thomas. > > I've completely missed the "xa_tracker is installed header" part. > > Considering that we already have a cannonical place where the > version is defined, one can simply use it (be that a build system > or not). > > IMHO this approach looks alot better. Hopefully I did not miss > something this time. > > Emil > > configure.ac | 12 +- > src/gallium/state_trackers/xa/xa_tracker.h| 200 > ++ > src/gallium/state_trackers/xa/xa_tracker.h.in | 200 > -- > 3 files changed, 208 insertions(+), 204 deletions(-) > create mode 100644 src/gallium/state_trackers/xa/xa_tracker.h > delete mode 100644 src/gallium/state_trackers/xa/xa_tracker.h.in > > diff --git a/configure.ac b/configure.ac > index ee5c2d1..1a3ef87 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2000,9 +2000,14 @@ AC_SUBST([VDPAU_MINOR], 0) > AC_SUBST([XVMC_MAJOR], 1) > AC_SUBST([XVMC_MINOR], 0) > > -AC_SUBST([XA_MAJOR], 2) > -AC_SUBST([XA_MINOR], 2) > -AC_SUBST([XA_TINY], 0) > +XA_HEADER="$srcdir/src/gallium/state_trackers/xa/xa_tracker.h" > +XA_MAJOR=`grep "#define XA_TRACKER_VERSION_MAJOR" $XA_HEADER | $SED > 's/^#define XA_TRACKER_VERSION_MAJOR //'` > +XA_MINOR=`grep "#define XA_TRACKER_VERSION_MINOR" $XA_HEADER | $SED > 's/^#define XA_TRACKER_VERSION_MINOR //'` > +XA_TINY=`grep "#define XA_TRACKER_VERSION_PATCH" $XA_HEADER | $SED > 's/^#define XA_TRACKER_VERSION_PATCH //'` > + > +AC_SUBST([XA_MAJOR], $XA_MAJOR) > +AC_SUBST([XA_MINOR], $XA_MINOR) > +AC_SUBST([XA_TINY], $XA_TINY) > AC_SUBST([XA_VERSION], "$XA_MAJOR.$XA_MINOR.$XA_TINY") > > dnl Restore LDFLAGS and CPPFLAGS > @@ -2063,7 +2068,6 @@ AC_CONFIG_FILES([Makefile > src/gallium/state_trackers/vdpau/Makefile > src/gallium/state_trackers/vega/Makefile > src/gallium/state_trackers/xa/Makefile > -src/gallium/state_trackers/xa/xa_tracker.h > src/gallium/state_trackers/xvmc/Makefile > src/gallium/targets/Makefile > src/gallium/targets/dri-freedreno/Makefile > diff --git a/src/gallium/state_trackers/xa/xa_tracker.h > b/src/gallium/state_trackers/xa/xa_tracker.h > new file mode 100644 > index 000..5c6435e > --- /dev/null > +++ b/src/gallium/state_trackers/xa/xa_tracker.h > @@ -0,0 +1,200 @@ > +/** > + * Copyright 2009-2011 VMware, Inc. All rights reserved. > + * > + * Permission is hereby granted, free of charge, to any person > + * obtaining a copy of this software and associated documentation > + * files (the "Software"), to deal in the Software without > + * restriction, including without limitation the rights to use, copy, > + * modify, merge, publish, distribute, sublicense, and/or sell copies > + * of the Software, and to permit persons to whom the Software is > + * furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice shall be > + * included in all copies or substantial portions of the Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF > + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS > + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > + * SOFTWARE. > + * > + * The format encoding idea is partially borrowed from libpixman, but it is > not > + * considered a "substantial part of the software", so the pixman copyright > + * is left out for simplicity, and acknowledgment is instead given in this > way. > + * > + * > + * Autho
Re: [Mesa-dev] [PATCH v3 00/11] Map support for GBM
On 04/08/2014 10:28 PM, Ander Conselvan de Oliveira wrote: > From: Ander Conselvan de Oliveira > > Changes from previous version: > > - make it clearer that the interface is optional; No! this is still a NAK! The reason is, just like the last time, that as soon as the major drivers implement this, The users of the interface will stop caring about the "slowpath" (no mmap() available). There are some other good reasons too, like for example the buffers being tiled or uncached. If you desperately need a generic way to access accelerated buffer contents using the CPU, then implement something similar to glTex[sub]Image() or gl[read|write]Pixels. Thanks, /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] xa: handle solid-fill src/mask
On 04/03/2014 04:07 PM, Brian Paul wrote: > On 04/02/2014 11:17 PM, Thomas Hellstrom wrote: >> On 04/01/2014 05:04 PM, Rob Clark wrote: >>> From: Rob Clark >>> >>> Add support to property handle solid-fill src and/or mask. Without >>> this >>> we fallback to sw a lot for common things like text rendering. >>> >>> Signed-off-by: Rob Clark >>> --- >>> src/gallium/state_trackers/xa/xa_composite.c | 88 >>> src/gallium/state_trackers/xa/xa_priv.h | 7 +- >>> src/gallium/state_trackers/xa/xa_renderer.c | 289 >>> --- >>> src/gallium/state_trackers/xa/xa_tgsi.c | 31 ++- >>> 4 files changed, 242 insertions(+), 173 deletions(-) >> >> Rob, >> While testing this patch it looks like we sometimes set two samplers, >> and the first one is NULL. >> The SVGA driver asserts on that condition. >> We might need to move the active sampler to the first entry in that >> case, and adjust tex coords and shader accordingly. >> >> I'll discuss with BrianP. > > I think the root problem is a disagreement between texture samplers > and sampler views. If a texture sampler is non-null, the > corresponding sampler view be should be non-null too, and vice versa. > > We're tripping over an assertion when a a sampler view is non-null but > the corresponding sampler is NULL. > > I'm going to write a patch for the driver to be more resilient in that > situation. > > -Brian Brian, This is a different problem. Here, the state tracker sets up sampler[0] and sampler_view[0] to NULL, but sampler[1] and sampler_view[1] to NON-NULL, but samplers and sampler views are consistent. The question is whether that's OK, or whether that's not allowed. /Thomas > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=VGqKhmPosyC9QpnoVvQFOszMOE3eB%2B956me7wcCEnEs%3D%0A&s=5dd06c74671afd42afbd55b02f0c81895463044783e8d6f7a692963750b02123 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: move LIST_INITHEAD(dirty_buffers) earlier in svga_context_create()
Reviewed-by: Thomas Hellstrom On 04/09/2014 07:40 PM, Brian Paul wrote: > Fixes a crash in svga_context_flush_buffers() if we use the 'draw' module > for AA lines (when the device doesn't support that feature). We need to > initialize this list before we setup the swtnl pieces. > > Found/fixed by Charmaine Lee. > > Cc: "10.0" > --- > src/gallium/drivers/svga/svga_context.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/src/gallium/drivers/svga/svga_context.c > b/src/gallium/drivers/svga/svga_context.c > index 0ba09ce..8389384 100644 > --- a/src/gallium/drivers/svga/svga_context.c > +++ b/src/gallium/drivers/svga/svga_context.c > @@ -123,6 +123,8 @@ struct pipe_context *svga_context_create( struct > pipe_screen *screen, > if (svga == NULL) >goto no_svga; > > + LIST_INITHEAD(&svga->dirty_buffers); > + > svga->pipe.screen = screen; > svga->pipe.priv = priv; > svga->pipe.destroy = svga_destroy; > @@ -185,8 +187,6 @@ struct pipe_context *svga_context_create( struct > pipe_screen *screen, > > svga->dirty = ~0; > > - LIST_INITHEAD(&svga->dirty_buffers); > - > check_for_workarounds(svga); > > return &svga->pipe; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 4/5] st/xa: handle solid-fill src/mask
Hi, Rob! On 04/08/2014 10:48 PM, Rob Clark wrote: > From: Rob Clark > > Add support to property handle solid-fill src and/or mask. Without this > we fallback to sw a lot for common things like text rendering. > > Signed-off-by: Rob Clark > --- > src/gallium/state_trackers/xa/xa_composite.c | 115 +-- > src/gallium/state_trackers/xa/xa_priv.h | 13 +- > src/gallium/state_trackers/xa/xa_renderer.c | 298 > --- > src/gallium/state_trackers/xa/xa_tgsi.c | 36 +++- > 4 files changed, 263 insertions(+), 199 deletions(-) > > diff --git a/src/gallium/state_trackers/xa/xa_composite.c > b/src/gallium/state_trackers/xa/xa_composite.c > index 7ae35a1..b70fd47 100644 > --- a/src/gallium/state_trackers/xa/xa_composite.c > +++ b/src/gallium/state_trackers/xa/xa_composite.c > @@ -111,12 +111,6 @@ blend_for_op(struct xa_composite_blend *blend, > boolean supported = FALSE; > > /* > - * Temporarily disable component alpha since it appears buggy. > - */ > -if (mask_pic && mask_pic->component_alpha) > - return FALSE; > - > -/* > I'll attach the rendercheck logs of two early regression. The first one (log1.txt) happens because we enable component_alpha here. The second one is with component alpha disabled again. /Thomas rendercheck 1.4 Render extension version 0.11 Window format: r8g8b8 Found server-supported format: a8 Found server-supported format: a8r8g8b8 Found server-supported format: x8r8g8b8 Found server-supported format: b8g8r8a8 Found server-supported format: b8g8r8x8 Found server-supported format: r8g8b8 Found server-supported format: b8g8r8 Found server-supported format: r5g5b5 Found server-supported format: b5g5r5 Found server-supported format: x1r5g5b5 Found server-supported format: x1b5g5r5 Found server-supported format: r5g6b5 Found server-supported format: b5g6r5 Found server-supported format: x8b8g8r8 Found server-supported format: x2r10g10b10 Found server-supported format: x2b10g10r10 Beginning testing of filling of 1x1R pictures Beginning testing of filling of 10x10 pictures Beginning dest coords test Beginning src coords test Beginning mask coords test mask coords test error of 32. at (1, 0) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (2, 0) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (3, 0) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (4, 0) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (0, 1) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 64. at (1, 1) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 1.00 1.00 1.00 mask coords test error of 32. at (2, 1) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 64. at (3, 1) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 1.00 1.00 1.00 mask coords test error of 32. at (4, 1) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (0, 2) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 64. at (1, 2) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 1.00 1.00 1.00 mask coords test error of 32. at (2, 2) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 64. at (3, 2) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 1.00 1.00 1.00 mask coords test error of 32. at (4, 2) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (0, 3) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 64. at (1, 3) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 1.00 1.00 1.00 mask coords test error of 64. at (2, 3) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 1.00 1.00 1.00 mask coords test error of 32. at (3, 3) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (4, 3) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (0, 4) -- RGBA got: 0.00 0.00 0.00 1.00 expected: 1.00 0.00 0.00 1.00 mask coords test error of 32. at (1, 4) -- RGBA got:
Re: [Mesa-dev] [PATCH v2 0/5] XA composite and perf improvements and fixes
Hi, Rob, Do you think we can push patches 1 trough 3 with a CC to stable for patch 3? (It for some reason fixes a rendering error with motif on vmwgfx). I'm still looking into patches 4 and 5 to investigate why I get rendering errors. /Thomas On 04/08/2014 10:48 PM, Rob Clark wrote: > From: Rob Clark > > While still more of a stop-gap solution (until glamor) for freedreno, > with these few relatively simple changes I get a pretty big performance > boost (~40%) for xf86-video-freedreno. > > Since the first iteration of these patches, I have: > * re-worked the 'solid-fill src/mask' patch to always use SAMP[0..n] >rather than hard-coding SAMP[0] to src and SAMP[1] to mask (to avoid >having a NULL sampler[0] > * Thomas's version of the 'cache render target surface' patch > * Added a patch to fix some problems with xRGB -> a8 operations > > With this, especially after the 'xrgb->a' patch, rendercheck is at least > not exploding. Some tests are still failing, but that appears to be > freedreno issues which I am still looking into. (Mostly problems with > some oddball formats.) > > Rob Clark (4): > st/xa: remove unneeded args > st/xa: scissor to help tilers > st/xa: handle solid-fill src/mask > st/xa: handle xrgb->a better > > Thomas Hellstrom (1): > st/xa: Cache render target surface > > src/gallium/state_trackers/xa/xa_composite.c | 129 ++- > src/gallium/state_trackers/xa/xa_context.c | 26 ++- > src/gallium/state_trackers/xa/xa_priv.h | 55 - > src/gallium/state_trackers/xa/xa_renderer.c | 319 > --- > src/gallium/state_trackers/xa/xa_tgsi.c | 73 -- > src/gallium/state_trackers/xa/xa_yuv.c | 2 +- > 6 files changed, 380 insertions(+), 224 deletions(-) > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Cache render target surface
Otherwise it will trick the gallium driver into thinking that the render
target has actually changed (due to different pipe_surface pointing to
same underlying pipe_resource). This is really badness for tiling GPUs
like adreno.
This also appears to fix a rendering error with Motif on vmwgfx.
Why that is is still under investigation.
Based on an idea by Rob Clark.
Cc: "10.0 10.1"
Signed-off-by: Thomas Hellstrom
Reviewed-by: Rob Clark
---
src/gallium/state_trackers/xa/xa_context.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_context.c
b/src/gallium/state_trackers/xa/xa_context.c
index 867999a..37de45b 100644
--- a/src/gallium/state_trackers/xa/xa_context.c
+++ b/src/gallium/state_trackers/xa/xa_context.c
@@ -78,6 +78,8 @@ xa_context_destroy(struct xa_context *r)
}
xa_ctx_sampler_views_destroy(r);
+if (r->srf)
+pipe_surface_reference(&r->srf, NULL);
if (r->cso) {
cso_release_all(r->cso);
@@ -185,8 +187,15 @@ xa_ctx_srf_create(struct xa_context *ctx, struct
xa_surface *dst)
struct pipe_screen *screen = ctx->pipe->screen;
struct pipe_surface srf_templ;
-if (ctx->srf)
- return -XA_ERR_INVAL;
+/*
+ * Cache surfaces unless we change render target
+ */
+if (ctx->srf) {
+if (ctx->srf->texture == dst->tex)
+return XA_ERR_NONE;
+
+pipe_surface_reference(&ctx->srf, NULL);
+}
if (!screen->is_format_supported(screen, dst->tex->format,
PIPE_TEXTURE_2D, 0,
@@ -204,7 +213,10 @@ xa_ctx_srf_create(struct xa_context *ctx, struct
xa_surface *dst)
void
xa_ctx_srf_destroy(struct xa_context *ctx)
{
-pipe_surface_reference(&ctx->srf, NULL);
+/*
+ * Cache surfaces unless we change render target.
+ * Final destruction on context destroy.
+ */
}
XA_EXPORT int
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 0/5] XA composite and perf improvements and fixes
On 04/17/2014 12:48 AM, Rob Clark wrote:
> On Wed, Apr 16, 2014 at 9:09 AM, Thomas Hellstrom
> wrote:
>> Hi, Rob,
>>
>> Do you think we can push patches 1 trough 3 with a CC to stable for
>> patch 3?
> yes please.. you can push, or I can.. I was just waiting to hear back
> from you on the later patches. I meant to propose merging the first 3
> but got distracted with other things ;-)
>
>
OK, so I've pushed the three first patches ( I added your reviewed-by on
the third, It looked from our email discussion like you have revied it).
I also took a liberty of reworking the fourth patch a bit. By sending
solid colors to the fragment shader using shader constants the
xa_renderer code becomes a lot nicer. I've attached the patches to this
email. (I have no intentions to "steal" your work so feel free to add
tags or use the code in any way you see fit :) ). I haven't tested
extensively but I don't see the rendercheck errors with these patches. I
still have a rendering problem when enabling solid fills, though, but I
suspect that's a vmwgfx bug.
As for the fifth patch, it seems to me like if the source is xrgb and
the dest is alpha, we could be using a solid fill path with (1, 0, 0, 0)
source color, without alterations to the fragment shader? Likewise if
mask is xrgb and we're not using component alpha, that's equivalent to
no mask regardless of destination?
Thanks
Thomas
>From bfa1e504961e0980bb2b40c1ac271691a2d8aebe Mon Sep 17 00:00:00 2001
From: Thomas Hellstrom
Date: Thu, 17 Apr 2014 08:06:22 +0200
Subject: [PATCH 1/2] st/xa: Enable solid fill with (non-solid) mask
Based on work by Rob Clark.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_composite.c | 94 +++-
src/gallium/state_trackers/xa/xa_context.c | 2 +-
src/gallium/state_trackers/xa/xa_priv.h | 2 +-
src/gallium/state_trackers/xa/xa_renderer.c | 47 --
src/gallium/state_trackers/xa/xa_tgsi.c | 13 ++--
5 files changed, 73 insertions(+), 85 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_composite.c b/src/gallium/state_trackers/xa/xa_composite.c
index 7ae35a1..de57518 100644
--- a/src/gallium/state_trackers/xa/xa_composite.c
+++ b/src/gallium/state_trackers/xa/xa_composite.c
@@ -125,6 +125,7 @@ blend_for_op(struct xa_composite_blend *blend,
if (xa_blends[i].op == op) {
*blend = xa_blends[i];
supported = TRUE;
+ break;
}
}
@@ -224,18 +225,12 @@ xa_composite_check_accelerated(const struct xa_composite *comp)
}
-if (src_pic->src_pict) {
- if (src_pic->src_pict->type != xa_src_pict_solid_fill)
+if (src_pic->src_pict && src_pic->src_pict->type != xa_src_pict_solid_fill)
return -XA_ERR_INVAL;
- /*
- * Currently we don't support solid fill with a mask.
- * We can easily do that, but that would require shader,
- * sampler view setup and vertex setup modification.
- */
- if (comp->mask)
- return -XA_ERR_INVAL;
-}
+/* No solid masks for now. */
+if (comp->mask && comp->mask->src_pict)
+return -XA_ERR_INVAL;
if (blend_for_op(&blend, comp->op, comp->src, comp->mask, comp->dst)) {
struct xa_picture *mask = comp->mask;
@@ -337,7 +332,7 @@ bind_shaders(struct xa_context *ctx, const struct xa_composite *comp)
if (src_pic->src_pict) {
if (src_pic->src_pict->type == xa_src_pict_solid_fill) {
- fs_traits |= FS_SOLID_FILL | FS_FILL;
+ fs_traits |= FS_SOLID_FILL;
vs_traits |= VS_SOLID_FILL;
xa_pixel_to_float4(src_pic->src_pict->solid_fill.color,
ctx->solid_color);
@@ -392,38 +387,32 @@ bind_samplers(struct xa_context *ctx,
struct pipe_context *pipe = ctx->pipe;
struct xa_picture *src_pic = comp->src;
struct xa_picture *mask_pic = comp->mask;
+int num_samplers = 0;
-ctx->num_bound_samplers = 0;
-
+xa_ctx_sampler_views_destroy(ctx);
memset(&src_sampler, 0, sizeof(struct pipe_sampler_state));
memset(&mask_sampler, 0, sizeof(struct pipe_sampler_state));
-if (src_pic) {
- if (ctx->has_solid_color) {
- samplers[0] = NULL;
- pipe_sampler_view_reference(&ctx->bound_sampler_views[0], NULL);
- } else {
- unsigned src_wrap = xa_repeat_to_gallium(src_pic->wrap);
- int filter;
-
- (void) xa_filter_to_gallium(src_pic->filter, &filter);
-
- src_sampler.wrap_s = src_wrap;
- src_sampler.wrap_t = src_wrap;
- src_sampler.min_img_filter = filter;
- src_sampler.mag_img_filter = filter;
- src_sampler.min_mip_filter = PIPE_TEX_MIPFILTER_NEAREST;
- src_sampler.normalized_coords = 1;
- samplers[0] = &src_sampler;
- ctx->num_bound_samplers = 1;
- u_sampler_view_default_template(&view_templ,
- src_pic->srf->tex,
- src_pic->srf->tex-&
Re: [Mesa-dev] [PATCH v3 00/11] Map support for GBM
On 04/25/2014 11:36 PM, Kristian Høgsberg wrote: > On Tue, Apr 8, 2014 at 1:49 PM, Thomas Hellstrom > wrote: >> On 04/08/2014 10:28 PM, Ander Conselvan de Oliveira wrote: >>> From: Ander Conselvan de Oliveira >>> >>> Changes from previous version: >>> >>> - make it clearer that the interface is optional; >> No! this is still a NAK! > I don't agree with your NAK, Thomas. We can't write APIs that only > supports what every graphics card out there can do. GL itself is a > good example of how functionality or fast-paths can be made available > in an optional way through extensions. In this case, we're missing > out on a zero-copy path for texturing from a sw-rendered buffer. The > intended usecase is for one process to use gbm (that is, not loading a > GL driver or using GL API) to allocate a buffer and render to it using > CPU rendering. Then share it by passing a dma-buf fd across a socket > to a GL-using process, which will then be able to create a GL texture > from it and texture from it. Yes. I'm aware about the use case. But GL extensions typically go through some form of review and issues brought up are usually resolved. In this particular case, this extension, while enabling a fastpath (which is good), may cause lazily written apps to be unusable on incoherent architectures (which is very bad. In particular for vmware), see [1]. If we take GL as an example, traditionally mapping and unmapping had to be done on buffer objects, and then transferred to the render buffer using some form of unpacking. I think this enables smart drivers to do a zero-copy upload, as well as providing a damage region (using writepixels / texSubImage) for incoherent / tiled architectures. The buffer object usage type is specified so that the driver can choose the type of caching. (Should the software writer be able to read from the buffer with any performance for example?). This issue has been brought up many times before, also in the context of dma-buf mmap / unmaps (it's exactly the same issue), and at some point is has to be resolved. So far nobody has wanted it badly enough to specify a decent API, and such an API would IMO need to deal with * Buffer usage (write, read, read/write etc.) * Specifying damage regions (before read and after write) for incoherent and tiled architectures. That way the API would force app writers to think also about the slowpath while fully enabling the zero-copy fastpath. > >> The reason is, just like the last time, that as soon as the major >> drivers implement this, The users of the interface will stop caring >> about the "slowpath" (no mmap() available). There are some other good >> reasons too, like for example the buffers being tiled or uncached. >> >> If you desperately need a generic way to access accelerated buffer >> contents using the CPU, then implement something similar to >> glTex[sub]Image() or gl[read|write]Pixels. > The semantics of the map/unmap API is that unmap acts as a flush and > the pixels in the mapped buffer aren't guaranteed to be visible to > other users of the gbm bo until after map. That lets you implement > map as a malloc and unmap as glTexImage2D + free. Which is the path > the application would have to fall back to anyway. But instead of > forcing everybody to go through the copy path (as we would if we > implemented something like glTexImage2D in gbm), we now have the > option of eliminating the copy when the underlying GPU architecture > allows it. [1] Yes, but the problem is when someone allocs a 1600x1200 bo, maps it and writes a single character. Then unmaps it and textures from it. We all know that eventually there will be apps out there that does this, and that also couldn't care less about the slow-path (non-zero copy). The app will crawl on any non-coherent architecture. So in this case, with this interface, I think the NAK is very well justified. At least for the API in its current form. /Thomas > > Kristian > >> Thanks, >> /Thomas >> >> >> >> ___ >> mesa-dev mailing list >> mesa-dev@lists.freedesktop.org >> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=odFlWkDI%2BmOWVatvfBb6%2B%2BwJ0wfBvjphI%2FNXAVVJGBQ%3D%0A&s=b566a35c98538f7394cb4bfc2741bd38af1ba4f2f351a695ca6417b09563c6bd ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Fix performance regression introduced by commit "Cache render target surface"
The mentioned commit has the nasty side-effect of turning off accelerated
copies.
Cc: "10.1 10.2"
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_context.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/state_trackers/xa/xa_context.c
b/src/gallium/state_trackers/xa/xa_context.c
index 37de45b..df3043c 100644
--- a/src/gallium/state_trackers/xa/xa_context.c
+++ b/src/gallium/state_trackers/xa/xa_context.c
@@ -223,7 +223,7 @@ XA_EXPORT int
xa_copy_prepare(struct xa_context *ctx,
struct xa_surface *dst, struct xa_surface *src)
{
-if (src == dst || ctx->srf != NULL)
+if (src == dst)
return -XA_ERR_INVAL;
if (src->tex->format != dst->tex->format) {
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 10.1.2
Carl, Unfortunately a pretty bad problem made it into the XA state tracker in 10.1.2 with commit "Cache render target surface" and it was just fixed in master with commit 9306b7c171b29ac99f837e9efcd0281caf1d332e. It makes vmware swapbuffers fall back to software. The reason it was CC'd stable was that it appeared to fix a rendering problem that we were seeing, but I should definitely have tested this more thoroughly. :( An unfortunate situation but the sooner we could cut a 10.1.3 release including 9306b7c171b29ac99f837e9efcd0281caf1d332e, the better for us. In the meantime we will have to ask distros that adopt 10.1.2 to cherry-pick this commit. Thanks, Thomas On 05/05/2014 10:04 PM, Carl Worth wrote: > Mesa 10.1.2 has been released. Mesa 10.1.2 is a bug fix release which > fixes bugs fixed since the 10.1.1 release, (see below for a list of > changes). > > The tag in the git repository for Mesa 10.1.2 is 'mesa-10.1.2'. > > Mesa 10.1.2 is available for download at > https://urldefense.proofpoint.com/v1/url?u=ftp://freedesktop.org/pub/mesa/10.1.2/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=Fj%2BPgRozQOZrS%2BG74sAmfMnf0xOaVyv9PtCX4FQ%2BYGA%3D%0A&s=6154e726f586e3cb0f913b306fe57db769d81ffa47fb4988f51d131fe37c58c7 > > md5sums: > 37d79f94b1f41852a89d1fc3900bea76 MesaLib-10.1.2.tar.gz > 28b60d15ac9f364da1e0155911eaf44e MesaLib-10.1.2.tar.bz2 > 05300039085a65fc53c5472c4bb5747a MesaLib-10.1.2.zip > > I have verified building from the .tar.bz2 file by doing: > > tar xjf MesaLib-10.1.2.tar.bz2 > cd Mesa-10.1.2 > ./configure --enable-gallium-llvm > make -j6 > make install > > I have also verified that I pushed the tag. > > -Carl > > > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=l5Ago9ekmVFZ3c4M6eauqrJWGwjf6fTb%2BP3CxbBFkVM%3D%0A&m=Fj%2BPgRozQOZrS%2BG74sAmfMnf0xOaVyv9PtCX4FQ%2BYGA%3D%0A&s=33f0e7f6a4c35dba2710051c12122b1313af9af0aec983f8d8349690dd04b23a ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] targets/xa: limit the amount of exported symbols
Hi, I'm on vacation, so I have no way of testing this until next week.
/Thomas
On 05/14/2014 02:04 PM, Emil Velikov wrote:
> ping for the series
>
> If there is no objections I would like to push these over the weekend.
>
> Cheers,
> Emil
> On 09/05/14 18:10, Emil Velikov wrote:
>> ping
>>
>> Thomas, Rob,
>> Can you please take a look if the patch makes sense ? I have double checked
>> that only the required functions are exported although I may have missed
>> something. IMHO you both know XA API a lot better than me :)
>>
>> Thanks
>> Emil
>>
>> On 02/05/14 22:02, Emil Velikov wrote:
>>> In the presence of LLVM the final library exports every symbol from
>>> the llvm namespace. Resolve this by using a version script (w/o the
>>> version/name tag).
>>>
>>> Considering that there are only ~35 symbols, explicitly list them
>>> to minimize the chances of rogue symbols sneaking in.
>>>
>>> Signed-off-by: Emil Velikov
>>> ---
>>> src/gallium/targets/xa/Makefile.am | 1 +
>>> src/gallium/targets/xa/xa.sym | 38
>>> ++
>>> 2 files changed, 39 insertions(+)
>>> create mode 100644 src/gallium/targets/xa/xa.sym
>>>
>>> diff --git a/src/gallium/targets/xa/Makefile.am
>>> b/src/gallium/targets/xa/Makefile.am
>>> index 2619e57..17cd6c4 100644
>>> --- a/src/gallium/targets/xa/Makefile.am
>>> +++ b/src/gallium/targets/xa/Makefile.am
>>> @@ -63,6 +63,7 @@ endif
>>> libxatracker_la_LDFLAGS = \
>>> -no-undefined \
>>> -version-number $(XA_MAJOR):$(XA_MINOR):$(XA_TINY) \
>>> + -Wl,--version-script=$(top_srcdir)/src/gallium/targets/xa/xa.sym \
>>> $(GC_SECTIONS) \
>>> $(LD_NO_UNDEFINED)
>>>
>>> diff --git a/src/gallium/targets/xa/xa.sym b/src/gallium/targets/xa/xa.sym
>>> new file mode 100644
>>> index 000..9c7f422
>>> --- /dev/null
>>> +++ b/src/gallium/targets/xa/xa.sym
>>> @@ -0,0 +1,38 @@
>>> +{
>>> + global:
>>> + xa_composite_allocation;
>>> + xa_composite_check_accelerated;
>>> + xa_composite_done;
>>> + xa_composite_prepare;
>>> + xa_composite_rect;
>>> + xa_context_create;
>>> + xa_context_default;
>>> + xa_context_destroy;
>>> + xa_context_flush;
>>> + xa_copy;
>>> + xa_copy_done;
>>> + xa_copy_prepare;
>>> + xa_fence_get;
>>> + xa_fence_wait;
>>> + xa_fence_destroy;
>>> + xa_format_check_supported;
>>> + xa_solid;
>>> + xa_solid_done;
>>> + xa_solid_prepare;
>>> + xa_surface_create;
>>> + xa_surface_dma;
>>> + xa_surface_format;
>>> + xa_surface_from_handle;
>>> + xa_surface_handle;
>>> + xa_surface_map;
>>> + xa_surface_redefine;
>>> + xa_surface_ref;
>>> + xa_surface_unmap;
>>> + xa_surface_unref;
>>> + xa_tracker_create;
>>> + xa_tracker_destroy;
>>> + xa_tracker_version;
>>> + xa_yuv_planar_blit;
>>> + local:
>>> + *;
>>> +};
>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] targets/xa: limit the amount of exported symbols
Reviewed-by: Thomas Hellstrom
On 05/02/2014 10:02 PM, Emil Velikov wrote:
> In the presence of LLVM the final library exports every symbol from
> the llvm namespace. Resolve this by using a version script (w/o the
> version/name tag).
>
> Considering that there are only ~35 symbols, explicitly list them
> to minimize the chances of rogue symbols sneaking in.
>
> Signed-off-by: Emil Velikov
> ---
> src/gallium/targets/xa/Makefile.am | 1 +
> src/gallium/targets/xa/xa.sym | 38
> ++
> 2 files changed, 39 insertions(+)
> create mode 100644 src/gallium/targets/xa/xa.sym
>
> diff --git a/src/gallium/targets/xa/Makefile.am
> b/src/gallium/targets/xa/Makefile.am
> index 2619e57..17cd6c4 100644
> --- a/src/gallium/targets/xa/Makefile.am
> +++ b/src/gallium/targets/xa/Makefile.am
> @@ -63,6 +63,7 @@ endif
> libxatracker_la_LDFLAGS = \
> -no-undefined \
> -version-number $(XA_MAJOR):$(XA_MINOR):$(XA_TINY) \
> + -Wl,--version-script=$(top_srcdir)/src/gallium/targets/xa/xa.sym \
> $(GC_SECTIONS) \
> $(LD_NO_UNDEFINED)
>
> diff --git a/src/gallium/targets/xa/xa.sym b/src/gallium/targets/xa/xa.sym
> new file mode 100644
> index 000..9c7f422
> --- /dev/null
> +++ b/src/gallium/targets/xa/xa.sym
> @@ -0,0 +1,38 @@
> +{
> + global:
> + xa_composite_allocation;
> + xa_composite_check_accelerated;
> + xa_composite_done;
> + xa_composite_prepare;
> + xa_composite_rect;
> + xa_context_create;
> + xa_context_default;
> + xa_context_destroy;
> + xa_context_flush;
> + xa_copy;
> + xa_copy_done;
> + xa_copy_prepare;
> + xa_fence_get;
> + xa_fence_wait;
> + xa_fence_destroy;
> + xa_format_check_supported;
> + xa_solid;
> + xa_solid_done;
> + xa_solid_prepare;
> + xa_surface_create;
> + xa_surface_dma;
> + xa_surface_format;
> + xa_surface_from_handle;
> + xa_surface_handle;
> + xa_surface_map;
> + xa_surface_redefine;
> + xa_surface_ref;
> + xa_surface_unmap;
> + xa_surface_unref;
> + xa_tracker_create;
> + xa_tracker_destroy;
> + xa_tracker_version;
> + xa_yuv_planar_blit;
> + local:
> + *;
> +};
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] winsys/svga: Avoid calling drm getparam for max surface size on older kernels
This avoids the kernel driver spewing out errors about the param not being
supported.
Also correct the max surface size used when the kernel does not support the
query.
Reported-by: Brian Paul
Signed-off-by: Thomas Hellstrom
Reviewed-by: Charmaine Lee
Cc: "10.1"
---
src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index b7bedb1..2866a29 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -762,7 +762,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
int ret;
uint32_t *cap_buffer;
drmVersionPtr version;
- boolean drm_gb_capable;
+ boolean have_drm_2_5;
VMW_FUNC;
@@ -770,7 +770,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
if (!version)
goto out_no_version;
- drm_gb_capable = version->version_major > 2 ||
+ have_drm_2_5 = version->version_major > 2 ||
(version->version_major == 2 && version->version_minor > 4);
memset(&gp_arg, 0, sizeof(gp_arg));
@@ -803,7 +803,7 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
vws->base.have_gb_objects =
!!(gp_arg.value & (uint64_t) SVGA_CAP_GBOBJECTS);
- if (vws->base.have_gb_objects && !drm_gb_capable)
+ if (vws->base.have_gb_objects && !have_drm_2_5)
goto out_no_3d;
if (vws->base.have_gb_objects) {
@@ -839,11 +839,12 @@ vmw_ioctl_init(struct vmw_winsys_screen *vws)
memset(&gp_arg, 0, sizeof(gp_arg));
gp_arg.param = DRM_VMW_PARAM_MAX_SURF_MEMORY;
- ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM,
-&gp_arg, sizeof(gp_arg));
- if (ret) {
+ if (have_drm_2_5)
+ ret = drmCommandWriteRead(vws->ioctl.drm_fd, DRM_VMW_GET_PARAM,
+ &gp_arg, sizeof(gp_arg));
+ if (!have_drm_2_5 || ret) {
/* Just guess a large enough value, around 800mb. */
- vws->ioctl.max_surface_memory = 0x3;
+ vws->ioctl.max_surface_memory = 0x3000;
} else {
vws->ioctl.max_surface_memory = gp_arg.value;
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: remove SVGA_RELOC_READ flag in SVGA3D_BindGBSurface()
On Thu, 2019-03-07 at 19:45 -0700, Brian Paul wrote: > This fixes a rendering issue where UBO updates aren't always picked > up by drawing calls. This issue effected the Webots robotics > simulator. VMware bug 2175527. > > Testing Done: Webots replay, piglit, misc Linux games > --- > src/gallium/drivers/svga/svga_cmd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/gallium/drivers/svga/svga_cmd.c > b/src/gallium/drivers/svga/svga_cmd.c > index 5557d20..6577c83 100644 > --- a/src/gallium/drivers/svga/svga_cmd.c > +++ b/src/gallium/drivers/svga/svga_cmd.c > @@ -1693,7 +1693,7 @@ SVGA3D_BindGBSurface(struct svga_winsys_context > *swc, >return PIPE_ERROR_OUT_OF_MEMORY; > > swc->surface_relocation(swc, &cmd->sid, &cmd->mobid, surface, > - SVGA_RELOC_READ | SVGA_RELOC_INTERNAL); > + SVGA_RELOC_READ); > > swc->commit(swc); > Reviewed-by: Thomas Hellström ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] winsys/svga: use new pb_usage_flags enum type
On Tue, 2019-03-05 at 20:48 -0700, Brian Paul wrote:
> And add a comment that we're implicitly converting PIPE_TRANSFER_
> flags to PB_USAGE_ flags in one place. And statically assert that
> the enum values match.
LGTM. Thanks for fixing this!
Reviewed-by: Thomas Hellstrom
> ---
> src/gallium/winsys/svga/drm/vmw_buffer.c | 27
> +++
> src/gallium/winsys/svga/drm/vmw_buffer.h | 1 +
> src/gallium/winsys/svga/drm/vmw_context.c | 4 ++--
> 3 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.c
> b/src/gallium/winsys/svga/drm/vmw_buffer.c
> index 3ac80c7..91b5b25 100644
> --- a/src/gallium/winsys/svga/drm/vmw_buffer.c
> +++ b/src/gallium/winsys/svga/drm/vmw_buffer.c
> @@ -90,6 +90,11 @@ static inline struct vmw_gmr_bufmgr *
> vmw_gmr_bufmgr(struct pb_manager *mgr)
> {
> assert(mgr);
> +
> + /* Make sure our extra flags don't collide with pipebuffer's
> flags */
> + STATIC_ASSERT((VMW_BUFFER_USAGE_SHARED & PB_USAGE_ALL) == 0);
> + STATIC_ASSERT((VMW_BUFFER_USAGE_SYNC & PB_USAGE_ALL) == 0);
> +
> return (struct vmw_gmr_bufmgr *)mgr;
> }
>
> @@ -109,7 +114,7 @@ vmw_gmr_buffer_destroy(struct pb_buffer *_buf)
>
> static void *
> vmw_gmr_buffer_map(struct pb_buffer *_buf,
> - unsigned flags,
> + enum pb_usage_flags flags,
> void *flush_ctx)
> {
> struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
> @@ -140,7 +145,7 @@ static void
> vmw_gmr_buffer_unmap(struct pb_buffer *_buf)
> {
> struct vmw_gmr_buffer *buf = vmw_gmr_buffer(_buf);
> - unsigned flags = buf->map_flags;
> + enum pb_usage_flags flags = buf->map_flags;
>
> if ((_buf->usage & VMW_BUFFER_USAGE_SYNC) &&
> !(flags & PB_USAGE_UNSYNCHRONIZED)) {
> @@ -164,7 +169,7 @@ vmw_gmr_buffer_get_base_buffer(struct pb_buffer
> *buf,
> static enum pipe_error
> vmw_gmr_buffer_validate( struct pb_buffer *_buf,
> struct pb_validate *vl,
> - unsigned flags )
> + enum pb_usage_flags flags )
> {
> /* Always pinned */
> return PIPE_OK;
> @@ -338,7 +343,7 @@ vmw_svga_winsys_buffer_destroy(struct
> svga_winsys_screen *sws,
> void *
> vmw_svga_winsys_buffer_map(struct svga_winsys_screen *sws,
> struct svga_winsys_buffer *buf,
> - unsigned flags)
> + enum pipe_transfer_usage flags)
> {
> void *map;
>
> @@ -346,6 +351,20 @@ vmw_svga_winsys_buffer_map(struct
> svga_winsys_screen *sws,
> if (flags & PIPE_TRANSFER_UNSYNCHRONIZED)
>flags &= ~PIPE_TRANSFER_DONTBLOCK;
>
> + /* NOTE: we're passing PIPE_TRANSFER_x flags instead of
> +* PB_USAGE_x flags here. We should probably fix that.
> +*/
> + STATIC_ASSERT((unsigned) PB_USAGE_CPU_READ ==
> + (unsigned) PIPE_TRANSFER_READ);
> + STATIC_ASSERT((unsigned) PB_USAGE_CPU_WRITE ==
> + (unsigned) PIPE_TRANSFER_WRITE);
> + STATIC_ASSERT((unsigned) PB_USAGE_GPU_READ ==
> + (unsigned) PIPE_TRANSFER_MAP_DIRECTLY);
> + STATIC_ASSERT((unsigned) PB_USAGE_DONTBLOCK ==
> + (unsigned) PIPE_TRANSFER_DONTBLOCK);
> + STATIC_ASSERT((unsigned) PB_USAGE_UNSYNCHRONIZED ==
> + (unsigned) PIPE_TRANSFER_UNSYNCHRONIZED);
> +
> map = pb_map(vmw_pb_buffer(buf), flags, NULL);
>
> #ifdef DEBUG
> diff --git a/src/gallium/winsys/svga/drm/vmw_buffer.h
> b/src/gallium/winsys/svga/drm/vmw_buffer.h
> index 6e1151e..8ed56d4 100644
> --- a/src/gallium/winsys/svga/drm/vmw_buffer.h
> +++ b/src/gallium/winsys/svga/drm/vmw_buffer.h
> @@ -33,6 +33,7 @@
> #include "util/u_debug_flush.h"
>
>
> +/* These extra flags are used wherever the pb_usage_flags enum type
> is used */
> #define VMW_BUFFER_USAGE_SHARED(1 << 20)
> #define VMW_BUFFER_USAGE_SYNC (1 << 21)
>
> diff --git a/src/gallium/winsys/svga/drm/vmw_context.c
> b/src/gallium/winsys/svga/drm/vmw_context.c
> index c0ee833..59963ff 100644
> --- a/src/gallium/winsys/svga/drm/vmw_context.c
> +++ b/src/gallium/winsys/svga/drm/vmw_context.c
> @@ -161,10 +161,10 @@ vmw_svga_winsys_context(struct
> svga_winsys_context *swc)
> }
>
>
> -static inline unsigned
> +static inline enum pb_usage_flags
> vmw_translate_to_pb_flags(unsigned flags)
> {
> - unsigned f = 0;
> + enum pb_usage_flags f = 0;
> if (flags & SVGA_RELOC_READ)
>f |= PB_USAGE_GPU_READ;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa-stable] [PATCH] xa: add xa_surface_from_handle2
On 09/01/2015 03:49 PM, Emil Velikov wrote: > Hi all, > > On 1 August 2015 at 20:40, Thomas Hellstrom wrote: >> Hi! >> >> On 08/01/2015 07:16 PM, Emil Velikov wrote: >>> On 22 July 2015 at 00:00, Rob Clark wrote: >>>> From: Rob Clark >>>> >>>> Like xa_surface_from_handle(), but takes a handle type, rather than >>>> hard-coding 'shared' handle. This is needed to fix bugs seen with >>>> xf86-video-freedreno with xrandr rotation, for example. The root issue >>>> is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle >>>> associated with the drm_file will result in two unique handles for the >>>> same bo. Which causes all sorts of follow-on fail. >>>> >>>> Cc: "10.5 10.6" >>>> Signed-off-by: Rob Clark >>>> --- >>>> Note: it would be good to get this in stable too, since I have a patch >>>> for xf86-video-freedreno which will depend on this. >>>> >>> Bth, I'm not too excited about having new APIs in the stable branch, >>> despite them being trivial as this one. >>> Regardless it would be nice to get a pair of eyes looking in this direction. >>> >>> The patch does exactly what it says on the tin, although I do wonder >>> if we should bump XA_TRACKER_VERSION_MINOR ? >> I haven't had time yet to look at the patch itself (I'm on vacation and >> back next week), but having XA recognize handle types, in particular >> dma-buf fds is, IMO a good thing. >> >> Regarding adding new interfaces to XA, the XA documentation is pretty >> explicit about how this should be handled and recognized, with version >> numbers. As long as all XA users follow this, it should be pretty >> straightforward also in a stable mesa branch. IIRC, the XA minor must be >> bumped in this case, and an out-of-mesa-tree user can't rely on the >> symbol being present, since an old libxatracker with the same major >> number might be present, but needs to use dlsym() or something similar. >> > Rob, Thomas do you plan on picking this up and addressing the final bits ? > > -Emil Hi! we'll need this for dri3 support in vmwgfx but for us there's no need to take it through stable. Rob, are you going for glamor or do you need this for stable? Thanks, Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] xa: add xa_surface_from_handle2 v2
From: Rob Clark
Like xa_surface_from_handle(), but takes a handle type, rather than
hard-coding 'shared' handle. This is needed to fix bugs seen with
xf86-video-freedreno with xrandr rotation, for example. The root issue
is that doing a GEM_OPEN ioctl on a bo that already has a GEM handle
associated with the drm_file will result in two unique handles for the
same bo. Which causes all sorts of follow-on fail.
v2:
- Add support for for fd handles.
- Avoid duplicating code.
- Bump xa version minor.
Signed-off-by: Rob Clark
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_tracker.c | 41 ++
src/gallium/state_trackers/xa/xa_tracker.h | 14 +-
src/gallium/targets/xa/xa.sym | 1 +
3 files changed, 45 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
b/src/gallium/state_trackers/xa/xa_tracker.c
index 21ca57c..2944b16 100644
--- a/src/gallium/state_trackers/xa/xa_tracker.c
+++ b/src/gallium/state_trackers/xa/xa_tracker.c
@@ -298,6 +298,20 @@ xa_format_check_supported(struct xa_tracker *xa,
return XA_ERR_NONE;
}
+static unsigned
+handle_type(enum xa_handle_type type)
+{
+switch (type) {
+case xa_handle_type_kms:
+ return DRM_API_HANDLE_TYPE_KMS;
+case xa_handle_type_fd:
+return DRM_API_HANDLE_TYPE_FD;
+case xa_handle_type_shared:
+default:
+ return DRM_API_HANDLE_TYPE_SHARED;
+}
+}
+
static struct xa_surface *
surface_create(struct xa_tracker *xa,
int width,
@@ -380,9 +394,24 @@ xa_surface_from_handle(struct xa_tracker *xa,
enum xa_formats xa_format, unsigned int flags,
uint32_t handle, uint32_t stride)
{
+return xa_surface_from_handle2(xa, width, height, depth, stype, xa_format,
+ DRM_API_HANDLE_TYPE_SHARED, flags, handle,
+ stride);
+}
+
+XA_EXPORT struct xa_surface *
+xa_surface_from_handle2(struct xa_tracker *xa,
+int width,
+int height,
+int depth,
+enum xa_surface_type stype,
+enum xa_formats xa_format, unsigned int flags,
+enum xa_handle_type type,
+uint32_t handle, uint32_t stride)
+{
struct winsys_handle whandle;
memset(&whandle, 0, sizeof(whandle));
-whandle.type = DRM_API_HANDLE_TYPE_SHARED;
+whandle.type = handle_type(type);
whandle.handle = handle;
whandle.stride = stride;
return surface_create(xa, width, height, depth, stype, xa_format, flags,
&whandle);
@@ -511,15 +540,7 @@ xa_surface_handle(struct xa_surface *srf,
boolean res;
memset(&whandle, 0, sizeof(whandle));
-switch (type) {
-case xa_handle_type_kms:
- whandle.type = DRM_API_HANDLE_TYPE_KMS;
- break;
-case xa_handle_type_shared:
-default:
- whandle.type = DRM_API_HANDLE_TYPE_SHARED;
- break;
-}
+whandle.type = handle_type(type);
res = screen->resource_get_handle(screen, srf->tex, &whandle);
if (!res)
return -XA_ERR_INVAL;
diff --git a/src/gallium/state_trackers/xa/xa_tracker.h
b/src/gallium/state_trackers/xa/xa_tracker.h
index 5c6435e..44b3eb5 100644
--- a/src/gallium/state_trackers/xa/xa_tracker.h
+++ b/src/gallium/state_trackers/xa/xa_tracker.h
@@ -37,7 +37,7 @@
#include
#define XA_TRACKER_VERSION_MAJOR 2
-#define XA_TRACKER_VERSION_MINOR 2
+#define XA_TRACKER_VERSION_MINOR 3
#define XA_TRACKER_VERSION_PATCH 0
#define XA_FLAG_SHARED (1 << 0)
@@ -149,6 +149,7 @@ struct xa_box {
enum xa_handle_type {
xa_handle_type_shared,
xa_handle_type_kms,
+xa_handle_type_fd,
};
extern void xa_tracker_version(int *major, int *minor, int *patch);
@@ -177,6 +178,17 @@ extern struct xa_surface * xa_surface_from_handle(struct
xa_tracker *xa,
enum xa_formats pform,
unsigned int flags,
uint32_t handle, uint32_t stride);
+extern struct xa_surface *
+xa_surface_from_handle2(struct xa_tracker *xa,
+int width,
+int height,
+int depth,
+enum xa_surface_type stype,
+enum xa_formats xa_format,
+unsigned int flags,
+enum xa_handle_type type,
+uint32_t handle,
+uint32_t stride);
enum xa_formats xa_surface_format(const struct xa_surface *srf);
diff --git a/src/gallium/targets/xa/xa.sym b/src/gallium/targets/xa/xa.sym
index 9c7f422..50ccc99 100644
--- a/src/gallium/targets/xa/xa.sym
+++ b/src/gallium/targets/xa/xa.sym
@@ -23,6 +23,7 @@
xa_surface_
[Mesa-dev] [PATCH] st/xa: Use PIPE_FORMAT_R8_UNORM when available
XA has been using L8_UNORM for a8 and yuv component surfaces.
This commit instead makes XA prefer R8_UNORM since it's assumed to have a
higher availability.
Also neither of these formats are suitable as destination formats using
destination alpha blending, so reject those operations.
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_composite.c | 40 ++--
src/gallium/state_trackers/xa/xa_tracker.c | 28 +--
2 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_composite.c
b/src/gallium/state_trackers/xa/xa_composite.c
index 7cfd1e1..e81eeba 100644
--- a/src/gallium/state_trackers/xa/xa_composite.c
+++ b/src/gallium/state_trackers/xa/xa_composite.c
@@ -78,26 +78,6 @@ static const struct xa_composite_blend xa_blends[] = {
0, 0, PIPE_BLENDFACTOR_ONE, PIPE_BLENDFACTOR_ONE},
};
-
-/*
- * The alpha value stored in a luminance texture is read by the
- * hardware as color.
- */
-static unsigned
-xa_convert_blend_for_luminance(unsigned factor)
-{
-switch(factor) {
-case PIPE_BLENDFACTOR_DST_ALPHA:
- return PIPE_BLENDFACTOR_DST_COLOR;
-case PIPE_BLENDFACTOR_INV_DST_ALPHA:
- return PIPE_BLENDFACTOR_INV_DST_COLOR;
-default:
- break;
-}
-return factor;
-}
-
-
static boolean
blend_for_op(struct xa_composite_blend *blend,
enum xa_composite_op op,
@@ -131,10 +111,16 @@ blend_for_op(struct xa_composite_blend *blend,
if (!dst_pic->srf)
return supported;
-if (dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM) {
- blend->rgb_src = xa_convert_blend_for_luminance(blend->rgb_src);
- blend->rgb_dst = xa_convert_blend_for_luminance(blend->rgb_dst);
-}
+/*
+ * None of the hardware formats we might use for dst A8 are
+ * suitable for dst_alpha blending, since they present the
+ * alpha channel either in all color channels (L8_UNORM) or
+ * in the red channel only (R8_UNORM)
+ */
+if ((dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM ||
+ dst_pic->srf->tex->format == PIPE_FORMAT_R8_UNORM) &&
+blend->alpha_dst)
+return FALSE;
/*
* If there's no dst alpha channel, adjust the blend op so that we'll treat
@@ -298,7 +284,8 @@ picture_format_fixups(struct xa_picture *src_pic,
ret |= mask ? FS_MASK_SET_ALPHA : FS_SRC_SET_ALPHA;
if (src_hw_format == src_pic_format) {
- if (src->tex->format == PIPE_FORMAT_L8_UNORM)
+ if (src->tex->format == PIPE_FORMAT_L8_UNORM ||
+src->tex->format == PIPE_FORMAT_R8_UNORM)
return ((mask) ? FS_MASK_LUMINANCE : FS_SRC_LUMINANCE);
return ret;
@@ -372,7 +359,8 @@ bind_shaders(struct xa_context *ctx, const struct
xa_composite *comp)
fs_traits |= picture_format_fixups(mask_pic, 1);
}
-if (ctx->srf->format == PIPE_FORMAT_L8_UNORM)
+if (ctx->srf->format == PIPE_FORMAT_L8_UNORM ||
+ctx->srf->format == PIPE_FORMAT_R8_UNORM)
fs_traits |= FS_DST_LUMINANCE;
shader = xa_shaders_get(ctx->shaders, vs_traits, fs_traits);
diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
b/src/gallium/state_trackers/xa/xa_tracker.c
index 2944b16..cd1394a 100644
--- a/src/gallium/state_trackers/xa/xa_tracker.c
+++ b/src/gallium/state_trackers/xa/xa_tracker.c
@@ -82,7 +82,7 @@ static const unsigned int stype_bind[XA_LAST_SURFACE_TYPE] =
{ 0,
};
static struct xa_format_descriptor
-xa_get_pipe_format(enum xa_formats xa_format)
+xa_get_pipe_format(struct xa_tracker *xa, enum xa_formats xa_format)
{
struct xa_format_descriptor fdesc;
@@ -102,7 +102,13 @@ xa_get_pipe_format(enum xa_formats xa_format)
fdesc.format = PIPE_FORMAT_B5G5R5A1_UNORM;
break;
case xa_format_a8:
- fdesc.format = PIPE_FORMAT_L8_UNORM;
+if (xa->screen->is_format_supported(xa->screen, PIPE_FORMAT_R8_UNORM,
+PIPE_TEXTURE_2D, 0,
+stype_bind[xa_type_a] |
+PIPE_BIND_RENDER_TARGET))
+fdesc.format = PIPE_FORMAT_R8_UNORM;
+else
+fdesc.format = PIPE_FORMAT_L8_UNORM;
break;
case xa_format_z24:
fdesc.format = PIPE_FORMAT_Z24X8_UNORM;
@@ -126,7 +132,12 @@ xa_get_pipe_format(enum xa_formats xa_format)
fdesc.format = PIPE_FORMAT_S8_UINT_Z24_UNORM;
break;
case xa_format_yuv8:
- fdesc.format = PIPE_FORMAT_L8_UNORM;
+if (xa->screen->is_format_supported(xa->screen, PIPE_FORMAT_R8_UNORM,
+PIPE_TEXTURE_2D, 0,
+stype_bind[xa_type_yuv_component]))
+fdesc.format = PIPE_FORMAT_R8_UNORM;
+else
+fd
Re: [Mesa-dev] [PATCH] st/xa: Use PIPE_FORMAT_R8_UNORM when available
On 09/17/2015 11:34 AM, Jose Fonseca wrote:
> On 16/09/15 14:04, Thomas Hellstrom wrote:
>> XA has been using L8_UNORM for a8 and yuv component surfaces.
>> This commit instead makes XA prefer R8_UNORM since it's assumed to
>> have a
>> higher availability.
>>
>> Also neither of these formats are suitable as destination formats using
>> destination alpha blending, so reject those operations.
>>
>> Signed-off-by: Thomas Hellstrom
>> ---
>> src/gallium/state_trackers/xa/xa_composite.c | 40
>> ++--
>> src/gallium/state_trackers/xa/xa_tracker.c | 28 +--
>> 2 files changed, 34 insertions(+), 34 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/xa/xa_composite.c
>> b/src/gallium/state_trackers/xa/xa_composite.c
>> index 7cfd1e1..e81eeba 100644
>> --- a/src/gallium/state_trackers/xa/xa_composite.c
>> +++ b/src/gallium/state_trackers/xa/xa_composite.c
>> @@ -78,26 +78,6 @@ static const struct xa_composite_blend xa_blends[]
>> = {
>> 0, 0, PIPE_BLENDFACTOR_ONE, PIPE_BLENDFACTOR_ONE},
>> };
>>
>> -
>> -/*
>> - * The alpha value stored in a luminance texture is read by the
>> - * hardware as color.
>> - */
>> -static unsigned
>> -xa_convert_blend_for_luminance(unsigned factor)
>> -{
>> -switch(factor) {
>> -case PIPE_BLENDFACTOR_DST_ALPHA:
>> -return PIPE_BLENDFACTOR_DST_COLOR;
>> -case PIPE_BLENDFACTOR_INV_DST_ALPHA:
>> -return PIPE_BLENDFACTOR_INV_DST_COLOR;
>> -default:
>> -break;
>> -}
>> -return factor;
>> -}
>> -
>> -
>> static boolean
>> blend_for_op(struct xa_composite_blend *blend,
>>enum xa_composite_op op,
>> @@ -131,10 +111,16 @@ blend_for_op(struct xa_composite_blend *blend,
>> if (!dst_pic->srf)
>> return supported;
>>
>> -if (dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM) {
>> -blend->rgb_src = xa_convert_blend_for_luminance(blend->rgb_src);
>> -blend->rgb_dst = xa_convert_blend_for_luminance(blend->rgb_dst);
>> -}
>> +/*
>> + * None of the hardware formats we might use for dst A8 are
>> + * suitable for dst_alpha blending, since they present the
>> + * alpha channel either in all color channels (L8_UNORM) or
>> + * in the red channel only (R8_UNORM)
>> + */
>> +if ((dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM ||
>> + dst_pic->srf->tex->format == PIPE_FORMAT_R8_UNORM) &&
>> +blend->alpha_dst)
>> +return FALSE;
>
> I'm not very familiar with this code, but wasn't
> xa_convert_blend_for_luminance compensating for the A8 <-> L8
> mismatch? It looks like it was doing the right thing. And
> xa_convert_blend_for_luminance would work both for L8 and R8.
In these operations since the destination format is A8, we're only
interested in the resulting alpha channel. With
PIPE_BLENDFACTOR_DST_ALPHA, we would use the destination alpha channel
for blending, which would pick up 1 for L8 and R8 which is obviously
wrong. Now the removed function instead set PIPE_BLENDFACTOR_DST_COLOR,
which would, if I read the specs correctly blend component-wise and
yield the correct results for the R, G and B channels if L8 is used. and
for the R channel only if R8 is used. But a prerequisite here is that
the destination logical format is A8 and the alpha channel is never
correct AFAICT.
>
>>
>> /*
>>* If there's no dst alpha channel, adjust the blend op so that
>> we'll treat
>> @@ -298,7 +284,8 @@ picture_format_fixups(struct xa_picture *src_pic,
>> ret |= mask ? FS_MASK_SET_ALPHA : FS_SRC_SET_ALPHA;
>>
>> if (src_hw_format == src_pic_format) {
>> -if (src->tex->format == PIPE_FORMAT_L8_UNORM)
>> +if (src->tex->format == PIPE_FORMAT_L8_UNORM ||
>> +src->tex->format == PIPE_FORMAT_R8_UNORM)
>> return ((mask) ? FS_MASK_LUMINANCE : FS_SRC_LUMINANCE);
>>
>> return ret;
>> @@ -372,7 +359,8 @@ bind_shaders(struct xa_context *ctx, const struct
>> xa_composite *comp)
>> fs_traits |= picture_format_fixups(mask_pic, 1);
>> }
>>
>> -if (ctx->srf->format == PIPE_FORMAT_L8_UNORM)
>> +if (ctx->srf->format == PIPE_FORMAT_L8_UNORM ||
>> +ctx->srf->format == PIPE_FORMAT_R8_UNORM)
>> fs_traits |= FS_DST_LUMINANCE;
>
> What exactly is FS_DST_LUMINANCE supposed to do?
Re: [Mesa-dev] [PATCH] st/xa: Use PIPE_FORMAT_R8_UNORM when available
On 09/17/2015 11:53 AM, Thomas Hellstrom wrote:
> On 09/17/2015 11:34 AM, Jose Fonseca wrote:
>> On 16/09/15 14:04, Thomas Hellstrom wrote:
>>> XA has been using L8_UNORM for a8 and yuv component surfaces.
>>> This commit instead makes XA prefer R8_UNORM since it's assumed to
>>> have a
>>> higher availability.
>>>
>>> Also neither of these formats are suitable as destination formats using
>>> destination alpha blending, so reject those operations.
>>>
>>> Signed-off-by: Thomas Hellstrom
>>> ---
>>> src/gallium/state_trackers/xa/xa_composite.c | 40
>>> ++--
>>> src/gallium/state_trackers/xa/xa_tracker.c | 28 +--
>>> 2 files changed, 34 insertions(+), 34 deletions(-)
>>>
>>> diff --git a/src/gallium/state_trackers/xa/xa_composite.c
>>> b/src/gallium/state_trackers/xa/xa_composite.c
>>> index 7cfd1e1..e81eeba 100644
>>> --- a/src/gallium/state_trackers/xa/xa_composite.c
>>> +++ b/src/gallium/state_trackers/xa/xa_composite.c
>>> @@ -78,26 +78,6 @@ static const struct xa_composite_blend xa_blends[]
>>> = {
>>> 0, 0, PIPE_BLENDFACTOR_ONE, PIPE_BLENDFACTOR_ONE},
>>> };
>>>
>>> -
>>> -/*
>>> - * The alpha value stored in a luminance texture is read by the
>>> - * hardware as color.
>>> - */
>>> -static unsigned
>>> -xa_convert_blend_for_luminance(unsigned factor)
>>> -{
>>> -switch(factor) {
>>> -case PIPE_BLENDFACTOR_DST_ALPHA:
>>> -return PIPE_BLENDFACTOR_DST_COLOR;
>>> -case PIPE_BLENDFACTOR_INV_DST_ALPHA:
>>> -return PIPE_BLENDFACTOR_INV_DST_COLOR;
>>> -default:
>>> -break;
>>> -}
>>> -return factor;
>>> -}
>>> -
>>> -
>>> static boolean
>>> blend_for_op(struct xa_composite_blend *blend,
>>>enum xa_composite_op op,
>>> @@ -131,10 +111,16 @@ blend_for_op(struct xa_composite_blend *blend,
>>> if (!dst_pic->srf)
>>> return supported;
>>>
>>> -if (dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM) {
>>> -blend->rgb_src = xa_convert_blend_for_luminance(blend->rgb_src);
>>> -blend->rgb_dst = xa_convert_blend_for_luminance(blend->rgb_dst);
>>> -}
>>> +/*
>>> + * None of the hardware formats we might use for dst A8 are
>>> + * suitable for dst_alpha blending, since they present the
>>> + * alpha channel either in all color channels (L8_UNORM) or
>>> + * in the red channel only (R8_UNORM)
>>> + */
>>> +if ((dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM ||
>>> + dst_pic->srf->tex->format == PIPE_FORMAT_R8_UNORM) &&
>>> +blend->alpha_dst)
>>> +return FALSE;
>> I'm not very familiar with this code, but wasn't
>> xa_convert_blend_for_luminance compensating for the A8 <-> L8
>> mismatch? It looks like it was doing the right thing. And
>> xa_convert_blend_for_luminance would work both for L8 and R8.
> In these operations since the destination format is A8, we're only
> interested in the resulting alpha channel. With
> PIPE_BLENDFACTOR_DST_ALPHA, we would use the destination alpha channel
> for blending, which would pick up 1 for L8 and R8 which is obviously
> wrong. Now the removed function instead set PIPE_BLENDFACTOR_DST_COLOR,
> which would, if I read the specs correctly blend component-wise and
> yield the correct results for the R, G and B channels if L8 is used. and
> for the R channel only if R8 is used. But a prerequisite here is that
> the destination logical format is A8 and the alpha channel is never
> correct AFAICT.
>
Hmm, or are you making the point that blending takes place when we've
already swizzled the alpha value to the red channel? Yes, then you're
obviously right, and I need to revert that "fix" ;).
/Thomas
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Fixups for PIPE_FORMAT_R8_UNORM A8 usage
Check for PIPE_FORMAT_R8_UNORM when setting up the copy shader.
Also re-enable the dest alpha blending with A8 destination that
actually turned out to be correct.
Verified using rendercheck that the composite operators
overreverse, in, out, atop, atopreverse and xor seem to work fine
with a8 destiation.
Reported-by: Jose Fonseca
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_composite.c | 34
src/gallium/state_trackers/xa/xa_renderer.c | 6 +++--
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_composite.c
b/src/gallium/state_trackers/xa/xa_composite.c
index e81eeba..bcb27ea 100644
--- a/src/gallium/state_trackers/xa/xa_composite.c
+++ b/src/gallium/state_trackers/xa/xa_composite.c
@@ -78,6 +78,27 @@ static const struct xa_composite_blend xa_blends[] = {
0, 0, PIPE_BLENDFACTOR_ONE, PIPE_BLENDFACTOR_ONE},
};
+/*
+ * The alpha value stored in a L8 texture is read by the
+ * hardware as color, and R8 is read as red. The source alpha value
+ * at the end of the fragment shader is stored in all color channels,
+ * so the correct approach is to blend using DST_COLOR instead of
+ * DST_ALPHA and then output any color channel (L8) or the red channel (R8).
+ */
+static unsigned
+xa_convert_blend_for_luminance(unsigned factor)
+{
+switch(factor) {
+case PIPE_BLENDFACTOR_DST_ALPHA:
+ return PIPE_BLENDFACTOR_DST_COLOR;
+case PIPE_BLENDFACTOR_INV_DST_ALPHA:
+ return PIPE_BLENDFACTOR_INV_DST_COLOR;
+default:
+ break;
+}
+return factor;
+}
+
static boolean
blend_for_op(struct xa_composite_blend *blend,
enum xa_composite_op op,
@@ -111,16 +132,11 @@ blend_for_op(struct xa_composite_blend *blend,
if (!dst_pic->srf)
return supported;
-/*
- * None of the hardware formats we might use for dst A8 are
- * suitable for dst_alpha blending, since they present the
- * alpha channel either in all color channels (L8_UNORM) or
- * in the red channel only (R8_UNORM)
- */
if ((dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM ||
- dst_pic->srf->tex->format == PIPE_FORMAT_R8_UNORM) &&
-blend->alpha_dst)
-return FALSE;
+ dst_pic->srf->tex->format == PIPE_FORMAT_R8_UNORM)) {
+blend->rgb_src = xa_convert_blend_for_luminance(blend->rgb_src);
+blend->rgb_dst = xa_convert_blend_for_luminance(blend->rgb_dst);
+}
/*
* If there's no dst alpha channel, adjust the blend op so that we'll treat
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index fda07e5..006ccf6 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -465,9 +465,11 @@ renderer_copy_prepare(struct xa_context *r,
}
/* shaders */
-if (src_texture->format == PIPE_FORMAT_L8_UNORM)
+if (src_texture->format == PIPE_FORMAT_L8_UNORM ||
+src_texture->format == PIPE_FORMAT_R8_UNORM)
fs_traits |= FS_SRC_LUMINANCE;
-if (dst_surface->format == PIPE_FORMAT_L8_UNORM)
+if (dst_surface->format == PIPE_FORMAT_L8_UNORM ||
+src_texture->format == PIPE_FORMAT_R8_UNORM)
fs_traits |= FS_DST_LUMINANCE;
if (xa_format_a(dst_xa_format) != 0 &&
xa_format_a(src_xa_format) == 0)
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Fixups for PIPE_FORMAT_R8_UNORM A8 usage v2.
Check for PIPE_FORMAT_R8_UNORM when setting up the copy shader.
Also re-enable the dest alpha blending with A8 destination that
actually turned out to be correct.
Verified using rendercheck that the composite operators
overreverse, in, out, atop, atopreverse and xor seem to work fine
with a8 destiation.
v2: Fix a copy-paste error.
Reported-by: Jose Fonseca
Signed-off-by: Thomas Hellstrom
---
src/gallium/state_trackers/xa/xa_composite.c | 34
src/gallium/state_trackers/xa/xa_renderer.c | 6 +++--
2 files changed, 29 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/xa/xa_composite.c
b/src/gallium/state_trackers/xa/xa_composite.c
index e81eeba..bcb27ea 100644
--- a/src/gallium/state_trackers/xa/xa_composite.c
+++ b/src/gallium/state_trackers/xa/xa_composite.c
@@ -78,6 +78,27 @@ static const struct xa_composite_blend xa_blends[] = {
0, 0, PIPE_BLENDFACTOR_ONE, PIPE_BLENDFACTOR_ONE},
};
+/*
+ * The alpha value stored in a L8 texture is read by the
+ * hardware as color, and R8 is read as red. The source alpha value
+ * at the end of the fragment shader is stored in all color channels,
+ * so the correct approach is to blend using DST_COLOR instead of
+ * DST_ALPHA and then output any color channel (L8) or the red channel (R8).
+ */
+static unsigned
+xa_convert_blend_for_luminance(unsigned factor)
+{
+switch(factor) {
+case PIPE_BLENDFACTOR_DST_ALPHA:
+ return PIPE_BLENDFACTOR_DST_COLOR;
+case PIPE_BLENDFACTOR_INV_DST_ALPHA:
+ return PIPE_BLENDFACTOR_INV_DST_COLOR;
+default:
+ break;
+}
+return factor;
+}
+
static boolean
blend_for_op(struct xa_composite_blend *blend,
enum xa_composite_op op,
@@ -111,16 +132,11 @@ blend_for_op(struct xa_composite_blend *blend,
if (!dst_pic->srf)
return supported;
-/*
- * None of the hardware formats we might use for dst A8 are
- * suitable for dst_alpha blending, since they present the
- * alpha channel either in all color channels (L8_UNORM) or
- * in the red channel only (R8_UNORM)
- */
if ((dst_pic->srf->tex->format == PIPE_FORMAT_L8_UNORM ||
- dst_pic->srf->tex->format == PIPE_FORMAT_R8_UNORM) &&
-blend->alpha_dst)
-return FALSE;
+ dst_pic->srf->tex->format == PIPE_FORMAT_R8_UNORM)) {
+blend->rgb_src = xa_convert_blend_for_luminance(blend->rgb_src);
+blend->rgb_dst = xa_convert_blend_for_luminance(blend->rgb_dst);
+}
/*
* If there's no dst alpha channel, adjust the blend op so that we'll treat
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index fda07e5..bc55f87 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -465,9 +465,11 @@ renderer_copy_prepare(struct xa_context *r,
}
/* shaders */
-if (src_texture->format == PIPE_FORMAT_L8_UNORM)
+if (src_texture->format == PIPE_FORMAT_L8_UNORM ||
+src_texture->format == PIPE_FORMAT_R8_UNORM)
fs_traits |= FS_SRC_LUMINANCE;
-if (dst_surface->format == PIPE_FORMAT_L8_UNORM)
+if (dst_surface->format == PIPE_FORMAT_L8_UNORM ||
+dst_surface->format == PIPE_FORMAT_R8_UNORM)
fs_traits |= FS_DST_LUMINANCE;
if (xa_format_a(dst_xa_format) != 0 &&
xa_format_a(src_xa_format) == 0)
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] GBM: Add map/unmap functions
On 04/11/2016 04:31 PM, Rob Clark wrote: > On Mon, Apr 11, 2016 at 10:09 AM, Emil Velikov > wrote: >> Hi Rob, >> >> On 31 March 2016 at 04:21, Rob Herring wrote: >>> This adds GBM map and unmap functions. Unlike prior attempts, this >>> version provides a region and usage flags for the mapping. The operation >>> follows gallium transfer_map() function. This is complete enough to work >>> on Android with gralloc using the GBM API. >>> >>> TODO: >>> - split up patches >>> - define and propagate GBM usage flags >>> - DRIImage extension version checking >>> - Need to flush context on unmap? >>> - Need fences for gralloc lockAsync >>> - integrate dumb buffer mapping >>> - bikeshed the name (map or lock) >>> >> With the risk of starting a war - wasn't there objections about having >> such interfaces in GBM a while back ? >> Personally I would CC the person so that he can clarify if current >> version is in better shape. Hopefully he'll bring forward what needs >> fixing (if any) to get this kind of interface in acceptable shape. >> >> Note: not sure who was against the previous patches so I haven't CC'd him. > iirc, it was Thomas (who I've added in CC).. and the issue was more > about how the previous implementation worked (ie. returning mmap > pointer to entire buffer). Rob's implementation fits on top of > pipe_transfer and should address Thomas's concerns. > > As long as there is an "affected region" attached to the map I'm completely OK with it. Thanks, /Thomas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/xa: Fix regression in xa_yuv_planar_blit()
Commit "st/xa: scissor to help tilers" broke xa_yuv_planar_blit() and vmwgfx
textured video. Fix this by implementing scissors also in the yuv draw path.
Signed-off-by: Thomas Hellstrom
Cc: Rob Clark
Cc: "10.2 10.3"
---
src/gallium/state_trackers/xa/xa_renderer.c | 11 +++
src/gallium/state_trackers/xa/xa_yuv.c | 1 +
2 files changed, 12 insertions(+)
diff --git a/src/gallium/state_trackers/xa/xa_renderer.c
b/src/gallium/state_trackers/xa/xa_renderer.c
index 121d8ed..780b247 100644
--- a/src/gallium/state_trackers/xa/xa_renderer.c
+++ b/src/gallium/state_trackers/xa/xa_renderer.c
@@ -530,11 +530,22 @@ renderer_draw_yuv(struct xa_context *r,
src_x, src_y, src_w, src_h,
dst_x, dst_y, dst_w, dst_h, srf);
+ if (!r->scissor_valid) {
+ r->scissor.minx = 0;
+ r->scissor.miny = 0;
+ r->scissor.maxx = r->dst->tex->width0;
+ r->scissor.maxy = r->dst->tex->height0;
+ }
+
+ r->pipe->set_scissor_states(r->pipe, 0, 1, &r->scissor);
+
cso_set_vertex_elements(r->cso, num_attribs, r->velems);
util_draw_user_vertex_buffer(r->cso, r->buffer, PIPE_PRIM_QUADS,
4, /* verts */
num_attribs); /* attribs/vert */
r->buffer_size = 0;
+
+ xa_scissor_reset(r);
}
void
diff --git a/src/gallium/state_trackers/xa/xa_yuv.c
b/src/gallium/state_trackers/xa/xa_yuv.c
index 43f56ff..1519639 100644
--- a/src/gallium/state_trackers/xa/xa_yuv.c
+++ b/src/gallium/state_trackers/xa/xa_yuv.c
@@ -146,6 +146,7 @@ xa_yuv_planar_blit(struct xa_context *r,
int w = box->x2 - box->x1;
int h = box->y2 - box->y1;
+xa_scissor_update(r, x, y, box->x2, box->y2);
renderer_draw_yuv(r,
(float)src_x + scale_x * (x - dst_x),
(float)src_y + scale_y * (y - dst_y),
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] xa: support for drivers which use NIR
lgtm.
Could you just add a small comment for future reference in in
xa_tracker.c that the function
_mesa_error_no_memory
is used by NIR?
Thanks,
Thomas
On 04/03/2015 08:07 PM, Rob Clark wrote:
> From: Rob Clark
>
> We need to pull in libnir.la and it's dependency libglsl_util.la. Also,
> _mesa_error_no_memory() must be defined.
>
> Fortunately with libnir.la (vs pulling in all of libglsl.la) we don't
> also need libstdc++.
>
> Signed-off-by: Rob Clark
> ---
> src/gallium/state_trackers/xa/xa_tracker.c | 7 +++
> src/gallium/targets/xa/Makefile.am | 2 ++
> 2 files changed, 9 insertions(+)
>
> diff --git a/src/gallium/state_trackers/xa/xa_tracker.c
> b/src/gallium/state_trackers/xa/xa_tracker.c
> index f69ac8e..3f22d64 100644
> --- a/src/gallium/state_trackers/xa/xa_tracker.c
> +++ b/src/gallium/state_trackers/xa/xa_tracker.c
> @@ -535,3 +535,10 @@ xa_surface_format(const struct xa_surface *srf)
> {
> return srf->fdesc.xa_format;
> }
> +
> +void _mesa_error_no_memory(const char *caller);
> +void
> +_mesa_error_no_memory(const char *caller)
> +{
> + debug_printf("Mesa error: out of memory in %s", caller);
> +}
> diff --git a/src/gallium/targets/xa/Makefile.am
> b/src/gallium/targets/xa/Makefile.am
> index a1eae2a..8ddb967 100644
> --- a/src/gallium/targets/xa/Makefile.am
> +++ b/src/gallium/targets/xa/Makefile.am
> @@ -37,6 +37,8 @@ libxatracker_la_LIBADD = \
> $(top_builddir)/src/gallium/state_trackers/xa/libxatracker.la \
> $(top_builddir)/src/gallium/auxiliary/libgalliumvl_stub.la \
> $(top_builddir)/src/gallium/auxiliary/libgallium.la \
> + $(top_builddir)/src/glsl/libnir.la \
> + $(top_builddir)/src/libglsl_util.la \
> $(top_builddir)/src/util/libmesautil.la \
> $(LIBDRM_LIBS) \
> $(GALLIUM_COMMON_LIB_DEPS)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] winsys/svga: Fix an uninitialized return value
Reported-by: Brian Paul
Signed-off-by: Thomas Hellstrom
Reviwed-by: Brian Paul
Cc: "11.0 11.1"
---
src/gallium/winsys/svga/drm/vmw_surface.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/gallium/winsys/svga/drm/vmw_surface.c
b/src/gallium/winsys/svga/drm/vmw_surface.c
index 6c0ad3b..a438b1a 100644
--- a/src/gallium/winsys/svga/drm/vmw_surface.c
+++ b/src/gallium/winsys/svga/drm/vmw_surface.c
@@ -170,6 +170,8 @@ vmw_svga_winsys_surface_unmap(struct svga_winsys_context
*swc,
*rebind = vsrf->rebind;
vsrf->rebind = FALSE;
vmw_svga_winsys_buffer_unmap(&vsrf->screen->base, vsrf->buf);
+ } else {
+ *rebind = FALSE;
}
pipe_mutex_unlock(vsrf->mutex);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] winsys/svga: Increase the fence timeout
If running with a software renderer backend, the timeout may be
insufficient, and we don't want to release busy buffers too early.
In practice, SVGA gpu lockups are extremely rare.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
Cc: "11.0 11.1"
---
src/gallium/winsys/svga/drm/vmw_screen_ioctl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
index c86d95a..7fc93e7 100644
--- a/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
+++ b/src/gallium/winsys/svga/drm/vmw_screen_ioctl.c
@@ -52,6 +52,7 @@
#include
#define VMW_MAX_DEFAULT_TEXTURE_SIZE (128 * 1024 * 1024)
+#define VMW_FENCE_TIMEOUT_SECONDS 60
struct vmw_region
{
@@ -721,7 +722,7 @@ vmw_ioctl_fence_finish(struct vmw_winsys_screen *vws,
memset(&arg, 0, sizeof(arg));
arg.handle = handle;
- arg.timeout_us = 10*100;
+ arg.timeout_us = VMW_FENCE_TIMEOUT_SECONDS*100;
arg.lazy = 0;
arg.flags = vflags;
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium/vl: Fix brightness usage
Multiplying the contrast- and brightness matrices it becomes obvious that brightness should be multiplied by contrast in the procamp matrix. Fix this. Cc: "11.0 11.1 11.2" Signed-off-by: Thomas Hellstrom --- src/gallium/auxiliary/vl/vl_csc.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/gallium/auxiliary/vl/vl_csc.c b/src/gallium/auxiliary/vl/vl_csc.c index c8efe28..623edfd 100644 --- a/src/gallium/auxiliary/vl/vl_csc.c +++ b/src/gallium/auxiliary/vl/vl_csc.c @@ -77,10 +77,10 @@ * [ 0, 0, 0, 1] * * procamp - * [ c, 0, 0, b] - * [ 0, c*s*cos(h), c*s*sin(h), 0] - * [ 0, -c*s*sin(h), c*s*cos(h), 0] - * [ 0, 0, 0, 1] + * [ c, 0, 0, cb] + * [ 0, c*s*cos(h), c*s*sin(h), 0] + * [ 0, -c*s*sin(h), c*s*cos(h), 0] + * [ 0, 0, 0, 1] * * bias * [ 1, 0, 0, ybias] @@ -89,10 +89,10 @@ * [ 0, 0, 0, 1] * * csc - * [ c*cstd[ 0], c*cstd[ 1]*s*cos(h) - c*cstd[ 2]*s*sin(h), c*cstd[ 2]*s*cos(h) + c*cstd[ 1]*s*sin(h), cstd[ 3] + cstd[ 0]*(b + c*ybias) + cstd[ 1]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 2]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] - * [ c*cstd[ 4], c*cstd[ 5]*s*cos(h) - c*cstd[ 6]*s*sin(h), c*cstd[ 6]*s*cos(h) + c*cstd[ 5]*s*sin(h), cstd[ 7] + cstd[ 4]*(b + c*ybias) + cstd[ 5]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 6]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] - * [ c*cstd[ 8], c*cstd[ 9]*s*cos(h) - c*cstd[10]*s*sin(h), c*cstd[10]*s*cos(h) + c*cstd[ 9]*s*sin(h), cstd[11] + cstd[ 8]*(b + c*ybias) + cstd[ 9]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[10]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] - * [ c*cstd[12], c*cstd[13]*s*cos(h) - c*cstd[14]*s*sin(h), c*cstd[14]*s*cos(h) + c*cstd[13]*s*sin(h), cstd[15] + cstd[12]*(b + c*ybias) + cstd[13]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[14]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[ 0], c*cstd[ 1]*s*cos(h) - c*cstd[ 2]*s*sin(h), c*cstd[ 2]*s*cos(h) + c*cstd[ 1]*s*sin(h), cstd[ 3] + cstd[ 0]*c(b + ybias) + cstd[ 1]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 2]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[ 4], c*cstd[ 5]*s*cos(h) - c*cstd[ 6]*s*sin(h), c*cstd[ 6]*s*cos(h) + c*cstd[ 5]*s*sin(h), cstd[ 7] + cstd[ 4]*c(b + ybias) + cstd[ 5]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 6]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[ 8], c*cstd[ 9]*s*cos(h) - c*cstd[10]*s*sin(h), c*cstd[10]*s*cos(h) + c*cstd[ 9]*s*sin(h), cstd[11] + cstd[ 8]*c(b + ybias) + cstd[ 9]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[10]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[12], c*cstd[13]*s*cos(h) - c*cstd[14]*s*sin(h), c*cstd[14]*s*cos(h) + c*cstd[13]*s*sin(h), cstd[15] + cstd[12]*c(b + ybias) + cstd[13]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[14]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] */ /* @@ -210,21 +210,21 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs, (*matrix)[0][0] = c * (*cstd)[0][0]; (*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s * sinf(h); (*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s * sinf(h); - (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * (b + c * ybias) + + (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * (b + ybias) + (*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias * s * sinf(h)) + (*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias * s * sinf(h)); (*matrix)[1][0] = c * (*cstd)[1][0]; (*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s * sinf(h); (*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s * sinf(h); - (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * (b + c * ybias) + + (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * (b + ybias) + (*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias * s * sinf(h)) + (*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias * s * sinf(h)); (*matrix)[2][0] = c * (*cstd)[2][0]; (*matrix)[2][1] = c * (*cstd)[2][1] * s * cosf(h) - c * (*cstd)[2][2] * s * sinf(h); (*matrix)[2][2] = c * (*cstd)[2][2] * s * cosf(h) + c * (*cstd)[2][1] * s * sinf(h); - (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * (b + c * ybias) + + (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * (b * ybias) + (*cstd)[2][1] * (c * cbbias * s * cosf(h) + c * crbias * s * sinf(h)) + (*cstd)[2][2] * (c * crbias * s * cosf(h) - c * cbbias * s * sinf(h)); } -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] gallium/vl: Parameter substitution in the csc matrix computation
Makes the code significantly more readable.
Signed-off-by: Thomas Hellstrom
---
src/gallium/auxiliary/vl/vl_csc.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_csc.c
b/src/gallium/auxiliary/vl/vl_csc.c
index 66ea301..f86cef2 100644
--- a/src/gallium/auxiliary/vl/vl_csc.c
+++ b/src/gallium/auxiliary/vl/vl_csc.c
@@ -153,6 +153,7 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
float s = p->saturation;
float b = p->brightness;
float h = p->hue;
+ float x, y, z;
const vl_csc_matrix *cstd;
@@ -162,6 +163,11 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
s *= 1.138f/1.164f; /* Adjust for the chroma range */
}
+ /* Parameter substitutions */
+ x = c * s * cosf(h);
+ y = c * s * sinf(h);
+ z = c * b;
+
assert(matrix);
switch (cs) {
@@ -182,23 +188,23 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
}
(*matrix)[0][0] = c * (*cstd)[0][0];
- (*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s *
sinf(h);
- (*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s *
sinf(h);
- (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * b +
- (*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*matrix)[0][1] = (*cstd)[0][1] * x - (*cstd)[0][2] * y;
+ (*matrix)[0][2] = (*cstd)[0][2] * x + (*cstd)[0][1] * y;
+ (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * z +
+ (*cstd)[0][1] * (x * cbbias + y * crbias) +
+ (*cstd)[0][2] * (x * crbias - y * cbbias);
(*matrix)[1][0] = c * (*cstd)[1][0];
- (*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s *
sinf(h);
- (*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s *
sinf(h);
- (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * b +
- (*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*matrix)[1][1] = (*cstd)[1][1] * x - (*cstd)[1][2] * y;
+ (*matrix)[1][2] = (*cstd)[1][2] * x + (*cstd)[1][1] * y;
+ (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * z +
+ (*cstd)[1][1] * (x * cbbias + y * crbias) +
+ (*cstd)[1][2] * (x * crbias - y * cbbias);
(*matrix)[2][0] = c * (*cstd)[2][0];
- (*matrix)[2][1] = c * (*cstd)[2][1] * s * cosf(h) - c * (*cstd)[2][2] * s *
sinf(h);
- (*matrix)[2][2] = c * (*cstd)[2][2] * s * cosf(h) + c * (*cstd)[2][1] * s *
sinf(h);
- (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * b +
- (*cstd)[2][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[2][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*matrix)[2][1] = (*cstd)[2][1] * x - (*cstd)[2][2] * y;
+ (*matrix)[2][2] = (*cstd)[2][2] * x + (*cstd)[2][1] * y;
+ (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * z +
+ (*cstd)[2][1] * (x * cbbias + y * crbias) +
+ (*cstd)[2][2] * (x * crbias - y * cbbias);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/3] gallium/vl: Simplify usage of full range matrices
When looking at the full range matrices, it becomes obvious that the difference
between the standard matrices and the full range matrices is that column 0
is multiplied by 1.164 and columns 1 and 2 are muliplied by 1.138. This can
be accomplished by multiplying the contrast with 1.164 and the saturation with
1.138/1.164. Removes the need to specify separate full range matrices.
We can also incorporate the ybias in the brightness simplifying the
calculation somewhat.
Signed-off-by: Thomas Hellstrom
---
src/gallium/auxiliary/vl/vl_csc.c | 50 ++-
1 file changed, 12 insertions(+), 38 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_csc.c
b/src/gallium/auxiliary/vl/vl_csc.c
index 623edfd..66ea301 100644
--- a/src/gallium/auxiliary/vl/vl_csc.c
+++ b/src/gallium/auxiliary/vl/vl_csc.c
@@ -108,18 +108,6 @@ static const vl_csc_matrix bt_601 =
};
/*
- * Converts ITU-R BT.601 YCbCr pixels to RGB pixels where:
- * Y is in [16,235], Cb and Cr are in [16,240]
- * R, G, and B are in [0,255]
- */
-static const vl_csc_matrix bt_601_full =
-{
- { 1.164f, 0.0f,1.596f, 0.0f, },
- { 1.164f, -0.391f, -0.813f, 0.0f, },
- { 1.164f, 2.018f, 0.0f, 0.0f, }
-};
-
-/*
* Converts ITU-R BT.709 YCbCr pixels to RGB pixels where:
* Y is in [16,235], Cb and Cr are in [16,240]
* R, G, and B are in [16,235]
@@ -131,18 +119,6 @@ static const vl_csc_matrix bt_709 =
{ 1.0f, 1.816f, 0.0f, 0.0f, }
};
-/*
- * Converts ITU-R BT.709 YCbCr pixels to RGB pixels where:
- * Y is in [16,235], Cb and Cr are in [16,240]
- * R, G, and B are in [0,255]
- */
-static const vl_csc_matrix bt_709_full =
-{
- { 1.164f, 0.0f,1.793f, 0.0f, },
- { 1.164f, -0.213f, -0.534f, 0.0f, },
- { 1.164f, 2.115f, 0.0f, 0.0f, }
-};
-
static const vl_csc_matrix smpte240m =
{
{ 1.0f, 0.0f,1.582f, 0.0f, },
@@ -150,13 +126,6 @@ static const vl_csc_matrix smpte240m =
{ 1.0f, 1.833f, 0.0f, 0.0f, }
};
-static const vl_csc_matrix smpte240m_full =
-{
- { 1.164f, 0.0f,1.794f, 0.0f, },
- { 1.164f, -0.258f, -0.543f, 0.0f, },
- { 1.164f, 2.079f, 0.0f, 0.0f, }
-};
-
static const vl_csc_matrix identity =
{
{ 1.0f, 0.0f, 0.0f, 0.0f, },
@@ -176,7 +145,6 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
bool full_range,
vl_csc_matrix *matrix)
{
- float ybias = full_range ? -16.0f/255.0f : 0.0f;
float cbbias = -128.0f/255.0f;
float crbias = -128.0f/255.0f;
@@ -188,17 +156,23 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
const vl_csc_matrix *cstd;
+ if (full_range) {
+ b -= -16.0f/255.0f; /* Adjust for the y bias */
+ c *= 1.164f;/* Adjust for the y range */
+ s *= 1.138f/1.164f; /* Adjust for the chroma range */
+ }
+
assert(matrix);
switch (cs) {
case VL_CSC_COLOR_STANDARD_BT_601:
- cstd = full_range ? &bt_601_full : &bt_601;
+ cstd = &bt_601;
break;
case VL_CSC_COLOR_STANDARD_BT_709:
- cstd = full_range ? &bt_709_full : &bt_709;
+ cstd = &bt_709;
break;
case VL_CSC_COLOR_STANDARD_SMPTE_240M:
- cstd = full_range ? &smpte240m_full : &smpte240m;
+ cstd = &smpte240m;
break;
case VL_CSC_COLOR_STANDARD_IDENTITY:
default:
@@ -210,21 +184,21 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
(*matrix)[0][0] = c * (*cstd)[0][0];
(*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s *
sinf(h);
(*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s *
sinf(h);
- (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * (b + ybias) +
+ (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * b +
(*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
(*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
(*matrix)[1][0] = c * (*cstd)[1][0];
(*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s *
sinf(h);
(*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s *
sinf(h);
- (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * (b + ybias) +
+ (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * b +
(*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
(*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
(*matrix)[2][0] = c * (*cstd)[2][0];
(*matrix)[2][1] = c * (*cstd)[2][1] * s * cosf(h) - c * (*cstd)[2][2] * s *
sinf(h);
(*matrix)[2][2] = c * (*cstd)[2][2] * s * cosf(h) + c * (*cstd)[2][1] * s *
sinf(h);
- (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * (b * ybias) +
+ (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * b +
(*cstd)[2][1] * (c * cbbias * s
[Mesa-dev] [PATCH 2/3] gallium/vl: Simplify usage of full range matrices
When looking at the full range matrices, it becomes obvious that the difference
between the standard matrices and the full range matrices is that column 0
is multiplied by 1.164 and columns 1 and 2 are muliplied by 1.138. This can
be accomplished by multiplying the contrast with 1.164 and the saturation with
1.138/1.164. Removes the need to specify separate full range matrices.
We can also incorporate the ybias in the brightness simplifying the
calculation somewhat.
Signed-off-by: Thomas Hellstrom
---
src/gallium/auxiliary/vl/vl_csc.c | 50 ++-
1 file changed, 12 insertions(+), 38 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_csc.c
b/src/gallium/auxiliary/vl/vl_csc.c
index fc11f73..bb2cc58 100644
--- a/src/gallium/auxiliary/vl/vl_csc.c
+++ b/src/gallium/auxiliary/vl/vl_csc.c
@@ -108,18 +108,6 @@ static const vl_csc_matrix bt_601 =
};
/*
- * Converts ITU-R BT.601 YCbCr pixels to RGB pixels where:
- * Y is in [16,235], Cb and Cr are in [16,240]
- * R, G, and B are in [0,255]
- */
-static const vl_csc_matrix bt_601_full =
-{
- { 1.164f, 0.0f,1.596f, 0.0f, },
- { 1.164f, -0.391f, -0.813f, 0.0f, },
- { 1.164f, 2.018f, 0.0f, 0.0f, }
-};
-
-/*
* Converts ITU-R BT.709 YCbCr pixels to RGB pixels where:
* Y is in [16,235], Cb and Cr are in [16,240]
* R, G, and B are in [16,235]
@@ -131,18 +119,6 @@ static const vl_csc_matrix bt_709 =
{ 1.0f, 1.816f, 0.0f, 0.0f, }
};
-/*
- * Converts ITU-R BT.709 YCbCr pixels to RGB pixels where:
- * Y is in [16,235], Cb and Cr are in [16,240]
- * R, G, and B are in [0,255]
- */
-static const vl_csc_matrix bt_709_full =
-{
- { 1.164f, 0.0f,1.793f, 0.0f, },
- { 1.164f, -0.213f, -0.534f, 0.0f, },
- { 1.164f, 2.115f, 0.0f, 0.0f, }
-};
-
static const vl_csc_matrix smpte240m =
{
{ 1.0f, 0.0f,1.582f, 0.0f, },
@@ -150,13 +126,6 @@ static const vl_csc_matrix smpte240m =
{ 1.0f, 1.833f, 0.0f, 0.0f, }
};
-static const vl_csc_matrix smpte240m_full =
-{
- { 1.164f, 0.0f,1.794f, 0.0f, },
- { 1.164f, -0.258f, -0.543f, 0.0f, },
- { 1.164f, 2.079f, 0.0f, 0.0f, }
-};
-
static const vl_csc_matrix identity =
{
{ 1.0f, 0.0f, 0.0f, 0.0f, },
@@ -176,7 +145,6 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
bool full_range,
vl_csc_matrix *matrix)
{
- float ybias = full_range ? -16.0f/255.0f : 0.0f;
float cbbias = -128.0f/255.0f;
float crbias = -128.0f/255.0f;
@@ -188,17 +156,23 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
const vl_csc_matrix *cstd;
+ if (full_range) {
+ b -= -16.0f/255.0f; /* Adjust for the y bias */
+ c *= 1.164f;/* Adjust for the y range */
+ s *= 1.138f/1.164f; /* Adjust for the chroma range */
+ }
+
assert(matrix);
switch (cs) {
case VL_CSC_COLOR_STANDARD_BT_601:
- cstd = full_range ? &bt_601_full : &bt_601;
+ cstd = &bt_601;
break;
case VL_CSC_COLOR_STANDARD_BT_709:
- cstd = full_range ? &bt_709_full : &bt_709;
+ cstd = &bt_709;
break;
case VL_CSC_COLOR_STANDARD_SMPTE_240M:
- cstd = full_range ? &smpte240m_full : &smpte240m;
+ cstd = &smpte240m;
break;
case VL_CSC_COLOR_STANDARD_IDENTITY:
default:
@@ -210,21 +184,21 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
(*matrix)[0][0] = c * (*cstd)[0][0];
(*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s *
sinf(h);
(*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s *
sinf(h);
- (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * (b + ybias) +
+ (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * b +
(*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
(*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
(*matrix)[1][0] = c * (*cstd)[1][0];
(*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s *
sinf(h);
(*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s *
sinf(h);
- (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * (b + ybias) +
+ (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * b +
(*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
(*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
(*matrix)[2][0] = c * (*cstd)[2][0];
(*matrix)[2][1] = c * (*cstd)[2][1] * s * cosf(h) - c * (*cstd)[2][2] * s *
sinf(h);
(*matrix)[2][2] = c * (*cstd)[2][2] * s * cosf(h) + c * (*cstd)[2][1] * s *
sinf(h);
- (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * (b + ybias) +
+ (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * b +
(*cstd)[2][1] * (c * cbbias * s
[Mesa-dev] [PATCH 3/3] gallium/vl: Parameter substitution in the csc matrix computation
Makes the code significantly more readable.
Signed-off-by: Thomas Hellstrom
---
src/gallium/auxiliary/vl/vl_csc.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_csc.c
b/src/gallium/auxiliary/vl/vl_csc.c
index bb2cc58..66cedd9 100644
--- a/src/gallium/auxiliary/vl/vl_csc.c
+++ b/src/gallium/auxiliary/vl/vl_csc.c
@@ -153,6 +153,7 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
float s = p->saturation;
float b = p->brightness;
float h = p->hue;
+ float x, y, z;
const vl_csc_matrix *cstd;
@@ -162,6 +163,11 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
s *= 1.138f/1.164f; /* Adjust for the chroma range */
}
+ /* Parameter substitutions */
+ x = c * s * cosf(h);
+ y = c * s * sinf(h);
+ z = c * b;
+
assert(matrix);
switch (cs) {
@@ -182,23 +188,23 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs,
}
(*matrix)[0][0] = c * (*cstd)[0][0];
- (*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s *
sinf(h);
- (*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s *
sinf(h);
- (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * b +
- (*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*matrix)[0][1] = (*cstd)[0][1] * x - (*cstd)[0][2] * y;
+ (*matrix)[0][2] = (*cstd)[0][2] * x + (*cstd)[0][1] * y;
+ (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * z +
+ (*cstd)[0][1] * (x * cbbias + y * crbias) +
+ (*cstd)[0][2] * (x * crbias - y * cbbias);
(*matrix)[1][0] = c * (*cstd)[1][0];
- (*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s *
sinf(h);
- (*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s *
sinf(h);
- (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * b +
- (*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*matrix)[1][1] = (*cstd)[1][1] * x - (*cstd)[1][2] * y;
+ (*matrix)[1][2] = (*cstd)[1][2] * x + (*cstd)[1][1] * y;
+ (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * z +
+ (*cstd)[1][1] * (x * cbbias + y * crbias) +
+ (*cstd)[1][2] * (x * crbias - y * cbbias);
(*matrix)[2][0] = c * (*cstd)[2][0];
- (*matrix)[2][1] = c * (*cstd)[2][1] * s * cosf(h) - c * (*cstd)[2][2] * s *
sinf(h);
- (*matrix)[2][2] = c * (*cstd)[2][2] * s * cosf(h) + c * (*cstd)[2][1] * s *
sinf(h);
- (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * b +
- (*cstd)[2][1] * (c * cbbias * s * cosf(h) + c * crbias *
s * sinf(h)) +
- (*cstd)[2][2] * (c * crbias * s * cosf(h) - c * cbbias *
s * sinf(h));
+ (*matrix)[2][1] = (*cstd)[2][1] * x - (*cstd)[2][2] * y;
+ (*matrix)[2][2] = (*cstd)[2][2] * x + (*cstd)[2][1] * y;
+ (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * z +
+ (*cstd)[2][1] * (x * cbbias + y * crbias) +
+ (*cstd)[2][2] * (x * crbias - y * cbbias);
}
--
2.5.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallium/vl: Fix brightness usage v2
Multiplying the contrast- and brightness matrices it becomes obvious that brightness should be multiplied by contrast in the procamp matrix. Fix this. v2: Fixed a couple of typos, one of them affecting the results. Cc: "11.0 11.1 11.2" Signed-off-by: Thomas Hellstrom --- src/gallium/auxiliary/vl/vl_csc.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/src/gallium/auxiliary/vl/vl_csc.c b/src/gallium/auxiliary/vl/vl_csc.c index c8efe28..fc11f73 100644 --- a/src/gallium/auxiliary/vl/vl_csc.c +++ b/src/gallium/auxiliary/vl/vl_csc.c @@ -77,10 +77,10 @@ * [ 0, 0, 0, 1] * * procamp - * [ c, 0, 0, b] - * [ 0, c*s*cos(h), c*s*sin(h), 0] - * [ 0, -c*s*sin(h), c*s*cos(h), 0] - * [ 0, 0, 0, 1] + * [ c, 0, 0, cb] + * [ 0, c*s*cos(h), c*s*sin(h), 0] + * [ 0, -c*s*sin(h), c*s*cos(h), 0] + * [ 0, 0, 0, 1] * * bias * [ 1, 0, 0, ybias] @@ -89,10 +89,10 @@ * [ 0, 0, 0, 1] * * csc - * [ c*cstd[ 0], c*cstd[ 1]*s*cos(h) - c*cstd[ 2]*s*sin(h), c*cstd[ 2]*s*cos(h) + c*cstd[ 1]*s*sin(h), cstd[ 3] + cstd[ 0]*(b + c*ybias) + cstd[ 1]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 2]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] - * [ c*cstd[ 4], c*cstd[ 5]*s*cos(h) - c*cstd[ 6]*s*sin(h), c*cstd[ 6]*s*cos(h) + c*cstd[ 5]*s*sin(h), cstd[ 7] + cstd[ 4]*(b + c*ybias) + cstd[ 5]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 6]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] - * [ c*cstd[ 8], c*cstd[ 9]*s*cos(h) - c*cstd[10]*s*sin(h), c*cstd[10]*s*cos(h) + c*cstd[ 9]*s*sin(h), cstd[11] + cstd[ 8]*(b + c*ybias) + cstd[ 9]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[10]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] - * [ c*cstd[12], c*cstd[13]*s*cos(h) - c*cstd[14]*s*sin(h), c*cstd[14]*s*cos(h) + c*cstd[13]*s*sin(h), cstd[15] + cstd[12]*(b + c*ybias) + cstd[13]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[14]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[ 0], c*cstd[ 1]*s*cos(h) - c*cstd[ 2]*s*sin(h), c*cstd[ 2]*s*cos(h) + c*cstd[ 1]*s*sin(h), cstd[ 3] + cstd[ 0]*c(b + ybias) + cstd[ 1]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 2]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[ 4], c*cstd[ 5]*s*cos(h) - c*cstd[ 6]*s*sin(h), c*cstd[ 6]*s*cos(h) + c*cstd[ 5]*s*sin(h), cstd[ 7] + cstd[ 4]*c*(b + ybias) + cstd[ 5]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[ 6]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[ 8], c*cstd[ 9]*s*cos(h) - c*cstd[10]*s*sin(h), c*cstd[10]*s*cos(h) + c*cstd[ 9]*s*sin(h), cstd[11] + cstd[ 8]*c*(b + ybias) + cstd[ 9]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[10]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] + * [ c*cstd[12], c*cstd[13]*s*cos(h) - c*cstd[14]*s*sin(h), c*cstd[14]*s*cos(h) + c*cstd[13]*s*sin(h), cstd[15] + cstd[12]*c*(b + ybias) + cstd[13]*(c*cbbias*s*cos(h) + c*crbias*s*sin(h)) + cstd[14]*(c*crbias*s*cos(h) - c*cbbias*s*sin(h))] */ /* @@ -210,21 +210,21 @@ void vl_csc_get_matrix(enum VL_CSC_COLOR_STANDARD cs, (*matrix)[0][0] = c * (*cstd)[0][0]; (*matrix)[0][1] = c * (*cstd)[0][1] * s * cosf(h) - c * (*cstd)[0][2] * s * sinf(h); (*matrix)[0][2] = c * (*cstd)[0][2] * s * cosf(h) + c * (*cstd)[0][1] * s * sinf(h); - (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * (b + c * ybias) + + (*matrix)[0][3] = (*cstd)[0][3] + (*cstd)[0][0] * c * (b + ybias) + (*cstd)[0][1] * (c * cbbias * s * cosf(h) + c * crbias * s * sinf(h)) + (*cstd)[0][2] * (c * crbias * s * cosf(h) - c * cbbias * s * sinf(h)); (*matrix)[1][0] = c * (*cstd)[1][0]; (*matrix)[1][1] = c * (*cstd)[1][1] * s * cosf(h) - c * (*cstd)[1][2] * s * sinf(h); (*matrix)[1][2] = c * (*cstd)[1][2] * s * cosf(h) + c * (*cstd)[1][1] * s * sinf(h); - (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * (b + c * ybias) + + (*matrix)[1][3] = (*cstd)[1][3] + (*cstd)[1][0] * c * (b + ybias) + (*cstd)[1][1] * (c * cbbias * s * cosf(h) + c * crbias * s * sinf(h)) + (*cstd)[1][2] * (c * crbias * s * cosf(h) - c * cbbias * s * sinf(h)); (*matrix)[2][0] = c * (*cstd)[2][0]; (*matrix)[2][1] = c * (*cstd)[2][1] * s * cosf(h) - c * (*cstd)[2][2] * s * sinf(h); (*matrix)[2][2] = c * (*cstd)[2][2] * s * cosf(h) + c * (*cstd)[2][1] * s * sinf(h); - (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * (b + c * ybias) + + (*matrix)[2][3] = (*cstd)[2][3] + (*cstd)[2][0] * c * (b + ybias) + (*cstd)[2][1] * (c * cbbias * s * cosf(h) + c * crbias * s * sinf(h)) + (*cstd)[2][2] * (c * crbias * s * cosf(h) - c * cbbias * s * sinf(h)); } -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
