Re: [Mesa-dev] [PATCH 1/2] gbm/dri2: propagate errors when creating a DMA-BUF fd
Bump, could someone push this?
Thanks,
-Nicholas
On Wed, Sep 14, 2016 at 1:06 PM, Nicholas Bishop wrote:
> Thanks for review. Could someone with commit access push this for me?
>
> On Wed, Sep 14, 2016 at 8:48 AM, Eric Engestrom
> wrote:
>> On Thu, Sep 08, 2016 at 03:55:02PM -0400, Nicholas Bishop wrote:
>>> Changed dri2_query_image to check the return value of
>>> resource_get_handle and return GL_FALSE if an error occurs. Similarly
>>> changed gbm_dri_bo_get_fd to check the return value of queryImage and
>>> return -1 (an invalid file descriptor) if an error occurs.
>>>
>>> Updated the comment for gbm_bo_get_fd to say that -1 is returned if
>>> an error occurs.
>>>
>>> For reference this is an example callstack that should propagate the
>>> error back to the user:
>>>
>>> i915_drm_buffer_get_handle
>>> i915_texture_get_handle
>>> u_resource_get_handle_vtbl
>>> dri2_query_image
>>> gbm_dri_bo_get_fd
>>> gbm_bo_get_fd
>>>
>>> Signed-off-by: Nicholas Bishop
>>
>> Looks good to me
>> Reviewed-by: Eric Engestrom
>>
>>> ---
>>> src/gallium/state_trackers/dri/dri2.c | 11 +++
>>> src/gbm/backends/dri/gbm_dri.c| 8 +---
>>> src/gbm/main/gbm.c| 3 ++-
>>> 3 files changed, 14 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/src/gallium/state_trackers/dri/dri2.c
>>> b/src/gallium/state_trackers/dri/dri2.c
>>> index 28f8078..c6260ba 100644
>>> --- a/src/gallium/state_trackers/dri/dri2.c
>>> +++ b/src/gallium/state_trackers/dri/dri2.c
>>> @@ -979,10 +979,13 @@ dri2_query_image(__DRIimage *image, int attrib, int
>>> *value)
>>>return GL_TRUE;
>>> case __DRI_IMAGE_ATTRIB_FD:
>>>whandle.type= DRM_API_HANDLE_TYPE_FD;
>>> - image->texture->screen->resource_get_handle(image->texture->screen,
>>> - image->texture, &whandle, usage);
>>> - *value = whandle.handle;
>>> - return GL_TRUE;
>>> + if
>>> (image->texture->screen->resource_get_handle(image->texture->screen,
>>> + image->texture, &whandle, usage)) {
>>> + *value = whandle.handle;
>>> + return GL_TRUE;
>>> + } else {
>>> + return GL_FALSE;
>>> + }
>>> case __DRI_IMAGE_ATTRIB_FORMAT:
>>>*value = image->dri_format;
>>>return GL_TRUE;
>>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>>> index c3626e3..54b293a 100644
>>> --- a/src/gbm/backends/dri/gbm_dri.c
>>> +++ b/src/gbm/backends/dri/gbm_dri.c
>>> @@ -589,9 +589,11 @@ gbm_dri_bo_get_fd(struct gbm_bo *_bo)
>>> if (bo->image == NULL)
>>>return -1;
>>>
>>> - dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_FD, &fd);
>>> -
>>> - return fd;
>>> + if (dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_FD, &fd)) {
>>> + return fd;
>>> + } else {
>>> + return -1;
>>> + }
>>> }
>>>
>>> static void
>>> diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
>>> index 95b4c2c..c3a2ec33 100644
>>> --- a/src/gbm/main/gbm.c
>>> +++ b/src/gbm/main/gbm.c
>>> @@ -242,7 +242,8 @@ gbm_bo_get_handle(struct gbm_bo *bo)
>>> * descriptor.
>>>
>>> * \param bo The buffer object
>>> - * \return Returns a file descriptor referring to the underlying buffer
>>> + * \return Returns a file descriptor referring to the underlying buffer or
>>> -1
>>> + * if an error occurs.
>>> */
>>> GBM_EXPORT int
>>> gbm_bo_get_fd(struct gbm_bo *bo)
>>> --
>>> 2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] gbm/dri2: propagate errors when creating a DMA-BUF fd
Thanks for review. Could someone with commit access push this for me?
On Wed, Sep 14, 2016 at 8:48 AM, Eric Engestrom
wrote:
> On Thu, Sep 08, 2016 at 03:55:02PM -0400, Nicholas Bishop wrote:
>> Changed dri2_query_image to check the return value of
>> resource_get_handle and return GL_FALSE if an error occurs. Similarly
>> changed gbm_dri_bo_get_fd to check the return value of queryImage and
>> return -1 (an invalid file descriptor) if an error occurs.
>>
>> Updated the comment for gbm_bo_get_fd to say that -1 is returned if
>> an error occurs.
>>
>> For reference this is an example callstack that should propagate the
>> error back to the user:
>>
>> i915_drm_buffer_get_handle
>> i915_texture_get_handle
>> u_resource_get_handle_vtbl
>> dri2_query_image
>> gbm_dri_bo_get_fd
>> gbm_bo_get_fd
>>
>> Signed-off-by: Nicholas Bishop
>
> Looks good to me
> Reviewed-by: Eric Engestrom
>
>> ---
>> src/gallium/state_trackers/dri/dri2.c | 11 +++
>> src/gbm/backends/dri/gbm_dri.c| 8 +---
>> src/gbm/main/gbm.c| 3 ++-
>> 3 files changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/src/gallium/state_trackers/dri/dri2.c
>> b/src/gallium/state_trackers/dri/dri2.c
>> index 28f8078..c6260ba 100644
>> --- a/src/gallium/state_trackers/dri/dri2.c
>> +++ b/src/gallium/state_trackers/dri/dri2.c
>> @@ -979,10 +979,13 @@ dri2_query_image(__DRIimage *image, int attrib, int
>> *value)
>>return GL_TRUE;
>> case __DRI_IMAGE_ATTRIB_FD:
>>whandle.type= DRM_API_HANDLE_TYPE_FD;
>> - image->texture->screen->resource_get_handle(image->texture->screen,
>> - image->texture, &whandle, usage);
>> - *value = whandle.handle;
>> - return GL_TRUE;
>> + if
>> (image->texture->screen->resource_get_handle(image->texture->screen,
>> + image->texture, &whandle, usage)) {
>> + *value = whandle.handle;
>> + return GL_TRUE;
>> + } else {
>> + return GL_FALSE;
>> + }
>> case __DRI_IMAGE_ATTRIB_FORMAT:
>>*value = image->dri_format;
>>return GL_TRUE;
>> diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
>> index c3626e3..54b293a 100644
>> --- a/src/gbm/backends/dri/gbm_dri.c
>> +++ b/src/gbm/backends/dri/gbm_dri.c
>> @@ -589,9 +589,11 @@ gbm_dri_bo_get_fd(struct gbm_bo *_bo)
>> if (bo->image == NULL)
>>return -1;
>>
>> - dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_FD, &fd);
>> -
>> - return fd;
>> + if (dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_FD, &fd)) {
>> + return fd;
>> + } else {
>> + return -1;
>> + }
>> }
>>
>> static void
>> diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
>> index 95b4c2c..c3a2ec33 100644
>> --- a/src/gbm/main/gbm.c
>> +++ b/src/gbm/main/gbm.c
>> @@ -242,7 +242,8 @@ gbm_bo_get_handle(struct gbm_bo *bo)
>> * descriptor.
>>
>> * \param bo The buffer object
>> - * \return Returns a file descriptor referring to the underlying buffer
>> + * \return Returns a file descriptor referring to the underlying buffer or
>> -1
>> + * if an error occurs.
>> */
>> GBM_EXPORT int
>> gbm_bo_get_fd(struct gbm_bo *bo)
>> --
>> 2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal: move the Mesa documentation to readthedocs.org
Good questions, > 1. How can we minimize the effort of maintaining two repositories? (I don't > think anyone here would support dropping the HTML docs, as they feed into > the main Mesa website). I agree that maintaining two repos would be bad, but we don't need to do that. Sphinx can generate HTML from RST in combination with a style template to provide the look 'n feel. This is what Read The Docs does: http://docs.readthedocs.io/en/latest/builds.html#sphinx For Mesa's website we could either pre-generate the HTML and store it in the mesa git repo alongside the RST sources, or it could be done in a separate update-the-website script. I'm not sure how Mesa's website is currently deployed. > 2. How easy it is to automate the additional tweaks you mention? Scriptable? Assuming that RST becomes the canonical source for the HTML it'll be a one time deal; we use pandoc to automate the initial conversion as shown in my github repo, then manually fix any formatting issues. I'm not sure how long it would take, but I'm happy to take on that work if there's buy-in from the project maintainers. -Nicholas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i915g: add dma-buf support to i915_drm_buffer_get_handle
The implementation of i915_drm_buffer_get_handle now handles
DRM_API_HANDLE_TYPE_FD in the same way that intel_winsys_import_handle
does, by calling drm_intel_bo_gem_create_from_prime.
Tested by successfully running Chrome's ozone_demo [1] with the
ozone-gbm backend on an Intel Pineview M machine. Without this change
it fails while trying to create a DMA-BUF.
[1]
https://chromium.googlesource.com/chromium/src.git/+/master/ui/ozone/demo/ozone_demo.cc
Signed-off-by: Nicholas Bishop
---
src/gallium/winsys/i915/drm/i915_drm_buffer.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/gallium/winsys/i915/drm/i915_drm_buffer.c
b/src/gallium/winsys/i915/drm/i915_drm_buffer.c
index ba454ec..4080a08 100644
--- a/src/gallium/winsys/i915/drm/i915_drm_buffer.c
+++ b/src/gallium/winsys/i915/drm/i915_drm_buffer.c
@@ -153,6 +153,14 @@ i915_drm_buffer_get_handle(struct i915_winsys *iws,
whandle->handle = buf->flink;
} else if (whandle->type == DRM_API_HANDLE_TYPE_KMS) {
whandle->handle = buf->bo->handle;
+ } else if (whandle->type == DRM_API_HANDLE_TYPE_FD) {
+ int fd;
+ int err;
+
+ err = drm_intel_bo_gem_export_to_prime(buf->bo, &fd);
+ if (err)
+ return FALSE;
+ whandle->handle = fd;
} else {
assert(!"unknown usage");
return FALSE;
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] gbm/dri2: propagate errors when creating a DMA-BUF fd
Changed dri2_query_image to check the return value of
resource_get_handle and return GL_FALSE if an error occurs. Similarly
changed gbm_dri_bo_get_fd to check the return value of queryImage and
return -1 (an invalid file descriptor) if an error occurs.
Updated the comment for gbm_bo_get_fd to say that -1 is returned if
an error occurs.
For reference this is an example callstack that should propagate the
error back to the user:
i915_drm_buffer_get_handle
i915_texture_get_handle
u_resource_get_handle_vtbl
dri2_query_image
gbm_dri_bo_get_fd
gbm_bo_get_fd
Signed-off-by: Nicholas Bishop
---
src/gallium/state_trackers/dri/dri2.c | 11 +++
src/gbm/backends/dri/gbm_dri.c| 8 +---
src/gbm/main/gbm.c| 3 ++-
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/src/gallium/state_trackers/dri/dri2.c
b/src/gallium/state_trackers/dri/dri2.c
index 28f8078..c6260ba 100644
--- a/src/gallium/state_trackers/dri/dri2.c
+++ b/src/gallium/state_trackers/dri/dri2.c
@@ -979,10 +979,13 @@ dri2_query_image(__DRIimage *image, int attrib, int
*value)
return GL_TRUE;
case __DRI_IMAGE_ATTRIB_FD:
whandle.type= DRM_API_HANDLE_TYPE_FD;
- image->texture->screen->resource_get_handle(image->texture->screen,
- image->texture, &whandle, usage);
- *value = whandle.handle;
- return GL_TRUE;
+ if (image->texture->screen->resource_get_handle(image->texture->screen,
+ image->texture, &whandle, usage)) {
+ *value = whandle.handle;
+ return GL_TRUE;
+ } else {
+ return GL_FALSE;
+ }
case __DRI_IMAGE_ATTRIB_FORMAT:
*value = image->dri_format;
return GL_TRUE;
diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c
index c3626e3..54b293a 100644
--- a/src/gbm/backends/dri/gbm_dri.c
+++ b/src/gbm/backends/dri/gbm_dri.c
@@ -589,9 +589,11 @@ gbm_dri_bo_get_fd(struct gbm_bo *_bo)
if (bo->image == NULL)
return -1;
- dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_FD, &fd);
-
- return fd;
+ if (dri->image->queryImage(bo->image, __DRI_IMAGE_ATTRIB_FD, &fd)) {
+ return fd;
+ } else {
+ return -1;
+ }
}
static void
diff --git a/src/gbm/main/gbm.c b/src/gbm/main/gbm.c
index 95b4c2c..c3a2ec33 100644
--- a/src/gbm/main/gbm.c
+++ b/src/gbm/main/gbm.c
@@ -242,7 +242,8 @@ gbm_bo_get_handle(struct gbm_bo *bo)
* descriptor.
* \param bo The buffer object
- * \return Returns a file descriptor referring to the underlying buffer
+ * \return Returns a file descriptor referring to the underlying buffer or -1
+ * if an error occurs.
*/
GBM_EXPORT int
gbm_bo_get_fd(struct gbm_bo *bo)
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Proposal: move the Mesa documentation to readthedocs.org
Bump, any interest in this? On Sat, Aug 27, 2016 at 1:09 AM, Nicholas Bishop wrote: > Hi, > > I'd like to propose a conversion of Mesa's documentation to > reStructuredText (RST) and hosting the result on readthedocs.org. The > intent is to make Mesa's documentation more accessible, searchable, and > easier to edit. > > I put together a quick proof-of-concept here: > > http://mesa-docs.readthedocs.io/en/latest/intro.html > > (For comparison: http://mesa3d.org/intro.html) > > Readthedocs.org essentially renders either Markdown or RST from a git > repository (or other VCS) into a nice pretty set of HTML pages. (I'm more > familiar with Markdown than RST, but I saw the Gallium docs are already > using RST on readthedocs.org.) > > Putting the content in RST and on readthedocs.org makes formatting and > searching easy, and it's a familiar platform for many developers. > > For the linked proof-of-concept I used pandoc (http://pandoc.org/) to > convert all the HTML pages to RST, on top of which I did some minor editing > to make the table of contents look reasonable. It's by no means a finished > conversion, but I hope having something to look at can make discussion > easier. This is all just a few hours work, but of course proofing and > correcting all the text/formatting would take somewhat longer. > > Here's the git repo that readthedocs.org is pulling from: > https://github.com/nicholasbishop/mesa-docs/tree/master/docs > > Thoughts? > > -Nicholas > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Proposal: move the Mesa documentation to readthedocs.org
Hi, I'd like to propose a conversion of Mesa's documentation to reStructuredText (RST) and hosting the result on readthedocs.org. The intent is to make Mesa's documentation more accessible, searchable, and easier to edit. I put together a quick proof-of-concept here: http://mesa-docs.readthedocs.io/en/latest/intro.html (For comparison: http://mesa3d.org/intro.html) Readthedocs.org essentially renders either Markdown or RST from a git repository (or other VCS) into a nice pretty set of HTML pages. (I'm more familiar with Markdown than RST, but I saw the Gallium docs are already using RST on readthedocs.org.) Putting the content in RST and on readthedocs.org makes formatting and searching easy, and it's a familiar platform for many developers. For the linked proof-of-concept I used pandoc (http://pandoc.org/) to convert all the HTML pages to RST, on top of which I did some minor editing to make the table of contents look reasonable. It's by no means a finished conversion, but I hope having something to look at can make discussion easier. This is all just a few hours work, but of course proofing and correcting all the text/formatting would take somewhat longer. Here's the git repo that readthedocs.org is pulling from: https://github.com/nicholasbishop/mesa-docs/tree/master/docs Thoughts? -Nicholas ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: add links to clarify patch mailing section
From: Nicholas Bishop * Changed "Mesa mailing list" to "mesa-dev mailing list" to clarify which list patches should be sent to * Added an explicit link to https://lists.freedesktop.org/mailman/listinfo/mesa-dev to show where to subscribe to the list * Added a link to https://git-scm.com/docs/git-send-email to help new users of that command v2: add signed-off-by Signed-off-by: Nicholas Bishop --- docs/devinfo.html | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/devinfo.html b/docs/devinfo.html index 489d263..e13837c 100644 --- a/docs/devinfo.html +++ b/docs/devinfo.html @@ -252,10 +252,14 @@ check for regressions. Mailing Patches -Patches should be sent to the Mesa mailing list for review. -When submitting a patch make sure to use git send-email rather than attaching -patches to emails. Sending patches as attachments prevents people from being -able to provide in-line review comments. +Patches should be sent to the mesa-dev mailing list for review: +https://lists.freedesktop.org/mailman/listinfo/mesa-dev";> +mesa-dev@lists.freedesktop.org. +When submitting a patch make sure to use +https://git-scm.com/docs/git-send-email";>git send-email +rather than attaching patches to emails. Sending patches as +attachments prevents people from being able to provide in-line review +comments. -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] docs: add links to clarify patch mailing section
From: Nicholas Bishop - Changed "Mesa mailing list" to "mesa-dev mailing list" to clarify which list patches should be sent to - Added an explicit link to https://lists.freedesktop.org/mailman/listinfo/mesa-dev to show where to subscribe to the list - Added a link to https://git-scm.com/docs/git-send-email to help new users of that command --- docs/devinfo.html | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/devinfo.html b/docs/devinfo.html index 489d263..e13837c 100644 --- a/docs/devinfo.html +++ b/docs/devinfo.html @@ -252,10 +252,14 @@ check for regressions. Mailing Patches -Patches should be sent to the Mesa mailing list for review. -When submitting a patch make sure to use git send-email rather than attaching -patches to emails. Sending patches as attachments prevents people from being -able to provide in-line review comments. +Patches should be sent to the mesa-dev mailing list for review: +https://lists.freedesktop.org/mailman/listinfo/mesa-dev";> +mesa-dev@lists.freedesktop.org. +When submitting a patch make sure to use +https://git-scm.com/docs/git-send-email";>git send-email +rather than attaching patches to emails. Sending patches as +attachments prevents people from being able to provide in-line review +comments. -- 2.7.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i915g: fix incorrect gl_FragCoord value
From: Nicholas Bishop
On Intel Pineview M hardware, the i915 gallium driver doesn't output
the correct gl_FragCoord. It seems to always have an X coord of 0.0
and a Y coord of the window's height in pixels, e.g. 600.0f or such.
I believe this is a regression caused in part by this commit:
afa035031ff9e0c07a2297d864e46c76f7bfff58
The old behavior used the output at index zero, while the new behavior
uses actual zeroes. In the case of gl_FragCoord the output at index
zero happened to be the correct one, so the behavior appeared correct
although the code already had a bug.
Fixed by checking for I915_SEMANTIC_POS when setting up texCoords. If
the generic_mapping is I915_SEMANTIC_POS, look for the
TGSI_SEMANTIC_POSITION instead of a TGSI_SEMANTIC_GENERIC output.
https://bugs.freedesktop.org/show_bug.cgi?id=97477
---
src/gallium/drivers/i915/i915_state_derived.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/gallium/drivers/i915/i915_state_derived.c
b/src/gallium/drivers/i915/i915_state_derived.c
index 177b854..dbfbc84 100644
--- a/src/gallium/drivers/i915/i915_state_derived.c
+++ b/src/gallium/drivers/i915/i915_state_derived.c
@@ -145,7 +145,12 @@ static void calculate_vertex_layout(struct i915_context
*i915)
uint hwtc;
if (texCoords[i]) {
hwtc = TEXCOORDFMT_4D;
- src = draw_find_shader_output(i915->draw, TGSI_SEMANTIC_GENERIC,
fs->generic_mapping[i]);
+ if (fs->generic_mapping[i] == I915_SEMANTIC_POS) {
+src = draw_find_shader_output(i915->draw, TGSI_SEMANTIC_POSITION,
0);
+ }
+ else {
+src = draw_find_shader_output(i915->draw, TGSI_SEMANTIC_GENERIC,
fs->generic_mapping[i]);
+ }
draw_emit_vertex_attr(&vinfo, EMIT_4F, src);
}
else {
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
