Re: [Piglit] [PATCH v3] pbo: delete unmapping the GL_PIXEL_UNPACK_BUFFER before using it and correct the data expected form glGetMapusv This fixes tests/spec/gl-2.1/pbo on Windows Intel driver. Accord

2017-06-06 Thread Józef Kucia
On Thu, Jun 1, 2017 at 1:11 PM, sandra koroniewska
 wrote:
> Hi,
> this change fixes a real problem for me (a crash on an Intel driver).
> I don't know if I understand this right, but for glPixelMap there is written
> in a spec (core 2.1, page 117): "If a pixel unpack buffer is bound (as
> indicated by a non-zero value of PIXEL UNPACK BUFFER BINDING), values is an
> offset into the pixel unpack buffer; otherwise, values is a pointer to
> client memory"
>
> There is a call after glUnmapBuffer:
> glPixelMapusv(GL_PIXEL_MAP_R_TO_R, max, NULL);
>
> So I understand that this "NULL" is an offset into the pixel unpack buffer,
> because it doesn't look like a pointer to client memory. But when I unmap
> it, the pointer is invalid, so there is a crash in this function.
> Tell me if I'm wrong, but I'm not sure if pbo_mem is not used.

PIXEL UNPACK BUFFER BINDING is changed using glBindBuffer() command.
glUnmapBuffer() does not modify buffer bindings.
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit


Re: [Piglit] [PATCH v3] pbo: delete unmapping the GL_PIXEL_UNPACK_BUFFER before using it and correct the data expected form glGetMapusv This fixes tests/spec/gl-2.1/pbo on Windows Intel driver. Accord

2017-05-25 Thread Józef Kucia
Hi Sandra,

On Thu, May 25, 2017 at 4:38 PM, sandra koroniewska
 wrote:
> Hi Józef,
> sorry for responding here, but I didn't manage to send the corrections in
> response to your previous mail. Thanks for your answer. The fragment of your
> previous mail is:
>
> When it comes to unmapping the buffer, I don't know if I'm thinking right,
> but I read in OpenGL 4.5 spec that "Unmapping a mapped buffer object
> invalidates the pointer to its data store" and glUnmapBuffer is using a
> pointer to GL_PIXEL_UNPACK_BUFFER.

In this case, glUnmapBuffer() invalidates the "pbo_mem" pointer which
was returned by the previous call to glMapBuffer(). After the call to
glUnmapBuffer() the "pbo_mem" pointer is not used so I don't see a
reason to remove this glUnmapBuffer() call. The glPixelMapusv() calls
in the test use a buffer bound to GL_PIXEL_UNPACK_BUFFER, but the
buffer doesn't have to be mapped.

Does your change fix a real problem for you?

Thanks,
Józef
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit


Re: [Piglit] [PATCH v3] pbo: delete unmapping the GL_PIXEL_UNPACK_BUFFER before using it and correct the data expected form glGetMapusv This fixes tests/spec/gl-2.1/pbo on Windows Intel driver. Accord

2017-05-25 Thread sandra koroniewska
Hi Józef,
sorry for responding here, but I didn't manage to send the corrections in
response to your previous mail. Thanks for your answer. The fragment of
your previous mail is:

"> -   glUnmapBufferARB(GL_PIXEL_UNP
ACK_BUFFER_ARB);

This change is suspicious. The buffer was mapped to fill it with
values above, and it can be safely unmapped at this point. Why do you
need this change?

> glPixelMapusv(GL_PIXEL_MAP_R_TO_R, max,
NULL);
> glPixelMapusv(GL_PIXEL_MAP_G_TO_G, max,
NULL);
> glPixelMapusv(GL_PIXEL_MAP_B_TO_B, max,
NULL);
> @@ -353,7 +352,7 @@ test_pixel_map(void)
> }
>
> for (i = 0; i < max; i++) {
> -   if (pbo_mem[i] != (255 - i)) {
> +if (pbo_mem[i] != (max - i - 1)) {

Please use tabs instead of spaces. Otherwise, this seems to be a
correct fix. I guess that the previous version of the test passes with
some drivers probably because "max" is equal to 256."

When it comes to unmapping the buffer, I don't know if I'm thinking right,
but I read in OpenGL 4.5 spec that "Unmapping a mapped buffer object
invalidates the pointer to its data store" and glUnmapBuffer is using a
pointer to GL_PIXEL_UNPACK_BUFFER.

Regards,
Sandra
___
Piglit mailing list
Piglit@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/piglit