Re: [Mesa-dev] winsys/svga/drm: Include sys/types.h
Reviewed-by: Sinclair Yeh On Tue, Jun 12, 2018 at 03:27:04PM +0100, Ross Burton wrote: > From: Khem Raj > > vmw_screen.h uses dev_t which is defines in sys/types.h > this header is required to be included for getting dev_t > definition. This issue happens on musl C library, it is hidden > on glibc since sys/types.h is included through another > system headers > > Upstream-Status: Submitted > Signed-off-by: Khem Raj > --- > src/gallium/winsys/svga/drm/vmw_screen.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/gallium/winsys/svga/drm/vmw_screen.h > b/src/gallium/winsys/svga/drm/vmw_screen.h > index f21cabb51f..4c972fdaa9 100644 > --- a/src/gallium/winsys/svga/drm/vmw_screen.h > +++ b/src/gallium/winsys/svga/drm/vmw_screen.h > @@ -41,6 +41,7 @@ > #include "svga_winsys.h" > #include "pipebuffer/pb_buffer_fenced.h" > #include > +#include > > #define VMW_GMR_POOL_SIZE (16*1024*1024) > #define VMW_QUERY_POOL_SIZE (8192) > -- > 2.17.1 > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glapi: add glBlendBarrier(), glPrimitiveBoundingBox() prototypes
Reviewed-by: Sinclair Yeh <s...@vmware.com> On Mon, Mar 26, 2018 at 04:56:22PM -0600, Brian Paul wrote: > in glapi_dispatch.c, as we have for many other GLES functions. > Fixes a cross-compile issue (missing prototype) when GLES support > is disabled. > --- > src/mapi/glapi/glapi_dispatch.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/src/mapi/glapi/glapi_dispatch.c b/src/mapi/glapi/glapi_dispatch.c > index 269adc7..3239523 100644 > --- a/src/mapi/glapi/glapi_dispatch.c > +++ b/src/mapi/glapi/glapi_dispatch.c > @@ -143,6 +143,8 @@ GL_API void GL_APIENTRY glTexParameterx (GLenum target, > GLenum pname, GLfixed pa > GL_API void GL_APIENTRY glTexParameterxv (GLenum target, GLenum pname, const > GLfixed *params); > GL_API void GL_APIENTRY glTranslatex (GLfixed x, GLfixed y, GLfixed z); > GL_API void GL_APIENTRY glPointSizePointerOES (GLenum type, GLsizei stride, > const GLvoid *pointer); > +GL_API void GL_APIENTRY glBlendBarrier (void); > +GL_API void GL_APIENTRY glPrimitiveBoundingBox (GLfloat minX, GLfloat minY, > GLfloat minZ, GLfloat minW, GLfloat maxX, GLfloat maxY, GLfloat maxZ, GLfloat > maxW); > > /* Enable frame pointer elimination on Windows, otherwise forgetting to add > * APIENTRY to _mesa_* entrypoints will not cause crashes on debug builds, as > -- > 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/3] loader/dri3: Use local blits and local buffers when resizing
On Tue, Oct 03, 2017 at 02:16:42PM +0200, Thomas Hellstrom wrote:
> Hi!
>
> Could anyone please review this series?
>
> Thanks,
> Thomas
Minor typo in the commit message of 1/3:
[Mesa-dev] [PATCH 1/3] loader/dri3: Use local blits and local buffers when
resizing
When a drawable is resized, and we we fill the resized buffers, with data
^
typo
For 3/3, I don't know which buffer LOADER_DRI3_FRONT_ID represents, so I'm
assuming that line checks the correct condition.
Other than those the series: Reviewed-by: Sinclair Yeh <s...@vmware.com>
>
>
> On 09/15/2017 10:48 AM, Thomas Hellstrom wrote:
> > When a drawable is resized, and we we fill the resized buffers, with data
> > from the old buffers, use a local blit if there is a local buffer (back or
> > fake front), and we have local blitting capability.
> >
> > Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
> > ---
> > src/loader/loader_dri3_helper.c | 50
> > -
> > 1 file changed, 24 insertions(+), 26 deletions(-)
> >
> > diff --git a/src/loader/loader_dri3_helper.c
> > b/src/loader/loader_dri3_helper.c
> > index bcd5a66..aea0f68 100644
> > --- a/src/loader/loader_dri3_helper.c
> > +++ b/src/loader/loader_dri3_helper.c
> > @@ -1373,30 +1373,30 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> > /* When resizing, copy the contents of the old buffer, waiting for
> > that
> > * copy to complete using our fences before proceeding
> > */
> > - switch (buffer_type) {
> > - case loader_dri3_buffer_back:
> > - if (buffer) {
> > -if (!buffer->linear_buffer) {
> > - dri3_fence_reset(draw->conn, new_buffer);
> > - dri3_fence_await(draw->conn, draw, buffer);
> > - dri3_copy_area(draw->conn,
> > - buffer->pixmap,
> > - new_buffer->pixmap,
> > - dri3_drawable_gc(draw),
> > - 0, 0, 0, 0,
> > - draw->width, draw->height);
> > - dri3_fence_trigger(draw->conn, new_buffer);
> > -} else if (draw->vtable->in_current_context(draw)) {
> > - (void) loader_dri3_blit_image(draw,
> > - new_buffer->image,
> > - buffer->image,
> > - 0, 0, draw->width,
> > draw->height,
> > - 0, 0, 0);
> > -}
> > -dri3_free_render_buffer(draw, buffer);
> > + if ((buffer_type == loader_dri3_buffer_back ||
> > + (buffer_type == loader_dri3_buffer_front &&
> > draw->have_fake_front))
> > + && buffer) {
> > +
> > + /* Fill the new buffer with data from an old buffer */
> > + dri3_fence_await(draw->conn, draw, buffer);
> > + if (!loader_dri3_blit_image(draw,
> > + new_buffer->image,
> > + buffer->image,
> > + 0, 0, draw->width, draw->height,
> > + 0, 0, 0) &&
> > + !buffer->linear_buffer) {
> > +dri3_fence_reset(draw->conn, new_buffer);
> > +dri3_copy_area(draw->conn,
> > + buffer->pixmap,
> > + new_buffer->pixmap,
> > + dri3_drawable_gc(draw),
> > + 0, 0, 0, 0,
> > + draw->width, draw->height);
> > +dri3_fence_trigger(draw->conn, new_buffer);
> >}
> > - break;
> > - case loader_dri3_buffer_front:
> > + dri3_free_render_buffer(draw, buffer);
> > + } else if (buffer_type == loader_dri3_buffer_front) {
> > + /* Fill the new fake front with data from a real front */
> >loader_dri3_swapbuffer_barrier(draw);
> >dri3_fence_reset(draw->conn, new_buffer);
> >dri3_copy_area(draw->conn,
> > @@ -1407,8 +1407,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> > draw->width, draw->height);
> >dri3_fence_trigger
Re: [Mesa-dev] [PATCH 0/4] dri3, gallium: Correctness and performance fixes v2
Reviewed-by: Sinclair Yeh <s...@vmware.com> On Wed, Aug 02, 2017 at 02:23:52PM +0200, Thomas Hellstrom wrote: > In v2 of the patch series, one freestanding patch has already been committed > and the back-to-fake-front flip patch has been dropped since it requires some > more work to not break EGL. Remaining is actually only the parts that allow > glFinish to be used instead of glXWaitGL. > > Main changes except some merge conflict fixups are that patch 1 and 2 was > previously a single patch and that the image loader extension number is > actually bumped to allow using the new functionality. It should probably be > sufficient to review patches 1 and 2. > > Thanks, > Thomas > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] dri3, gallium: Correctness and performance fixes
This series: Reviewed-by: Sinclair Yeh <s...@vmware.com> On Thu, Jun 22, 2017 at 12:42:32PM +0200, Thomas Hellstrom wrote: > A patch series that deals with dri3 correctness- and performance fixes. > > The corectness fixes attempts to deal with the fact that we need to wait for > all pending swapbuffers before we touch the front buffer. Otherwise a > front buffer change may be overwritten by a pending swapbuffer when it > was actually intended to be drawn *after* the swapbuffer. Also a post > swapbuffer front read could actually occur *before* the swapbuffer. > > Patch 1 deals with the dri3 internal synchronization. All frontbuffer > accesses introduce a "swapbuffer barrier" to order with respect to > pending swapbuffers. > The exception is _WaitX because if we call _WaitX we're ordering with > respect to X rendering and if there are pending swapbuffers, an application > would already have called _WaitGL to be able to do the X rendering correctly, > and _WaitGL is ordering with respect to pending swapbuffers. This patch > fixes the piglit copysubbuffer test. > > Patch 2 to 4 deals with having glFinish() order with respect to pending > swapbuffers. The behaviour is actually not correct in that it doesn't wait > for the pending swapbuffers to complete, but a user shouldn't be able to > tell the difference. This patch series is motivated by the fact that the > glXWaitGL man page states that glFinish() can be used instead of glXWaitGL, > and without this series it can't. The functionality is only implemented for > gallium. Other drivers need to provide their own implementation. Ideally > we should have accomplished this without the dri interface changes by > calling an unconditional flush_frontbuffer, but at least the gallium > flush_frontbuffer implementation is relying on us having a fake front which > is not always the case. > > Patch 5 replaces the back-to-fake-front full buffer copies with a swap > during swapbuffers. Should be saving a lot of work when we actually have a > fake front. There were some conserns raised when this was posted as an RFC > that the separate-server-gpu case would be broken as well as the buffer > age functionality. I've audited the code and I think that's not the case. > The piglit buffer age test still reports a pass after this change. The > separate-server-gpu case I guess needs additional testing. > > Tested wih piglit -quick without regressions. > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: Reduce the number of frontbuffer flush calls
Reviewed-by: Sinclair Yeh <s...@vmware.com>
On Thu, Jun 22, 2017 at 01:00:39PM +0200, Thomas Hellstrom wrote:
> The mesa state tracker was needlessly flushing the front buffer even if it
> hadn't been drawn to since the last flush. This was happening during
> glXSwapBuffers if we at some point previously had set that frontbuffer as
> a read- or draw renderbuffer, or at glFlush() or glFinish() if we at some
> point previously had rendered to the front buffer. Since the frontbuffer
> flush typically means a full drawable copy, it's a pretty big waste.
>
> Signed-off-by: Thomas Hellstrom <thellst...@vmware.com>
> ---
> src/mesa/state_tracker/st_cb_flush.c | 37
> ++--
> src/mesa/state_tracker/st_manager.c | 12
> 2 files changed, 10 insertions(+), 39 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_flush.c
> b/src/mesa/state_tracker/st_cb_flush.c
> index e8c6672..5a26018 100644
> --- a/src/mesa/state_tracker/st_cb_flush.c
> +++ b/src/mesa/state_tracker/st_cb_flush.c
> @@ -46,35 +46,6 @@
> #include "util/u_gen_mipmap.h"
>
>
> -/** Check if we have a front color buffer and if it's been drawn to. */
> -static inline GLboolean
> -is_front_buffer_dirty(struct st_context *st)
> -{
> - struct gl_framebuffer *fb = st->ctx->DrawBuffer;
> - struct st_renderbuffer *strb
> - = st_renderbuffer(fb->Attachment[BUFFER_FRONT_LEFT].Renderbuffer);
> - return strb && strb->defined;
> -}
> -
> -
> -/**
> - * Tell the screen to display the front color buffer on-screen.
> - */
> -static void
> -display_front_buffer(struct st_context *st)
> -{
> - struct gl_framebuffer *fb = st->ctx->DrawBuffer;
> - struct st_renderbuffer *strb
> - = st_renderbuffer(fb->Attachment[BUFFER_FRONT_LEFT].Renderbuffer);
> -
> - if (strb) {
> - /* Hook for copying "fake" frontbuffer if necessary:
> - */
> - st_manager_flush_frontbuffer(st);
> - }
> -}
> -
> -
> void st_flush(struct st_context *st,
>struct pipe_fence_handle **fence,
>unsigned flags)
> @@ -122,9 +93,7 @@ static void st_glFlush(struct gl_context *ctx)
> */
> st_flush(st, NULL, 0);
>
> - if (is_front_buffer_dirty(st)) {
> - display_front_buffer(st);
> - }
> + st_manager_flush_frontbuffer(st);
> }
>
>
> @@ -137,9 +106,7 @@ static void st_glFinish(struct gl_context *ctx)
>
> st_finish(st);
>
> - if (is_front_buffer_dirty(st)) {
> - display_front_buffer(st);
> - }
> + st_manager_flush_frontbuffer(st);
> }
>
>
> diff --git a/src/mesa/state_tracker/st_manager.c
> b/src/mesa/state_tracker/st_manager.c
> index 9978e3f..ea67097 100644
> --- a/src/mesa/state_tracker/st_manager.c
> +++ b/src/mesa/state_tracker/st_manager.c
> @@ -839,11 +839,15 @@ st_manager_flush_frontbuffer(struct st_context *st)
>
> if (stfb)
>strb =
> st_renderbuffer(stfb->Base.Attachment[BUFFER_FRONT_LEFT].Renderbuffer);
> - if (!strb)
> - return;
>
> - /* never a dummy fb */
> - stfb->iface->flush_front(>iface, stfb->iface,
> ST_ATTACHMENT_FRONT_LEFT);
> + /* Do we have a front color buffer and has it been drawn to since last
> +* frontbuffer flush?
> +*/
> + if (strb && strb->defined) {
> + stfb->iface->flush_front(>iface, stfb->iface,
> + ST_ATTACHMENT_FRONT_LEFT);
> + strb->defined = GL_FALSE;
> + }
> }
>
> /**
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] problem on building vmwgfx
On Tue, Feb 28, 2017 at 04:41:48PM +, Eric Engestrom wrote: > > Looks like there are more issues than I thought. > I don't know this codebase at all, I just recognized the first error you > saw and knew how to fix it. > > For more in-depth help, I suggest asking Sinclair or Thomas (both Cc'ed). > > Cheers, > Eric Hi, I checked in quite a bit of new code a few days ago, and this looks like a build problem with kernel 3.13.x. Zhiguang, if you need something immediately, just check out a version of the vmwgfx from last week and it should build fine. I'll take a look at this. Sinclair ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] main: uses casts to silence some _mesa_debug() format warnings
Reviewed-by: Sinclair Yeh <s...@vmware.com>
On Mon, May 02, 2016 at 07:15:11PM -0600, Brian Paul wrote:
> Silences warnings with 32-bit Linux gcc builds and MinGW which doesn't
> recognize the âtâ conversion character.
> ---
> src/mesa/main/bufferobj.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/src/mesa/main/bufferobj.c b/src/mesa/main/bufferobj.c
> index 731b62e..e60a8ea 100644
> --- a/src/mesa/main/bufferobj.c
> +++ b/src/mesa/main/bufferobj.c
> @@ -2487,8 +2487,9 @@ _mesa_map_buffer_range(struct gl_context *ctx,
>
> if (offset + length > bufObj->Size) {
>_mesa_error(ctx, GL_INVALID_VALUE,
> - "%s(offset %td + length %td > buffer_size %td)", func,
> - offset, length, bufObj->Size);
> + "%s(offset %lu + length %lu > buffer_size %lu)", func,
> + (unsigned long) offset, (unsigned long) length,
> + (unsigned long) bufObj->Size);
>return NULL;
> }
>
> @@ -3749,8 +3750,9 @@ _mesa_BindBufferRange(GLenum target, GLuint index,
> struct gl_buffer_object *bufObj;
>
> if (MESA_VERBOSE & VERBOSE_API) {
> - _mesa_debug(ctx, "glBindBufferRange(%s, %u, %u, %ld, %ld)\n",
> - _mesa_enum_to_string(target), index, buffer, offset, size);
> + _mesa_debug(ctx, "glBindBufferRange(%s, %u, %u, %lu, %lu)\n",
> + _mesa_enum_to_string(target), index, buffer,
> + (unsigned long) offset, (unsigned long) size);
> }
>
> if (buffer == 0) {
> --
> 1.9.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/4] nir: Avoid C99 field initializers.
Maybe add a short commit message for 3/4
Reviewed-by: Sinclair Yeh <s...@vmware.com>
On Thu, Apr 28, 2016 at 12:27:05PM +0100, Jose Fonseca wrote:
> As they are not standard C++ and are not supported by MSVC C++ compiler.
>
> Just have nir_imm_double match nir_imm_float above.
> ---
> src/compiler/nir/nir_builder.h | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/src/compiler/nir/nir_builder.h b/src/compiler/nir/nir_builder.h
> index a14f9ef..4fa9779 100644
> --- a/src/compiler/nir/nir_builder.h
> +++ b/src/compiler/nir/nir_builder.h
> @@ -117,9 +117,12 @@ nir_imm_float(nir_builder *build, float x)
> static inline nir_ssa_def *
> nir_imm_double(nir_builder *build, double x)
> {
> - nir_const_value v = { { .f64 = {x, 0, 0, 0} } };
> - nir_ssa_def *def = nir_build_imm(build, 1, 64, v);
> - return def;
> + nir_const_value v;
> +
> + memset(, 0, sizeof(v));
> + v.f64[0] = x;
> +
> + return nir_build_imm(build, 1, 64, v);
> }
>
> static inline nir_ssa_def *
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] include/GL: fix the interop header for a --disable-glx build
Minor comment below. Either way:
Reviewed-by: Sinclair Yeh <s...@vmware.com>
On Wed, Apr 20, 2016 at 05:52:17PM +0200, Mircea Gherzan wrote:
> This header should not blindly include the GLX and should also
> conditionally define functions that use GLX parameters. The
> MESA_EGL_NO_X11_HEADERS macro is used to check if we're building without
> GLX support.
>
> Signed-off-by: Mircea Gherzan <mircea.gher...@intel.com>
> ---
> include/GL/mesa_glinterop.h | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/include/GL/mesa_glinterop.h b/include/GL/mesa_glinterop.h
> index 814064d..cd3151f 100644
> --- a/include/GL/mesa_glinterop.h
> +++ b/include/GL/mesa_glinterop.h
> @@ -50,7 +50,12 @@
> #ifndef MESA_GLINTEROP_H
> #define MESA_GLINTEROP_H
>
> +#ifdef MESA_EGL_NO_X11_HEADERS
> +#include
> +#else
> #include
> +#endif
> +
> #include
>
> #ifdef __cplusplus
> @@ -219,6 +224,7 @@ typedef struct _mesa_glinterop_export_out {
> } mesa_glinterop_export_out;
>
>
> +#ifndef MESA_EGL_NO_X11_HEADERS
Assuming rearranging the code won't cause too many issues, instead of
the double negative, "#ifdef MESA_EGL_NO_X11_HEADER" is easier to
read.
> /**
> * Query device information.
> *
> @@ -232,16 +238,6 @@ GLAPI int GLAPIENTRY
> MesaGLInteropGLXQueryDeviceInfo(Display *dpy, GLXContext context,
> mesa_glinterop_device_info *out);
>
> -
> -/**
> - * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
> - * and EGLContext.
> - */
> -GLAPI int GLAPIENTRY
> -MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> -mesa_glinterop_device_info *out);
> -
> -
> /**
> * Create and return a DMABUF handle corresponding to the given OpenGL
> * object, and return other parameters about the OpenGL object.
> @@ -258,6 +254,20 @@ MesaGLInteropGLXExportObject(Display *dpy, GLXContext
> context,
> const mesa_glinterop_export_in *in,
> mesa_glinterop_export_out *out);
>
> +typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
> GLXContext context,
> +
> mesa_glinterop_device_info *out);
> +typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
> GLXContext context,
> +const
> mesa_glinterop_export_in *in,
> +
> mesa_glinterop_export_out *out);
> +#endif /* MESA_EGL_NO_X11_HEADERS */
> +
> +/**
> + * Same as MesaGLInteropGLXQueryDeviceInfo except that it accepts EGLDisplay
> + * and EGLContext.
> + */
> +GLAPI int GLAPIENTRY
> +MesaGLInteropEGLQueryDeviceInfo(EGLDisplay dpy, EGLContext context,
> +mesa_glinterop_device_info *out);
>
> /**
> * Same as MesaGLInteropGLXExportObject except that it accepts
> @@ -268,18 +278,11 @@ MesaGLInteropEGLExportObject(EGLDisplay dpy, EGLContext
> context,
> const mesa_glinterop_export_in *in,
> mesa_glinterop_export_out *out);
>
> -
> -typedef int (APIENTRYP PFNMESAGLINTEROPGLXQUERYDEVICEINFOPROC)(Display *dpy,
> GLXContext context,
> -
> mesa_glinterop_device_info *out);
> typedef int (APIENTRYP PFNMESAGLINTEROPEGLQUERYDEVICEINFOPROC)(EGLDisplay
> dpy, EGLContext context,
>
> mesa_glinterop_device_info *out);
> -typedef int (APIENTRYP PFNMESAGLINTEROPGLXEXPORTOBJECTPROC)(Display *dpy,
> GLXContext context,
> -const
> mesa_glinterop_export_in *in,
> -
> mesa_glinterop_export_out *out);
> typedef int (APIENTRYP PFNMESAGLINTEROPEGLEXPORTOBJECTPROC)(EGLDisplay dpy,
> EGLContext context,
> const
> mesa_glinterop_export_in *in,
>
> mesa_glinterop_export_out *out);
> -
> #ifdef __cplusplus
> }
> #endif
> --
> 2.5.0
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/mesa: simplify st_generate_mipmap()
One typo below otherwise: Reviewed-by: Sinclair Yeh <s...@vmware.com>
On Sat, Mar 26, 2016 at 11:21:19AM -0600, Brian Paul wrote:
> The whole st_generate_mipmap() function was overly complicated. Now
> we just call the new _mesa_prepare_mipmap_levels() function to prepare
> the texture mipmap memory, then call the generate function which fills
> in the texture images.
>
> This fixes a failed assertion in llvmpipe/softpipe which is hit with the
> new piglit generatemipmap-base-change test. Also fixes some device errors
> (format mismatches) with the VMware svga driver.
> ---
> src/mesa/state_tracker/st_gen_mipmap.c | 102
> -
> 1 file changed, 24 insertions(+), 78 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_gen_mipmap.c
> b/src/mesa/state_tracker/st_gen_mipmap.c
> index c4b3492..d854e20 100644
> --- a/src/mesa/state_tracker/st_gen_mipmap.c
> +++ b/src/mesa/state_tracker/st_gen_mipmap.c
> @@ -82,7 +82,6 @@ st_generate_mipmap(struct gl_context *ctx, GLenum target,
> const uint baseLevel = texObj->BaseLevel;
> enum pipe_format format;
> uint lastLevel, first_layer, last_layer;
> - uint dstLevel;
>
> if (!pt)
>return;
> @@ -103,42 +102,33 @@ st_generate_mipmap(struct gl_context *ctx, GLenum
> target,
> stObj->lastLevel = lastLevel;
>
> if (!texObj->Immutable) {
> - if (pt->last_level < lastLevel) {
> - /* The current gallium texture doesn't have space for all the
> - * mipmap levels we need to generate. So allocate a new texture.
> - */
> - struct pipe_resource *oldTex = stObj->pt;
> -
> - /* create new texture with space for more levels */
> - stObj->pt = st_texture_create(st,
> - oldTex->target,
> - oldTex->format,
> - lastLevel,
> - oldTex->width0,
> - oldTex->height0,
> - oldTex->depth0,
> - oldTex->array_size,
> - 0,
> - oldTex->bind);
> -
> - /* This will copy the old texture's base image into the new texture
> - * which we just allocated.
> - */
> - st_finalize_texture(ctx, st->pipe, texObj);
> -
> - /* release the old tex (will likely be freed too) */
> - pipe_resource_reference(, NULL);
> - st_texture_release_all_sampler_views(st, stObj);
> - }
> - else {
> - /* Make sure that the base texture image data is present in the
> - * texture buffer.
> - */
> - st_finalize_texture(ctx, st->pipe, texObj);
> - }
> + const GLboolean genSave = texObj->GenerateMipmap;
> +
> + /* Temporarily set GenerateMipmap to true so that
> allocate_full_mipmap()
> + * makes the right decision about full mipmap allocation.
> + */
> + texObj->GenerateMipmap = GL_TRUE;
> +
> + _mesa_prepare_mipmap_levels(ctx, texObj, baseLevel, lastLevel);
> +
> + texObj->GenerateMipmap = genSave;
> +
> + /* At this point, memory for all the texture levels has been
> + * allocated. However, the base level image may be in one resource
> + * while the subsequent/smaller levels may be in another resource.
> + * Finalizing the texture will copy the base images from the former
> + * resource to the later.
latter.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Command buffer error in vmwgfx kernel module
Hi Loukas, To help me reproduce this 1. which application(s) was running? 2. what is the distro and kernel version? 3. can you send me your vmware.log? Can you file a bug on bugs.freedesktop.org? thanks, Sinclair On Tue, Jan 26, 2016 at 02:06:14AM +0200, Agorgianitis Loukas wrote: > When running OpenGL app in Linux VM with 3D acceleration enabled and > vmwgfx installed, > i get this kind of errors in dmesg: > > [xx.x] [drm:vmw_cmdbuf_work_func [cmwgfx]] *ERROR* Command buffer error. > > This causes some OpenGL apps to not run at all. System info: > VMWare Workstation Pro 12.1.0 > Bleeding edge Arch Linux installation. > Latest version of open-vm-tools. > Tested with both stable and git versions of mesa, mesa-libgl, vmwgfx > and libdrm. > > I am not a kernel dev, but i think this might be a vmwgfx module bug. > Any ideas? > > Regards, > Loukas > > P.S. Post containing some additional info: > https://bbs.archlinux.org/viewtopic.php?id=207784 > > -- > Agorgianitis Loukas > Software Engineer > Email:agorgl...@gmail.com > Team Email: scaryboxstud...@gmail.com > > ___ > 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 10/10] vbo: convert display list GL_LINE_LOOP prims to GL_LINE_STRIP
Acked-by: Sinclair Yeh <s...@vmware.com>
On Fri, Oct 16, 2015 at 03:25:17PM -0600, Brian Paul wrote:
> When a long GL_LINE_LOOP prim was split across primitives we drew
> stray lines. See previous commit for details.
>
> This patch converts GL_LINE_LOOP prims into GL_LINE_STRIP prims so
> that drivers don't have to worry about the _mesa_prim::begin/end flags.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
> ---
> src/mesa/vbo/vbo_save_api.c | 53
> +
> 1 file changed, 53 insertions(+)
>
> diff --git a/src/mesa/vbo/vbo_save_api.c b/src/mesa/vbo/vbo_save_api.c
> index 6688ba0..d49aa15 100644
> --- a/src/mesa/vbo/vbo_save_api.c
> +++ b/src/mesa/vbo/vbo_save_api.c
> @@ -360,6 +360,51 @@ merge_prims(struct _mesa_prim *prim_list,
> *prim_count = prev_prim - prim_list + 1;
> }
>
> +
> +/**
> + * Convert GL_LINE_LOOP primitive into GL_LINE_STRIP so that drivers
> + * don't have to worry about handling the _mesa_prim::begin/end flags.
> + * See https://bugs.freedesktop.org/show_bug.cgi?id=81174
> + */
> +static void
> +convert_line_loop_to_strip(struct vbo_save_context *save,
> + struct vbo_save_vertex_list *node)
> +{
> + struct _mesa_prim *prim = >prim[node->prim_count - 1];
> +
> + assert(prim->mode == GL_LINE_LOOP);
> +
> + if (prim->end) {
> + /* Copy the 0th vertex to end of the buffer and extend the
> + * vertex count by one to finish the line loop.
> + */
> + const GLuint sz = save->vertex_size;
> + /* 0th vertex: */
> + const fi_type *src = save->buffer + prim->start * sz;
> + /* end of buffer: */
> + fi_type *dst = save->buffer + (prim->start + prim->count) * sz;
> +
> + memcpy(dst, src, sz * sizeof(float));
> +
> + prim->count++;
> + node->count++;
> + save->vert_count++;
> + save->buffer_ptr += sz;
> + save->vertex_store->used += sz;
> + }
> +
> + if (!prim->begin) {
> + /* Drawing the second or later section of a long line loop.
> + * Skip the 0th vertex.
> + */
> + prim->start++;
> + prim->count--;
> + }
> +
> + prim->mode = GL_LINE_STRIP;
> +}
> +
> +
> /**
> * Insert the active immediate struct onto the display list currently
> * being built.
> @@ -441,6 +486,10 @@ _save_compile_vertex_list(struct gl_context *ctx)
> */
> save->copied.nr = _save_copy_vertices(ctx, node, save->buffer);
>
> + if (node->prim[node->prim_count - 1].mode == GL_LINE_LOOP) {
> + convert_line_loop_to_strip(save, node);
> + }
> +
> merge_prims(node->prim, >prim_count);
>
> /* Deal with GL_COMPILE_AND_EXECUTE:
> @@ -482,6 +531,10 @@ _save_compile_vertex_list(struct gl_context *ctx)
>save->buffer_ptr = vbo_save_map_vertex_store(ctx, save->vertex_store);
>save->out_of_memory = save->buffer_ptr == NULL;
> }
> + else {
> + /* update buffer_ptr for next vertex */
> + save->buffer_ptr = save->vertex_store->buffer +
> save->vertex_store->used;
> + }
>
> if (save->prim_store->used > VBO_SAVE_PRIM_SIZE - 6) {
>save->prim_store->refcount--;
> --
> 1.9.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] vbo: fix GL_LINE_LOOP stray line bug
On Fri, Oct 16, 2015 at 03:25:16PM -0600, Brian Paul wrote:
> When long GL_LINE_LOOP primitives don't fit in one vertex buffer they
> have to be split across buffers. The code to do this was basically correct
> but drivers had to pay special attention to the _mesa_prim::begin,end flags
> in order to draw the sections of the line loop properly. Apparently, the
> only drivers to do this were those using the old 'tnl' module for software
> vertex processing.
>
> Now we convert the split pieces of GL_LINE_LOOP prims into GL_LINE_STRIP
> primitives so that drivers don't have to worry about the special begin/end
> flags. The only time a driver will get a GL_LINE_LOOP prim is when the
> whole thing fits in one vertex buffer.
>
> Most fixes bug 81174, but not completely. There's another bug somewhere
> in the src/gallium/auxiliary/draw/ code. If the piglit lineloop test is
> run with -count 4096, rendering is correct, but with -count 4097 there are
> stray lines. 4096 is a magic number in the draw code (search for "4096").
>
> Also note that this does not fix long line loops in display lists. The
> next patch fixes that.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81174
> ---
> src/mesa/vbo/vbo_context.h | 5 -
> src/mesa/vbo/vbo_exec_api.c | 38 +-
> src/mesa/vbo/vbo_exec_draw.c | 12
> 3 files changed, 53 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/vbo/vbo_context.h b/src/mesa/vbo/vbo_context.h
> index 1e85335..28f43b4 100644
> --- a/src/mesa/vbo/vbo_context.h
> +++ b/src/mesa/vbo/vbo_context.h
> @@ -205,7 +205,10 @@ vbo_get_default_vals_as_union(GLenum format)
> static inline unsigned
> vbo_compute_max_verts(const struct vbo_exec_context *exec)
> {
> - return (VBO_VERT_BUFFER_SIZE - exec->vtx.buffer_used) /
> + /* Subtract one so we're always sure to have room for an extra
> +* vertex for GL_LINE_LOOP -> GL_LINE_STRIP conversion.
> +*/
> + return (VBO_VERT_BUFFER_SIZE - exec->vtx.buffer_used - 1) /
>(exec->vtx.vertex_size * sizeof(GLfloat));
We may need to check for a negaive result here just in case
buffer_used is very close or equal to VBO_VERT_BUFFER_SIZE.
> }
>
> diff --git a/src/mesa/vbo/vbo_exec_api.c b/src/mesa/vbo/vbo_exec_api.c
> index 0116f56..3c25ec0 100644
> --- a/src/mesa/vbo/vbo_exec_api.c
> +++ b/src/mesa/vbo/vbo_exec_api.c
> @@ -61,7 +61,8 @@ static void reset_attrfv( struct vbo_exec_context *exec );
>
> /**
> * Close off the last primitive, execute the buffer, restart the
> - * primitive.
> + * primitive. This is called when we fill a vertex buffer before
> + * hitting glEnd.
> */
> static void vbo_exec_wrap_buffers( struct vbo_exec_context *exec )
> {
> @@ -83,6 +84,22 @@ static void vbo_exec_wrap_buffers( struct vbo_exec_context
> *exec )
>
>last_count = last_prim->count;
>
> + /* Special handling for wrapping GL_LINE_LOOP */
> + if (last_prim->mode == GL_LINE_LOOP &&
> + last_count > 0 &&
> + !last_prim->end) {
> + /* draw this section of the incomplete line loop as a line strip */
> + last_prim->mode = GL_LINE_STRIP;
> + if (!last_prim->begin) {
> +/* This is not the first section of the line loop, so don't
> + * draw the 0th vertex. We're saving it until we draw the
> + * very last section of the loop.
> + */
I don't understand some of the prim fields, so I'm assuming "start" is
an index into the VBO, i.e. [0 ... start ... n] where 'n' is index to
the last vertex.
With that assumption, if we do the below, then don't we miss the
[start -> start + 1] strip?
> +last_prim->start++;
> +last_prim->count--;
> + }
> + }
> +
>/* Execute the buffer and save copied vertices.
> */
>if (exec->vtx.vert_count)
> @@ -98,6 +115,7 @@ static void vbo_exec_wrap_buffers( struct vbo_exec_context
> *exec )
>
>if (_mesa_inside_begin_end(exec->ctx)) {
>exec->vtx.prim[0].mode = exec->ctx->Driver.CurrentExecPrimitive;
> + exec->vtx.prim[0].begin = 0;
>exec->vtx.prim[0].start = 0;
>exec->vtx.prim[0].count = 0;
>exec->vtx.prim_count++;
> @@ -827,6 +845,24 @@ static void GLAPIENTRY vbo_exec_End( void )
>last_prim->end = 1;
>last_prim->count = exec->vtx.vert_count - last_prim->start;
>
> + /* Special handling for GL_LINE_LOOP */
> + if (last_prim->mode == GL_LINE_LOOP && last_prim->begin == 0) {
> + /* We're finishing drawing a line loop. Append 0th vertex onto
> + * end of vertex buffer so we can draw it as a line strip.
> + */
> + const fi_type *src = exec->vtx.buffer_map;
> + fi_type *dst = exec->vtx.buffer_map +
> +exec->vtx.vert_count * exec->vtx.vertex_size;
> +
> + /* copy 0th vertex to end of buffer */
> + memcpy(dst, src, exec->vtx.vertex_size *
Re: [Mesa-dev] [PATCH 01/10] tnl: add some comments in render_line_loop code
Patches 1-8 look good. I'm spending a bit more time on 10.
Reviewed-by: Sinclair Yeh <s...@vmware.com>
From: Brian Paul <bri...@vmware.com>
Sent: Friday, October 16, 2015 2:25 PM
To: mesa-dev@lists.freedesktop.org
Cc: Charmaine Lee; Jose Fonseca; Sinclair Yeh
Subject: [PATCH 01/10] tnl: add some comments in render_line_loop code
And remove '(void) flags' line which is not needed.
---
src/mesa/tnl/t_vb_rendertmp.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/mesa/tnl/t_vb_rendertmp.h b/src/mesa/tnl/t_vb_rendertmp.h
index 44dee76..26a1695 100644
--- a/src/mesa/tnl/t_vb_rendertmp.h
+++ b/src/mesa/tnl/t_vb_rendertmp.h
@@ -124,19 +124,19 @@ static void TAG(render_line_loop)( struct gl_context *ctx,
GLuint i;
LOCAL_VARS;
- (void) flags;
-
INIT(GL_LINE_LOOP);
if (start+1 < count) {
if (TEST_PRIM_BEGIN(flags)) {
RESET_STIPPLE;
+ /* draw the first line from v[0] to v[1] */
if (ctx->Light.ProvokingVertex == GL_LAST_VERTEX_CONVENTION_EXT)
RENDER_LINE( ELT(start), ELT(start+1) );
else
RENDER_LINE( ELT(start+1), ELT(start) );
}
+ /* draw lines from v[1] to V[n-1] */
for ( i = start+2 ; i < count ; i++) {
if (ctx->Light.ProvokingVertex == GL_LAST_VERTEX_CONVENTION_EXT)
RENDER_LINE( ELT(i-1), ELT(i) );
@@ -145,6 +145,7 @@ static void TAG(render_line_loop)( struct gl_context *ctx,
}
if ( TEST_PRIM_END(flags)) {
+ /* draw final line from v[n-1] to v[0] (the very first vertex) */
if (ctx->Light.ProvokingVertex == GL_LAST_VERTEX_CONVENTION_EXT)
RENDER_LINE( ELT(count-1), ELT(start) );
else
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] mesa: make memcpy_texture() non-static
Reviewed-by: Sinclair Yeh <s...@vmware.com>
On Thu, Oct 15, 2015 at 01:01:42PM -0600, Brian Paul wrote:
> So that we can use it directly from the mesa/gallium state tracker.
> ---
> src/mesa/main/texstore.c | 40
> src/mesa/main/texstore.h | 11 +++
> 2 files changed, 31 insertions(+), 20 deletions(-)
>
> diff --git a/src/mesa/main/texstore.c b/src/mesa/main/texstore.c
> index e50964e..4b13c42 100644
> --- a/src/mesa/main/texstore.c
> +++ b/src/mesa/main/texstore.c
> @@ -97,16 +97,16 @@ static const GLubyte map_1032[6] = { 1, 0, 3, 2, ZERO,
> ONE };
> * No pixel transfer operations or special texel encodings allowed.
> * 1D, 2D and 3D images supported.
> */
> -static void
> -memcpy_texture(struct gl_context *ctx,
> -GLuint dimensions,
> - mesa_format dstFormat,
> - GLint dstRowStride,
> - GLubyte **dstSlices,
> - GLint srcWidth, GLint srcHeight, GLint srcDepth,
> - GLenum srcFormat, GLenum srcType,
> - const GLvoid *srcAddr,
> - const struct gl_pixelstore_attrib *srcPacking)
> +void
> +_mesa_memcpy_texture(struct gl_context *ctx,
> + GLuint dimensions,
> + mesa_format dstFormat,
> + GLint dstRowStride,
> + GLubyte **dstSlices,
> + GLint srcWidth, GLint srcHeight, GLint srcDepth,
> + GLenum srcFormat, GLenum srcType,
> + const GLvoid *srcAddr,
> + const struct gl_pixelstore_attrib *srcPacking)
> {
> const GLint srcRowStride = _mesa_image_row_stride(srcPacking, srcWidth,
> srcFormat, srcType);
> @@ -296,11 +296,11 @@ _mesa_texstore_ycbcr(TEXSTORE_PARAMS)
> assert(baseInternalFormat == GL_YCBCR_MESA);
>
> /* always just memcpy since no pixel transfer ops apply */
> - memcpy_texture(ctx, dims,
> - dstFormat,
> - dstRowStride, dstSlices,
> - srcWidth, srcHeight, srcDepth, srcFormat, srcType,
> - srcAddr, srcPacking);
> + _mesa_memcpy_texture(ctx, dims,
> +dstFormat,
> +dstRowStride, dstSlices,
> +srcWidth, srcHeight, srcDepth, srcFormat, srcType,
> +srcAddr, srcPacking);
>
> /* Check if we need byte swapping */
> /* XXX the logic here _might_ be wrong */
> @@ -899,11 +899,11 @@ _mesa_texstore_memcpy(TEXSTORE_PARAMS)
>return GL_FALSE;
> }
>
> - memcpy_texture(ctx, dims,
> - dstFormat,
> - dstRowStride, dstSlices,
> - srcWidth, srcHeight, srcDepth, srcFormat, srcType,
> - srcAddr, srcPacking);
> + _mesa_memcpy_texture(ctx, dims,
> +dstFormat,
> +dstRowStride, dstSlices,
> +srcWidth, srcHeight, srcDepth, srcFormat, srcType,
> +srcAddr, srcPacking);
> return GL_TRUE;
> }
> /**
> diff --git a/src/mesa/main/texstore.h b/src/mesa/main/texstore.h
> index 2c974f7..f08dc08 100644
> --- a/src/mesa/main/texstore.h
> +++ b/src/mesa/main/texstore.h
> @@ -74,6 +74,17 @@ _mesa_texstore_needs_transfer_ops(struct gl_context *ctx,
>GLenum baseInternalFormat,
>mesa_format dstFormat);
>
> +extern void
> +_mesa_memcpy_texture(struct gl_context *ctx,
> + GLuint dimensions,
> + mesa_format dstFormat,
> + GLint dstRowStride,
> + GLubyte **dstSlices,
> + GLint srcWidth, GLint srcHeight, GLint srcDepth,
> + GLenum srcFormat, GLenum srcType,
> + const GLvoid *srcAddr,
> + const struct gl_pixelstore_attrib *srcPacking);
> +
> extern GLboolean
> _mesa_texstore_can_use_memcpy(struct gl_context *ctx,
>GLenum baseInternalFormat, mesa_format
> dstFormat,
> --
> 1.9.1
>
> ___
> 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 1/4] st/mesa: use MAX3() instead of MAX2(MAX2) in draw_textured_quad()
1 and 3 look good to me.
On Thu, Oct 15, 2015 at 01:01:40PM -0600, Brian Paul wrote:
> ---
> src/mesa/state_tracker/st_cb_drawpixels.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/state_tracker/st_cb_drawpixels.c
> b/src/mesa/state_tracker/st_cb_drawpixels.c
> index 7e8633e..e4d3580 100644
> --- a/src/mesa/state_tracker/st_cb_drawpixels.c
> +++ b/src/mesa/state_tracker/st_cb_drawpixels.c
> @@ -667,7 +667,8 @@ draw_textured_quad(struct gl_context *ctx, GLint x, GLint
> y, GLfloat z,
> /* user textures, plus the drawpix textures */
> if (fpv) {
>struct pipe_sampler_view *sampler_views[PIPE_MAX_SAMPLERS];
> - uint num = MAX2(MAX2(fpv->drawpix_sampler, fpv->pixelmap_sampler) + 1,
> + uint num = MAX3(fpv->drawpix_sampler + 1,
> + fpv->pixelmap_sampler + 1,
>st->state.num_sampler_views[PIPE_SHADER_FRAGMENT]);
>
>memcpy(sampler_views, st->state.sampler_views[PIPE_SHADER_FRAGMENT],
> --
> 1.9.1
>
> ___
> 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 06/10] vbo: simplify some code in vbo_exec_debug_verts()
On Fri, Oct 16, 2015 at 03:25:13PM -0600, Brian Paul wrote:
> As before, use a new 'last_prim' pointer to simplify things. Plus, add
> some const qualifiers.
> ---
> src/mesa/vbo/vbo_exec_draw.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/src/mesa/vbo/vbo_exec_draw.c b/src/mesa/vbo/vbo_exec_draw.c
> index 781991b..412ebb6 100644
> --- a/src/mesa/vbo/vbo_exec_draw.c
> +++ b/src/mesa/vbo/vbo_exec_draw.c
> @@ -75,13 +75,13 @@ vbo_exec_debug_verts( struct vbo_exec_context *exec )
> static GLuint
> vbo_copy_vertices( struct vbo_exec_context *exec )
> {
> - GLuint nr = exec->vtx.prim[exec->vtx.prim_count-1].count;
> + struct _mesa_prim *last_prim = >vtx.prim[exec->vtx.prim_count - 1];
> + const GLuint nr = last_prim->count;
> GLuint ovf, i;
> - GLuint sz = exec->vtx.vertex_size;
> + const GLuint sz = exec->vtx.vertex_size;
> fi_type *dst = exec->vtx.copied.buffer;
> - const fi_type *src = (exec->vtx.buffer_map +
> - exec->vtx.prim[exec->vtx.prim_count-1].start *
> - exec->vtx.vertex_size);
> + const fi_type *src =
> + exec->vtx.buffer_map + last_prim->start * exec->vtx.vertex_size;
Can use "sz" here ^
Otherwise, looks good to me.
>
> switch (exec->ctx->Driver.CurrentExecPrimitive) {
> case GL_POINTS:
> @@ -127,7 +127,7 @@ vbo_copy_vertices( struct vbo_exec_context *exec )
> case GL_TRIANGLE_STRIP:
>/* no parity issue, but need to make sure the tri is not drawn twice */
>if (nr & 1) {
> - exec->vtx.prim[exec->vtx.prim_count-1].count--;
> + last_prim->count--;
>}
>/* fallthrough */
> case GL_QUAD_STRIP:
> --
> 1.9.1
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: add missing padding to SVGA3dSize
On Fri, Feb 20, 2015 at 09:22:20AM +, Van Der Wath, DanielX J wrote:
From: Daniel van der Wath danielx.j.van.der.w...@intel.com
The kernel side equivalent of struct SVGA3dSize (struct drm_vmw_size) has an
extra padding word that SVGA3dSize lacks. This was causing data to be written
past the end of size in vmw_drm_surface_from_handle(), corrupting other data
The drm_vmw_* types are used to exchange data with the VMW DRM so none of the
DRM IOCTL functions, e.g. drmCommandWriteRead(), should be using the SVGA3d*
types.
In vmw_drm_surface_from_handle(), size is of type struct drm_vmw_size,
and is being used here: rep-size_addr = (unsigned long)size, to call
drmCommandWriteRead(). So there shouldn't be a user/kernel mismatch here.
At which point during this function do you see handle being over written?
Also, which version of MESA are you seeing this on?
I'll see if I can see this on my end.
and in this case leading to Weston being unable to render anything on screen.
---
src/gallium/drivers/svga/include/svga3d_types.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/drivers/svga/include/svga3d_types.h
b/src/gallium/drivers/svga/include/svga3d_types.h
index fc4a6b9..3ce6814 100644
--- a/src/gallium/drivers/svga/include/svga3d_types.h
+++ b/src/gallium/drivers/svga/include/svga3d_types.h
@@ -1280,6 +1280,7 @@ struct {
uint32 width;
uint32 height;
uint32 depth;
+ uint32 pad64;
}
#include vmware_pack_end.h
SVGA3dSize;
--
1.7.11.7
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] svga: fix sid corruption in vmw_drm_surface_from_handle()
On Tue, Feb 03, 2015 at 03:16:51PM +, danielx.j.van.der.w...@intel.com wrote: From: Daniel van der Wath danielx.j.van.der.w...@intel.com The value stored in handle is trashed before being copied into the surface's sid. Use the original value from whandle-handle instead. This fixes a bug with Weston running on VMWare, where SVGA3D_SetRenderTarget() would fail and prevent anything from being drawn on screen. Reviewed-by: Satyeshwar Singh satyeshwar.si...@intel.com --- src/gallium/winsys/svga/drm/vmw_screen_dri.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/winsys/svga/drm/vmw_screen_dri.c b/src/gallium/winsys/svga/drm/vmw_screen_dri.c index 79a1b3e..0f796c4 100644 --- a/src/gallium/winsys/svga/drm/vmw_screen_dri.c +++ b/src/gallium/winsys/svga/drm/vmw_screen_dri.c @@ -319,7 +319,7 @@ vmw_drm_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 = handle; +vsrf-sid = whandle-handle; This doesn't look right because the patch will allow referencing a surface that has been destroyed. The problem is probably from an unnecessary call to vmw_ioctl_surface_destroy() earlier in the function. Instead of the current patch, can you try adding a check for if (vws-ioctl.have_drm_2_6) at line 262 covering the entire DRM_API_HANDLE_TYPE_FD case, and also at line 286 for the existing IF condition? If you like, you can take a look at commit 2f6fcd65 for ideas. Please give it a try and let me know. Thanks! Sinclair ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: fix spurious wglGetProcAddress / GL_INVALID_OPERATION error
This looks reasonable to me.
Acked-by: Sinclair Yeh s...@vmware.com
On Thu, Oct 02, 2014 at 09:49:04AM -0600, Brian Paul wrote:
On Windows, the Piglit primitive-restart test was failing a
glGetError()==0 assertion when it was run w/out any command line
arguments. Piglit's all.py script only runs primitive-restart
with arguments so this case isn't normally hit during a full
piglit run.
The basic problem is Microsoft's opengl32.dll calls glFlush
from wglGetProcAddress() and Piglit uses wglGetProcAddress() to
resolve glPrimitiveRestartNV() which is called inside glBegin/End.
See comments in the code for more info.
Plus, improve the comments for _mesa_alloc_dispatch_table().
Cc: mesa-sta...@lists.freedesktop.org
---
src/mesa/main/context.c | 36 +++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/context.c b/src/mesa/main/context.c
index afe43a6..5a8f718 100644
--- a/src/mesa/main/context.c
+++ b/src/mesa/main/context.c
@@ -891,7 +891,21 @@ _mesa_generic_nop(void)
/**
- * Allocate and initialize a new dispatch table.
+ * Special no-op glFlush, see below.
+ */
+#if defined(_WIN32)
+static void GLAPIENTRY
+nop_glFlush(void)
+{
+ /* don't record an error like we do in _mesa_generic_nop() */
+}
+#endif
+
+
+/**
+ * Allocate and initialize a new dispatch table. All the dispatch
+ * function pointers will point at the _mesa_generic_nop() function
+ * which raises GL_INVALID_OPERATION.
*/
struct _glapi_table *
_mesa_alloc_dispatch_table(void)
@@ -911,6 +925,26 @@ _mesa_alloc_dispatch_table(void)
for (i = 0; i numEntries; i++) {
entry[i] = (_glapi_proc) _mesa_generic_nop;
}
+
+#if defined(_WIN32)
+ /* This is a special case for Windows in the event that
+ * wglGetProcAddress is called between glBegin/End().
+ *
+ * The MS opengl32.dll library apparently calls glFlush from
+ * wglGetProcAddress(). If we're inside glBegin/End(), glFlush
+ * will dispatch to _mesa_generic_nop() and we'll generate a
+ * GL_INVALID_OPERATION error.
+ *
+ * The specific case which hits this is piglit's primitive-restart
+ * test which calls glPrimitiveRestartNV() inside glBegin/End. The
+ * first time we call glPrimitiveRestartNV() Piglit's API dispatch
+ * code will try to resolve the function by calling wglGetProcAddress.
+ * This raises GL_INVALID_OPERATION and an assert(glGetError()==0)
+ * will fail causing the test to fail. By suppressing the error, the
+ * assertion passes and the test continues.
+ */
+ SET_Flush(table, nop_glFlush);
+#endif
}
return table;
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-devk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=0z9ea8IzZ%2F3am%2F968VnzsA%3D%3D%0Am=uR%2BbgxEgKLtR41FFJnfOhIvQxuyZU7uaD5Fwrr7QHRI%3D%0As=1a422441a95eef77350f89c98b2e593f7aa29a93e9e5fe473ba769f814e12255
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/xa: Fix regression in xa_yuv_planar_blit()
Looks good.
Reviewed-by: Sinclair Yeh s...@vmware.com
On Mon, Sep 29, 2014 at 08:13:46AM +0200, Thomas Hellstrom wrote:
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 thellst...@vmware.com
Cc: Rob Clark robcl...@freedesktop.org
Cc: 10.2 10.3 mesa-sta...@lists.freedesktop.org
---
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
[Mesa-dev] [PATCH] Check for NULL native_window into eglCreateWindowSurface()
v2: Incorporated feedback from idr - moved the check to a higher level function. v1: We have customers using NULL as a way to test the robustness of the API. Without this check, EGL will segfault trying to dereference dri2_surf-wl_win-private because wl_win is NULL. This fix adds a check and sets EGL_BAD_NATIVE_WINDOW Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org --- src/egl/main/eglapi.c | 4 1 file changed, 4 insertions(+) diff --git a/src/egl/main/eglapi.c b/src/egl/main/eglapi.c index 7846814..096c3d8 100644 --- a/src/egl/main/eglapi.c +++ b/src/egl/main/eglapi.c @@ -571,6 +571,10 @@ _eglCreateWindowSurfaceCommon(_EGLDisplay *disp, EGLConfig config, EGLSurface ret; _EGL_CHECK_CONFIG(disp, conf, EGL_NO_SURFACE, drv); + + if (native_window == NULL) + RETURN_EGL_ERROR(disp, EGL_BAD_NATIVE_WINDOW, EGL_NO_SURFACE); + surf = drv-API.CreateWindowSurface(drv, disp, conf, native_window, attrib_list); ret = (surf) ? _eglLinkSurface(surf) : EGL_NO_SURFACE; -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Check for NULL native_window into dri2_wl_create_surface
We have customers using NULL as a way to test the robustness of
the API. Without this check, EGL will segfault trying to
dereference dri2_surf-wl_win-private because wl_win is
NULL.
This fix adds a check and sets EGL_BAD_NATIVE_WINDOW
---
src/egl/drivers/dri2/platform_wayland.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/src/egl/drivers/dri2/platform_wayland.c
b/src/egl/drivers/dri2/platform_wayland.c
index 537d26e..66f51e9 100644
--- a/src/egl/drivers/dri2/platform_wayland.c
+++ b/src/egl/drivers/dri2/platform_wayland.c
@@ -130,6 +130,13 @@ dri2_wl_create_surface(_EGLDriver *drv, _EGLDisplay *disp,
EGLint type,
(void) drv;
+ if (NULL == window)
+ {
+ _eglError(EGL_BAD_NATIVE_WINDOW, dri2_create_surface);
+ return NULL;
+ }
+
+
dri2_surf = malloc(sizeof *dri2_surf);
if (!dri2_surf) {
_eglError(EGL_BAD_ALLOC, dri2_create_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 1/6] dri2: Create image from texture
On Fri, Dec 14, 2012 at 03:28:13PM +0200, Abdiel Janulgue wrote:
Add create image from texture extension.
Signed-off-by: Abdiel Janulgue abdiel.janul...@linux.intel.com
---
include/GL/internal/dri_interface.h | 12 +
src/egl/drivers/dri2/egl_dri2.c | 83
+++
2 files changed, 95 insertions(+)
diff --git a/include/GL/internal/dri_interface.h
b/include/GL/internal/dri_interface.h
index 1e0f1d0..a711cbf 100644
--- a/include/GL/internal/dri_interface.h
+++ b/include/GL/internal/dri_interface.h
@@ -1061,6 +1061,18 @@ struct __DRIimageExtensionRec {
*/
__DRIimage *(*fromPlanar)(__DRIimage *image, int plane,
void *loaderPrivate);
+
+/**
+ * Create image from texture.
+ *
+ * \since 5
+ */
+ __DRIimage *(*createImageFromTexture)(__DRIcontext *context,
+ int target,
+ unsigned texture,
+ int level,
+ int depth,
+ void *loaderPrivate);
};
The order of level and depth is flipped when compared with actual
usage.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
