Re: [Mesa-dev] Mesa (master): build systems: uniformize git_sha1.h generation
On 1 July 2017 00:18:31 BST, Brian Paul wrote:
> Hi Eric,
>
> Shouldn't the new script file be put in the bin/ directory with the
> other helper scripts?
I guess you're right, not sure why I didn't do that.
Feel free to move it (just make sure to ../ the --git-dir too), or I can
do that when I get back in front of a computer next week.
Should we also merge bin/ and scripts/, maybe?
I think get_reviewers.pl would stay in scripts/ because that path
is in everyone's configuration, but I think everything in bin/ is
manually invoked, right?
Cheers,
Eric
>
> On 06/29/2017 09:52 AM, Eric Engeström wrote:
> > Module: Mesa
> > Branch: master
> > Commit: 3fd425aed764fb771f2f49ddb6b30b389a114504
> > URL:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__cgit.freedesktop.org_mesa_mesa_commit_-3Fid-3D3fd425aed764fb771f2f49ddb6b30b389a114504&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=C2QHFlT8FYNq-A29CoLU1hnnK3jQhP0A-EpQrqbU_GQ&s=ZjxcahOcytLNOgFBZuod2dWN2xvP8Ph32iP3dluOunQ&e=
> >
> > Author: Eric Engestrom
> > Date: Tue Jun 27 12:08:41 2017 +0100
> >
> > build systems: uniformize git_sha1.h generation
> >
> > Signed-off-by: Eric Engestrom
> > Reviewed-by: Matt Turner
> > Reviewed-by: Emil Velikov
> >
> > ---
> >
> > git_sha1_gen.sh | 12
> > src/Makefile.am | 13 +
> > src/SConscript | 28
>
> > src/mesa/Android.libmesa_git_sha1.mk | 7 +--
> > 4 files changed, 22 insertions(+), 38 deletions(-)
> >
> > diff --git a/git_sha1_gen.sh b/git_sha1_gen.sh
> > new file mode 100755
> > index 00..20ab8df8ea
> > --- /dev/null
> > +++ b/git_sha1_gen.sh
> > @@ -0,0 +1,12 @@
> > +#!/bin/sh
> > +
> > +# run git from the sources directory
> > +cd "$(dirname "$0")"
> > +
> > +# don't print anything if git fails
> > +if ! git_sha1=$(git --git-dir=.git rev-parse --short=10 HEAD
> 2>/dev/null)
> > +then
> > + exit
> > +fi
> > +
> > +printf '#define MESA_GIT_SHA1 "git-%s"\n' "$git_sha1"
> > diff --git a/src/Makefile.am b/src/Makefile.am
> > index df912c442a..d8a2ee59fc 100644
> > --- a/src/Makefile.am
> > +++ b/src/Makefile.am
> > @@ -21,18 +21,7 @@
> >
> > .PHONY: git_sha1.h.tmp
> > git_sha1.h.tmp:
> > - @# Don't assume that $(top_srcdir)/.git is a directory. It may be
> > - @# a gitlink file if $(top_srcdir) is a submodule checkout or a
> linked
> > - @# worktree.
> > - @# If we are building from a release tarball copy the bundled
> header.
> > - @touch git_sha1.h.tmp
> > - @if test -e $(top_srcdir)/.git; then \
> > - if which git > /dev/null; then \
> > - printf '#define MESA_GIT_SHA1 "git-%s"\n' \
> > - `git --git-dir=$(top_srcdir)/.git rev-parse --short=10
> > HEAD` \
> > - > git_sha1.h.tmp ; \
> > - fi \
> > - fi
> > + @sh $(top_srcdir)/git_sha1_gen.sh > $@
> >
> > git_sha1.h: git_sha1.h.tmp
> > @echo "updating git_sha1.h"
> > diff --git a/src/SConscript b/src/SConscript
> > index d861af8e4d..5e1171b524 100644
> > --- a/src/SConscript
> > +++ b/src/SConscript
> > @@ -22,27 +22,15 @@ def write_git_sha1_h_file(filename):
> > to retrieve the git hashid and write the header file. An
> empty file
> > will be created if anything goes wrong."""
> >
> > -args = [ 'git', 'rev-parse', '--short=10', 'HEAD' ]
> > -try:
> > -(commit, foo) = subprocess.Popen(args,
> stdout=subprocess.PIPE).communicate()
> > -except:
> > -print "Warning: exception in write_git_sha1_h_file()"
> > -# git log command didn't work
> > -if not os.path.exists(filename):
> > -dirname = os.path.dirname(filename)
> > -if dirname and not os.path.exists(dirname):
> > -os.makedirs(dirname)
> > -# create an empty file if none already exists
> > -f = open(filename, "w")
> > -f.close()
> > -return
> > -
> > -# note that commit[:-1] removes the trailing newline character
> > -commit = '#define MESA_GIT_SHA1 "git-%s"\n' % commit[:-1]
> > tempfile = "git_sha1.h.tmp"
> > -f = open(tempfile, "w")
> > -f.write(commit)
> > -f.close()
> > +with open(tempfile, "w") as f:
> > +args = [ 'sh', Dir('#').abspath + '/git_sha1_gen.sh' ]
> > +try:
> > +subprocess.Popen(args, stdout=f)
> > +except:
> > +print "Warning: exception in write_git_sha1_h_file()"
> > +return
> > +
> > if not os.path.exists(filename) or not filecmp.cmp(tempfile,
> filename):
> > # The filename does not exist or it's different from the
> new file,
> > # so replace old file with new.
> > diff --git a/src/mesa/Android.libmesa_git_sha1.mk
> b/src/mesa/Android.libmesa_git_sha1.mk
> > index 0fd176bf7d..a5a1ebb37f 100644
> > --- a/src/mesa/Android.libmesa_git_sha1.mk
> > +++ b/src/mes
[Mesa-dev] [PATCH] i965: Remove clearing of bo->map_gtt after failure
With the conversion to storing the result of drm_mmap to a local and not
directly to bo->map_gtt itself, we no longer should clear bo->map_gtt.
In the best the operation is redundant as we know bo->map_gtt to already
be NULL, but in the worst case we overwrite a concurrent thread that
successfully mmaped the GTT.
Fixes: 314647c4c206 ("i965: Drop global bufmgr lock from brw_bo_map_*
functions.")
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
Cc: Matt Turner
---
src/mesa/drivers/dri/i965/brw_bufmgr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
b/src/mesa/drivers/dri/i965/brw_bufmgr.c
index 8ed6ba5f41..d05885cfaf 100644
--- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
+++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
@@ -747,7 +747,6 @@ brw_bo_map_gtt(struct brw_context *brw, struct brw_bo *bo,
unsigned flags)
map = drm_mmap(0, bo->size, PROT_READ | PROT_WRITE,
MAP_SHARED, bufmgr->fd, mmap_arg.offset);
if (map == MAP_FAILED) {
- bo->map_gtt = NULL;
DBG("%s:%d: Error mapping buffer %d (%s): %s .\n",
__FILE__, __LINE__, bo->gem_handle, bo->name, strerror(errno));
return NULL;
--
2.13.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/24] st/mesa: unify update_gp/tcp/tep code
Hello Marek,
this patch makes most of the tesselation shaders in piglit crash
because now you are passing MESA_SHADER_TESS_* to st_get_basic_variant,
but this function tests for PIPE_SHADER_TESS_* when allocating new
variants. Hence, the function doesn't fulfill the assert in debug
mode, or it returns a null pointer in release.
Replacing MESA_SHADER_TESS_* with PIPE_SHADER_TESS_* fixes the problem
for me.
Best,
Gert
Am Montag, den 12.06.2017, 20:18 +0200 schrieb Marek Olšák:
> From: Marek Olšák
>
> ---
> src/mesa/state_tracker/st_atom_shader.c | 91 ++-
> --
> 1 file changed, 28 insertions(+), 63 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_atom_shader.c
> b/src/mesa/state_tracker/st_atom_shader.c
> index b6b3222..c1869d3 100644
> --- a/src/mesa/state_tracker/st_atom_shader.c
> +++ b/src/mesa/state_tracker/st_atom_shader.c
> @@ -189,103 +189,68 @@ st_update_vp( struct st_context *st )
> st->vp_variant = st_get_vp_variant(st, stvp, &key);
> }
>
> st_reference_vertprog(st, &st->vp, stvp);
>
> cso_set_vertex_shader_handle(st->cso_context,
> st->vp_variant->driver_shader);
> }
>
>
> -void
> -st_update_gp( struct st_context *st )
> +static void *
> +st_update_common_program(struct st_context *st, struct gl_program
> *prog,
> + unsigned pipe_shader, struct
> st_common_program **dst)
> {
> - struct st_common_program *stgp;
> + struct st_common_program *stp;
>
> - if (!st->ctx->GeometryProgram._Current) {
> - cso_set_geometry_shader_handle(st->cso_context, NULL);
> - st_reference_prog(st, &st->gp, NULL);
> - return;
> + if (!prog) {
> + st_reference_prog(st, dst, NULL);
> + return NULL;
> }
>
> - stgp = st_common_program(st->ctx->GeometryProgram._Current);
> - assert(stgp->Base.Target == GL_GEOMETRY_PROGRAM_NV);
> + stp = st_common_program(prog);
> + st_reference_prog(st, dst, stp);
>
> - void *shader;
> + if (st-
> >shader_has_one_variant[prog->info.stage] && stp->variants)
> + return stp->variants->driver_shader;
>
> - if (st->shader_has_one_variant[MESA_SHADER_GEOMETRY] && stgp-
> >variants) {
> - shader = stgp->variants->driver_shader;
> - } else {
> - shader = st_get_basic_variant(st, PIPE_SHADER_GEOMETRY, &stgp-
> >tgsi,
> -&stgp->variants)->driver_shader;
> - }
> + return st_get_basic_variant(st, pipe_shader, &stp->tgsi,
> + &stp->variants)->driver_shader;
> +}
>
> - st_reference_prog(st, &st->gp, stgp);
>
> +void
> +st_update_gp(struct st_context *st)
> +{
> + void *shader = st_update_common_program(st,
> + st->ctx-
> >GeometryProgram._Current,
> + PIPE_SHADER_GEOMETRY,
> &st->gp);
> cso_set_geometry_shader_handle(st->cso_context, shader);
> }
>
>
> void
> -st_update_tcp( struct st_context *st )
> +st_update_tcp(struct st_context *st)
> {
> - struct st_common_program *sttcp;
> -
> - if (!st->ctx->TessCtrlProgram._Current) {
> - cso_set_tessctrl_shader_handle(st->cso_context, NULL);
> - st_reference_prog(st, &st->tcp, NULL);
> - return;
> - }
> -
> - sttcp = st_common_program(st->ctx->TessCtrlProgram._Current);
> - assert(sttcp->Base.Target == GL_TESS_CONTROL_PROGRAM_NV);
> -
> - void *shader;
> -
> - if (st->shader_has_one_variant[MESA_SHADER_TESS_CTRL] && sttcp-
> >variants) {
> - shader = sttcp->variants->driver_shader;
> - } else {
> - shader = st_get_basic_variant(st, PIPE_SHADER_TESS_CTRL,
> &sttcp->tgsi,
> -&sttcp->variants)-
> >driver_shader;
> - }
> -
> - st_reference_prog(st, &st->tcp, sttcp);
> -
> + void *shader = st_update_common_program(st,
> + st->ctx-
> >TessCtrlProgram._Current,
> + MESA_SHADER_TESS_CTRL,
> &st->tcp);
> cso_set_tessctrl_shader_handle(st->cso_context, shader);
> }
>
>
> void
> -st_update_tep( struct st_context *st )
> +st_update_tep(struct st_context *st)
> {
> - struct st_common_program *sttep;
> -
> - if (!st->ctx->TessEvalProgram._Current) {
> - cso_set_tesseval_shader_handle(st->cso_context, NULL);
> - st_reference_prog(st, &st->tep, NULL);
> - return;
> - }
> -
> - sttep = st_common_program(st->ctx->TessEvalProgram._Current);
> - assert(sttep->Base.Target == GL_TESS_EVALUATION_PROGRAM_NV);
> -
> - void *shader;
> -
> - if (st->shader_has_one_variant[MESA_SHADER_TESS_EVAL] && sttep-
> >variants) {
> - shader = sttep->variants->driver_shader;
> - } else {
> - shader = st_get_basic_variant(st, PIPE_SHADER_TESS_EVAL,
> &sttep->tgsi,
> -&sttep->variants)-
> >driver_shader;
> - }
> -
> - st_reference_prog(st, &st->tep, sttep);
> -
> +
Re: [Mesa-dev] [PATCH 2/2] st/mesa: fix texture image resource selection in st_render_texture()
On 29.06.2017 00:12, Brian Paul wrote:
If we're rendering to an incomplete/inconsistent (cube) texture, the
different faces/levels of the texture may be stored in different
resources. Before, we always used the texture object resource. Now,
we use the texture image resource. In normal circumstances, that's
the same resource. But in some cases, such as the Piglit
fbo-incomplete-texture-03 test, the cube faces are in different
resources and we need to render to the texture image resource.
Fixes fbo-incomplete-texture-03 with VMware driver.
---
src/mesa/state_tracker/st_cb_fbo.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/mesa/state_tracker/st_cb_fbo.c
b/src/mesa/state_tracker/st_cb_fbo.c
index 2559c23..a4d710c 100644
--- a/src/mesa/state_tracker/st_cb_fbo.c
+++ b/src/mesa/state_tracker/st_cb_fbo.c
@@ -470,6 +470,21 @@ st_update_renderbuffer_surface(struct st_context *st,
strb->surface = *psurf;
}
+
+/**
+ * Return the pipe_resource which stores a particular texture image.
+ */
+static struct pipe_resource *
+get_teximage_resource(struct gl_texture_object *texObj,
+ unsigned face, unsigned level)
+{
+ struct st_texture_image *stImg =
+ st_texture_image(texObj->Image[face][level]);
+
+ return stImg->pt;
+}
+
+
/**
* Called by ctx->Driver.RenderTexture
*/
@@ -487,7 +502,9 @@ st_render_texture(struct gl_context *ctx,
if (!st_finalize_texture(ctx, pipe, att->Texture, att->CubeMapFace))
return;
- pt = st_get_texobj_resource(att->Texture);
+ pt = get_teximage_resource(att->Texture,
+ att->CubeMapFace,
+ att->TextureLevel);
When st_AllocTextureImageBuffer allocates a pipe resource for a "loose"
image, it allocates a single level, even if the image is not a mip level
0. So I wonder if we need to adjust the level selection in the
pipe_surface somehow. Is this covered by the incomplete texture tests?
Cheers,
Nicolai
assert(pt);
/* point renderbuffer at texobject */
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/dri: add 32-bit RGBX/RGBA formats
On Friday 30 June 2017, Rob Herring wrote:
> Add support for 32-bit RGBX/RGBA formats which are required for Android.
>
> The original patch (commit ccdcf91104a5) was reverted (commit
> c0c6ca40a25e) in mesa as it broke GLX resulting in swapped colors. Based
> on further investigation by Chad Versace, moving the RGBX/RGBA configs
> to the end is enough to prevent breaking GLX.
>
> Cc: Marek Olšák
> Cc: Eric Anholt
> Cc: Chad Versace
> Cc: Mauro Rossi
> Signed-off-by: Rob Herring
> ---
> I've tested only on Android and could use help testing with KDE which
> broke last time. This has been done on the Intel driver and *should* be
> okay, but maybe not.
Tested-by: Fredrik Höglund
> Mauro, any testing you can do would help. I'm fighting with ADB issues
> installing the apps you tested...
>
> Rob
>
> src/gallium/state_trackers/dri/dri2.c | 6 ++
> src/gallium/state_trackers/dri/dri_screen.c | 23 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c
> b/src/gallium/state_trackers/dri/dri2.c
> index 60ec38d8e445..4928394306e4 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -186,6 +186,9 @@ static enum pipe_format dri2_format_to_pipe_format (int
> format)
> case __DRI_IMAGE_FORMAT_ARGB:
>pf = PIPE_FORMAT_BGRA_UNORM;
>break;
> + case __DRI_IMAGE_FORMAT_XBGR:
> + pf = PIPE_FORMAT_RGBX_UNORM;
> + break;
> case __DRI_IMAGE_FORMAT_ABGR:
>pf = PIPE_FORMAT_RGBA_UNORM;
>break;
> @@ -434,6 +437,9 @@ dri_image_drawable_get_buffers(struct dri_drawable
> *drawable,
>case PIPE_FORMAT_BGRA_UNORM:
> image_format = __DRI_IMAGE_FORMAT_ARGB;
> break;
> + case PIPE_FORMAT_RGBX_UNORM:
> + image_format = __DRI_IMAGE_FORMAT_XBGR;
> + break;
>case PIPE_FORMAT_RGBA_UNORM:
> image_format = __DRI_IMAGE_FORMAT_ABGR;
> break;
> diff --git a/src/gallium/state_trackers/dri/dri_screen.c
> b/src/gallium/state_trackers/dri/dri_screen.c
> index 6b58830e0b42..e3f61447 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/dri_screen.c
> @@ -132,6 +132,27 @@ dri_fill_in_modes(struct dri_screen *screen)
>MESA_FORMAT_B8G8R8A8_SRGB,
>MESA_FORMAT_B8G8R8X8_SRGB,
>MESA_FORMAT_B5G6R5_UNORM,
> +
> + /* The 32-bit RGBA format must not precede the 32-bit BGRA format.
> + * Likewise for RGBX and BGRX. Otherwise, the GLX client and the GLX
> + * server may disagree on which format the GLXFBConfig represents,
> + * resulting in swapped color channels.
> + *
> + * The problem, as of 2017-05-30:
> + * When matching a GLXFBConfig to a __DRIconfig, GLX ignores the
> channel
> + * order and chooses the first __DRIconfig with the expected channel
> + * sizes. Specifically, GLX compares the GLXFBConfig's and
> __DRIconfig's
> + * __DRI_ATTRIB_{CHANNEL}_SIZE but ignores __DRI_ATTRIB_{CHANNEL}_MASK.
> + *
> + * EGL does not suffer from this problem. It correctly compares the
> + * channel masks when matching EGLConfig to __DRIconfig.
> + */
> +
> + /* Required by Android, for HAL_PIXEL_FORMAT_RGBA_. */
> + MESA_FORMAT_R8G8B8A8_UNORM,
> +
> + /* Required by Android, for HAL_PIXEL_FORMAT_RGBX_. */
> + MESA_FORMAT_R8G8B8X8_UNORM,
> };
> static const enum pipe_format pipe_formats[] = {
>PIPE_FORMAT_BGRA_UNORM,
> @@ -139,6 +160,8 @@ dri_fill_in_modes(struct dri_screen *screen)
>PIPE_FORMAT_BGRA_SRGB,
>PIPE_FORMAT_BGRX_SRGB,
>PIPE_FORMAT_B5G6R5_UNORM,
> + PIPE_FORMAT_RGBA_UNORM,
> + PIPE_FORMAT_RGBX_UNORM,
> };
> mesa_format format;
> __DRIconfig **configs = NULL;
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 2/3] gallium/hud: Prevent buffer overflow in hud_thread_counter_install
On Thu, 2017-06-29 at 07:28 -0600, Brian Paul wrote: > On 06/29/2017 07:21 AM, Robert Foss wrote: > > Switch to using strncopy to avoid potential overflow of > > name array in struct hud_graph. > > > > Coverity-id: 1413761 > > > > Signed-off-by: Robert Foss > > --- > > src/gallium/auxiliary/hud/hud_cpu.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/gallium/auxiliary/hud/hud_cpu.c > > b/src/gallium/auxiliary/hud/hud_cpu.c > > index 4caaab6977..468c36207b 100644 > > --- a/src/gallium/auxiliary/hud/hud_cpu.c > > +++ b/src/gallium/auxiliary/hud/hud_cpu.c > > @@ -362,7 +362,7 @@ void hud_thread_counter_install(struct hud_pane > > *pane, const char *name, > > if (!gr) > > return; > > > > - strcpy(gr->name, name); > > + strncpy(gr->name, name, HUD_GRAPH_NAME_LEN); > > strncpy() doesn't null terminate the destination if strlen(name) >= > HUD_GRAPH_NAME_LEN > > If you're concerned with overflow, you need to address that too. > > You might looks if we have a gallium util function for strncpy with > null > termination. I had a look at adding a stncpy analog to src/util/u_string.h but it would seem that these implementation are only intended for _WIN32 platforms. Were you thinking of another bunch of util functions? Or am I misunderstanding something else? Rob. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 101668] Counter-Strike: Global Offense - Everything is purple
https://bugs.freedesktop.org/show_bug.cgi?id=101668 Bug ID: 101668 Summary: Counter-Strike: Global Offense - Everything is purple Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: omin...@autistici.org QA Contact: mesa-dev@lists.freedesktop.org Created attachment 132383 --> https://bugs.freedesktop.org/attachment.cgi?id=132383&action=edit CS:GO Dust 2 Purple Using mesa from this PPA https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa on Linux Mint 18.1 with Linux 4.10 provided by the Linux Mint kernel updater This is how my game looks like. The default performance without an updated kernel + mesa is horrible, so I have to resort to the latest version. I am not certain if this is the right place to report this. I apologise in advance if this is the case. -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 101668] Counter-Strike: Global Offense - Everything is purple
https://bugs.freedesktop.org/show_bug.cgi?id=101668 omin...@autistici.org changed: What|Removed |Added CC||omin...@autistici.org -- You are receiving this mail because: You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/dri: add 32-bit RGBX/RGBA formats
Hi Rob,
It would be better to have a flag passed from libEGL to st/dri saying
that it's OK to expose those formats. I wouldn't like to have GLX
visuals that are unusable in practice because X doesn't support that
component ordering.
Marek
On Fri, Jun 30, 2017 at 8:31 PM, Rob Herring wrote:
> Add support for 32-bit RGBX/RGBA formats which are required for Android.
>
> The original patch (commit ccdcf91104a5) was reverted (commit
> c0c6ca40a25e) in mesa as it broke GLX resulting in swapped colors. Based
> on further investigation by Chad Versace, moving the RGBX/RGBA configs
> to the end is enough to prevent breaking GLX.
>
> Cc: Marek Olšák
> Cc: Eric Anholt
> Cc: Chad Versace
> Cc: Mauro Rossi
> Signed-off-by: Rob Herring
> ---
> I've tested only on Android and could use help testing with KDE which
> broke last time. This has been done on the Intel driver and *should* be
> okay, but maybe not.
>
> Mauro, any testing you can do would help. I'm fighting with ADB issues
> installing the apps you tested...
>
> Rob
>
> src/gallium/state_trackers/dri/dri2.c | 6 ++
> src/gallium/state_trackers/dri/dri_screen.c | 23 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/src/gallium/state_trackers/dri/dri2.c
> b/src/gallium/state_trackers/dri/dri2.c
> index 60ec38d8e445..4928394306e4 100644
> --- a/src/gallium/state_trackers/dri/dri2.c
> +++ b/src/gallium/state_trackers/dri/dri2.c
> @@ -186,6 +186,9 @@ static enum pipe_format dri2_format_to_pipe_format (int
> format)
> case __DRI_IMAGE_FORMAT_ARGB:
>pf = PIPE_FORMAT_BGRA_UNORM;
>break;
> + case __DRI_IMAGE_FORMAT_XBGR:
> + pf = PIPE_FORMAT_RGBX_UNORM;
> + break;
> case __DRI_IMAGE_FORMAT_ABGR:
>pf = PIPE_FORMAT_RGBA_UNORM;
>break;
> @@ -434,6 +437,9 @@ dri_image_drawable_get_buffers(struct dri_drawable
> *drawable,
>case PIPE_FORMAT_BGRA_UNORM:
> image_format = __DRI_IMAGE_FORMAT_ARGB;
> break;
> + case PIPE_FORMAT_RGBX_UNORM:
> + image_format = __DRI_IMAGE_FORMAT_XBGR;
> + break;
>case PIPE_FORMAT_RGBA_UNORM:
> image_format = __DRI_IMAGE_FORMAT_ABGR;
> break;
> diff --git a/src/gallium/state_trackers/dri/dri_screen.c
> b/src/gallium/state_trackers/dri/dri_screen.c
> index 6b58830e0b42..e3f61447 100644
> --- a/src/gallium/state_trackers/dri/dri_screen.c
> +++ b/src/gallium/state_trackers/dri/dri_screen.c
> @@ -132,6 +132,27 @@ dri_fill_in_modes(struct dri_screen *screen)
>MESA_FORMAT_B8G8R8A8_SRGB,
>MESA_FORMAT_B8G8R8X8_SRGB,
>MESA_FORMAT_B5G6R5_UNORM,
> +
> + /* The 32-bit RGBA format must not precede the 32-bit BGRA format.
> + * Likewise for RGBX and BGRX. Otherwise, the GLX client and the GLX
> + * server may disagree on which format the GLXFBConfig represents,
> + * resulting in swapped color channels.
> + *
> + * The problem, as of 2017-05-30:
> + * When matching a GLXFBConfig to a __DRIconfig, GLX ignores the
> channel
> + * order and chooses the first __DRIconfig with the expected channel
> + * sizes. Specifically, GLX compares the GLXFBConfig's and
> __DRIconfig's
> + * __DRI_ATTRIB_{CHANNEL}_SIZE but ignores __DRI_ATTRIB_{CHANNEL}_MASK.
> + *
> + * EGL does not suffer from this problem. It correctly compares the
> + * channel masks when matching EGLConfig to __DRIconfig.
> + */
> +
> + /* Required by Android, for HAL_PIXEL_FORMAT_RGBA_. */
> + MESA_FORMAT_R8G8B8A8_UNORM,
> +
> + /* Required by Android, for HAL_PIXEL_FORMAT_RGBX_. */
> + MESA_FORMAT_R8G8B8X8_UNORM,
> };
> static const enum pipe_format pipe_formats[] = {
>PIPE_FORMAT_BGRA_UNORM,
> @@ -139,6 +160,8 @@ dri_fill_in_modes(struct dri_screen *screen)
>PIPE_FORMAT_BGRA_SRGB,
>PIPE_FORMAT_BGRX_SRGB,
>PIPE_FORMAT_B5G6R5_UNORM,
> + PIPE_FORMAT_RGBA_UNORM,
> + PIPE_FORMAT_RGBX_UNORM,
> };
> mesa_format format;
> __DRIconfig **configs = NULL;
> --
> 2.11.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
[Mesa-dev] [Bug 101668] Counter-Strike: Global Offense - Everything is purple
https://bugs.freedesktop.org/show_bug.cgi?id=101668 --- Comment #1 from Ilia Mirkin --- [You can't assume that anyone upstream knows the specifics of your distro or some private repo you're using] A small recommendation: - List mesa version - List hardware (lspci -nn -d ::300 should generally be enough) If you're interested in this being addressed faster: - Record an apitrace, such that when it is replayed, it shows the issue (https://github.com/apitrace/apitrace) and make this trace available. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] swr: Limit memory held by defer deleted resources.
FWIW I added the exact same workaround in nouveau. I think I even also used 64: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nouveau_fence.c#n270 Reviewed-by: Ilia Mirkin On Fri, Jun 30, 2017 at 11:24 PM, Bruce Cherniak wrote: > This patch limits the number of items on the fence work queue (the > deferred deletion list) by submitting a sync fence when the queue size > exceeds a threshold. This initiates deferred deletion of all resources > on the list and decreases the total amount of memory held waiting for > "deferred deletion". > > This resolves bug 101467 filed against swr for the piglit > streaming-texture-leak test. For those running on smaller memory > (16GB?) systems, this will prevent oom-killer. > > Thus far, we have not seen any real world applications that exhibit > behavior like the streaming-texture-leak test; as any form of pipeline > flush will trigger the defer queue and properly free any retained > allocations. But, this addresses those as well. > > Cc: "17.1" > --- > src/gallium/drivers/swr/swr_screen.cpp | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/src/gallium/drivers/swr/swr_screen.cpp > b/src/gallium/drivers/swr/swr_screen.cpp > index a80ec2adba..16a314c28a 100644 > --- a/src/gallium/drivers/swr/swr_screen.cpp > +++ b/src/gallium/drivers/swr/swr_screen.cpp > @@ -992,6 +992,12 @@ swr_resource_destroy(struct pipe_screen *p_screen, > struct pipe_resource *pt) >swr_fence_work_free(screen->flush_fence, spr->swr.pBaseAddress, true); >swr_fence_work_free(screen->flush_fence, >spr->secondary.pBaseAddress, true); > + > + /* If work queue grows too large, submit a fence to force queue to > + * drain. This is mainly to decrease the amount of memory used by the > + * piglit streaming-texture-leak test */ > + if (screen->pipe && swr_fence(screen->flush_fence)->work.count > 64) > + swr_fence_submit(swr_context(screen->pipe), screen->flush_fence); > } > > FREE(spr); > -- > 2.11.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 1/4] spirv: fix OpBitcast when the src and dst bitsize are different (v2)
On June 30, 2017 19:57:01 Connor Abbott wrote:
From: Connor Abbott
Before, we were just implementing it with a move, which is incorrect
when the source and destination have different bitsizes. To implement
it properly, we need to use the 64-bit pack/unpack opcodes. Since
glslang uses OpBitcast to implement packInt2x32 and unpackInt2x32, this
should fix them on anv (and radv once we enable the int64 capability).
v2: make supporting non-32/64 bit easier (Jason)
Fixes: b3135c3c ("anv: Advertise shaderInt64 on Broadwell and above")
Signed-off-by: Connor Abbott
---
src/compiler/spirv/vtn_alu.c | 65 +++-
1 file changed, 64 insertions(+), 1 deletion(-)
diff --git a/src/compiler/spirv/vtn_alu.c b/src/compiler/spirv/vtn_alu.c
index 9e4beed..e607825 100644
--- a/src/compiler/spirv/vtn_alu.c
+++ b/src/compiler/spirv/vtn_alu.c
@@ -210,6 +210,66 @@ vtn_handle_matrix_alu(struct vtn_builder *b, SpvOp opcode,
}
}
+static void
+vtn_handle_bitcast(struct vtn_builder *b, struct vtn_ssa_value *dest,
+ struct nir_ssa_def *src)
+{
+ if (glsl_get_vector_elements(dest->type) == src->num_components) {
+ /* From the definition of OpBitcast in the SPIR-V 1.2 spec:
+ *
+ * "If Result Type has the same number of components as Operand, they
+ * must also have the same component width, and results are computed per
+ * component."
+ */
+ dest->def = nir_imov(&b->nb, src);
+ return;
+ }
+
+ /* From the definition of OpBitcast in the SPIR-V 1.2 spec:
+*
+* "If Result Type has a different number of components than Operand, the
+* total number of bits in Result Type must equal the total number of bits
+* in Operand. Let L be the type, either Result Type or Operand’s type,
that
+* has the larger number of components. Let S be the other type, with the
+* smaller number of components. The number of components in L must be an
+* integer multiple of the number of components in S. The first component
+* (that is, the only or lowest-numbered component) of S maps to the first
+* components of L, and so on, up to the last component of S mapping to the
+* last components of L. Within this mapping, any single component of S
+* (mapping to multiple components of L) maps its lower-ordered bits to the
+* lower-numbered components of L."
+*/
+ unsigned src_bit_size = src->bit_size;
+ unsigned dest_bit_size = glsl_get_bit_size(dest->type);
+ unsigned src_components = src->num_components;
+ unsigned dest_components = glsl_get_vector_elements(dest->type);
assert(src_bit_size * src_components == dest_bit_size * dest_components);
With that,
Reviewed-by: Jason Ekstrand
+ nir_ssa_def *dest_chan[4];
+ if (src_bit_size > dest_bit_size) {
+ assert(src_bit_size % dest_bit_size == 0);
+ unsigned divisor = src_bit_size / dest_bit_size;
+ for (unsigned comp = 0; comp < src_components; comp++) {
+ assert(src_bit_size == 64);
+ assert(dest_bit_size == 32);
+ nir_ssa_def *split =
+nir_unpack_64_2x32(&b->nb, nir_channel(&b->nb, src, comp));
+ for (unsigned i = 0; i < divisor; i++)
+dest_chan[divisor * comp + i] = nir_channel(&b->nb, split, i);
+ }
+ } else {
+ assert(dest_bit_size % src_bit_size == 0);
+ unsigned divisor = dest_bit_size / src_bit_size;
+ for (unsigned comp = 0; comp < dest_components; comp++) {
+ unsigned channels = ((1 << divisor) - 1) << (comp * divisor);
+ nir_ssa_def *src_chan =
+nir_channels(&b->nb, src, channels);
+ assert(dest_bit_size == 64);
+ assert(src_bit_size == 32);
+ dest_chan[comp] = nir_pack_64_2x32(&b->nb, src_chan);
+ }
+ }
+ dest->def = nir_vec(&b->nb, dest_chan, dest_components);
+}
+
nir_op
vtn_nir_alu_op_for_spirv_opcode(SpvOp opcode, bool *swap,
nir_alu_type src, nir_alu_type dst)
@@ -285,7 +345,6 @@ vtn_nir_alu_op_for_spirv_opcode(SpvOp opcode, bool *swap,
case SpvOpFUnordGreaterThanEqual: return nir_op_fge;
/* Conversions: */
- case SpvOpBitcast: return nir_op_imov;
case SpvOpQuantizeToF16: return nir_op_fquantize2f16;
case SpvOpUConvert:
case SpvOpConvertFToU:
@@ -503,6 +562,10 @@ vtn_handle_alu(struct vtn_builder *b, SpvOp opcode,
break;
}
+ case SpvOpBitcast:
+ vtn_handle_bitcast(b, val->ssa, src[0]);
+ break;
+
default: {
bool swap;
nir_alu_type src_alu_type =
nir_get_nir_type_for_glsl_type(vtn_src[0]->type);
--
2.9.4
___
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 15/19] mesa: hook up UUID queries for driver and device
On June 30, 2017 5:58:24 PM Andres Rodriguez wrote:
On 2017-06-30 07:21 PM, Jason Ekstrand wrote:
On June 30, 2017 4:04:31 PM Andres Rodriguez wrote:
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 6 ++
src/mesa/main/get.c | 17 +
src/mesa/main/version.c | 16
src/mesa/main/version.h | 6 ++
src/mesa/state_tracker/st_context.c | 10 ++
5 files changed, 55 insertions(+)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 27c6efc..65bc97e 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1108,6 +1108,12 @@ struct dd_function_table {
GLenum usage,
struct gl_buffer_object *bufObj);
+ /**
+* Fill uuid with an unique identifier for this driver
+*
+* uuid must point to UUID_SIZE_EXT bytes of available memory
+*/
+ void (*GetUuid)(struct gl_context *ctx, char *uuid);
/*@}*/
/**
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 9f26ad1..bcbec1a 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -40,6 +40,7 @@
#include "framebuffer.h"
#include "samplerobj.h"
#include "stencil.h"
+#include "version.h"
/* This is a table driven implemetation of the glGet*v() functions.
* The basic idea is that most getters just look up an int somewhere
@@ -832,6 +833,14 @@ find_custom_value(struct gl_context *ctx, const
struct value_desc *d, union valu
ctx->Texture.Unit[unit].CurrentTex[d->offset]->Name;
break;
+ /* GL_EXT_external_objects */
+ case GL_DRIVER_UUID_EXT:
+ _mesa_get_driver_uuid(ctx, v->value_int_4);
+ break;
+ case GL_DEVICE_UUID_EXT:
+ _mesa_get_device_uuid(ctx, v->value_int_4);
+ break;
+
/* GL_EXT_packed_float */
case GL_RGBA_SIGNED_COMPONENTS_EXT:
{
@@ -2491,6 +2500,14 @@ find_value_indexed(const char *func, GLenum
pname, GLuint index, union value *v)
goto invalid_value;
v->value_int = ctx->Const.MaxComputeVariableGroupSize[index];
return TYPE_INT;
+
+ /* GL_EXT_external_objects */
+ case GL_DRIVER_UUID_EXT:
+ _mesa_get_driver_uuid(ctx, v->value_int_4);
+ return TYPE_INT_4;
+ case GL_DEVICE_UUID_EXT:
+ _mesa_get_device_uuid(ctx, v->value_int_4);
+ return TYPE_INT_4;
}
invalid_enum:
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 34f8bbb..402fc01 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -635,3 +635,19 @@ _mesa_compute_version(struct gl_context *ctx)
break;
}
}
+
+
+void
+_mesa_get_driver_uuid(struct gl_context *ctx, GLint *uuid)
+{
+ uuid[0] = 'M';
+ uuid[1] = 'E';
+ uuid[2] = 'S';
+ uuid[4] = 'A';
This isn't right. The driver uuid is supposed to encompass not only the
driver but also a version. This is used to ensure that all of the magic
between GL and Vulkan will "just work". That magic includes whatever
heuristics are used to choose image layout. Since these may change from
version to version, this should be some sort of version number and
probably needs to be provided by the actual driver.
This is something I've been on the fence about for a while, mostly
because the vulkan and gl driver for mesa come out of the same source
base. It is very unlikely that an end user will have an incompatible
version of mesa-gl and mesa-vulkan since they will probably be built
from the same commit.
The possible users that could end up mixing and matching different
versions of vulkan and gl are developers or testers. And, while I don't
personally agree with having a mix-and-match of shared libraries, some
people sometimes do it. And that is something that has always been "at
your own risk". I didn't want to kill this use case with a version check.
Killing that use-case is exactly why that query exists in the first place.
Texture layout is a very complex operation with, at least for Intel,
several arbitrary choices. If any of that code changes, things are liable
to break in strange, unpredictable, and hard to debug ways. The individual
developers may not know if a particular addrlib or ISL change will affect
things so it's better off to assume that they all do.
Also, I don't think users trying to run mixed setups is as unlikely as you
make it sound. There are all sorts of people out there that will build a
custom mesa if needed to play their game. If they try to use that with
their system mesa, they're in for trouble.
Having said that, your suggestion is 100% according to spec. I'm just
abusing the fact that mesa-gl and mesa-vk are release tagged together.
It lets us be less restrictive for funky dev/test setups (and it lets me
be a little lazy).
If we still want the version in there, that can be accommodated. If so,
would the mesa version number be sufficient, or do we want something
more specific?
I think we probably want some sort of git she or build id
[Mesa-dev] [PATCH] st/mesa: fix tessellation shaders with no support for shareable shaders
From: Marek Olšák
Broken by: b43c887a9bf1e3fb99b0dc22bfea5db81375a06e
Reported by Gert Wollny.
---
src/mesa/state_tracker/st_atom_shader.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_atom_shader.c
b/src/mesa/state_tracker/st_atom_shader.c
index c1869d3..46f2bd7 100644
--- a/src/mesa/state_tracker/st_atom_shader.c
+++ b/src/mesa/state_tracker/st_atom_shader.c
@@ -226,31 +226,31 @@ st_update_gp(struct st_context *st)
PIPE_SHADER_GEOMETRY, &st->gp);
cso_set_geometry_shader_handle(st->cso_context, shader);
}
void
st_update_tcp(struct st_context *st)
{
void *shader = st_update_common_program(st,
st->ctx->TessCtrlProgram._Current,
- MESA_SHADER_TESS_CTRL, &st->tcp);
+ PIPE_SHADER_TESS_CTRL, &st->tcp);
cso_set_tessctrl_shader_handle(st->cso_context, shader);
}
void
st_update_tep(struct st_context *st)
{
void *shader = st_update_common_program(st,
st->ctx->TessEvalProgram._Current,
- MESA_SHADER_TESS_EVAL, &st->tep);
+ PIPE_SHADER_TESS_EVAL, &st->tep);
cso_set_tesseval_shader_handle(st->cso_context, shader);
}
void
st_update_cp( struct st_context *st )
{
struct st_compute_program *stcp;
if (!st->ctx->ComputeProgram._Current) {
--
2.7.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] Android: generate symlinks for all enabled gallium drivers
Current post install command relies on GALLIUM_TARGET_DRIVERS variable,
however variable needs to be initialized in src/gallium/Android.mk
in order that all enabled gallium drivers symlinks are correctly generated.
At the moment due to sorting of INC_DIRS and variable set with svga (vmwgfx)
only vmwgfx_dri.so and virtio_gpu_dri.so symlinks are generated.
Fixes:a3d98ca62f ("Android: use symlinks for driver loading")
---
src/gallium/Android.mk | 1 +
src/gallium/drivers/svga/Android.mk | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/gallium/Android.mk b/src/gallium/Android.mk
index fbcd6ef2a6..79f920058c 100644
--- a/src/gallium/Android.mk
+++ b/src/gallium/Android.mk
@@ -25,6 +25,7 @@
GALLIUM_TOP := $(call my-dir)
GALLIUM_COMMON_MK := $(GALLIUM_TOP)/Android.common.mk
+GALLIUM_TARGET_DRIVERS :=
SUBDIRS := auxiliary
SUBDIRS += auxiliary/pipe-loader
diff --git a/src/gallium/drivers/svga/Android.mk
b/src/gallium/drivers/svga/Android.mk
index 154cfc4c59..edb69bf2bf 100644
--- a/src/gallium/drivers/svga/Android.mk
+++ b/src/gallium/drivers/svga/Android.mk
@@ -40,6 +40,6 @@ include $(GALLIUM_COMMON_MK)
include $(BUILD_STATIC_LIBRARY)
ifneq ($(HAVE_GALLIUM_VMWGFX),)
-GALLIUM_TARGET_DRIVERS := vmwgfx
+GALLIUM_TARGET_DRIVERS += vmwgfx
$(eval GALLIUM_LIBS += $(LOCAL_MODULE) libmesa_winsys_svga)
endif
--
2.11.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] ac/nir: implement 64-bit packing and unpacking
Not sure whether I'd reviewed the first series, but patches 2-4 are
Reviewed-by: Bas Nieuwenhuizen
On Sat, Jul 1, 2017 at 4:56 AM, Connor Abbott wrote:
> From: Connor Abbott
>
> We implement the split opcodes, and tell NIR to lower the original ones.
> The lowering to LLVM is a little more complicated, but NIR can optimize
> the split ones a little better, and some NIR lowering passes that we
> might want to use (particularly for doubles) emit the split ones.
>
> This should fix pack/unpackDouble2x32, which seems like a bug since when
> we enabled the Float64 capability. It will also fix pack/unpackInt2x32
> when we enable the Int64 capability.
>
> Fixes: 798ae37c ("radv: Enable Float64 support.")
> Signed-off-by: Connor Abbott
> ---
> src/amd/common/ac_nir_to_llvm.c | 31 +++
> src/amd/vulkan/radv_pipeline.c | 1 +
> 2 files changed, 32 insertions(+)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 51daa3c..88f3f44 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -1866,6 +1866,37 @@ static void visit_alu(struct nir_to_llvm_context *ctx,
> const nir_alu_instr *inst
> case nir_op_fddy_coarse:
> result = emit_ddxy(ctx, instr->op, src[0]);
> break;
> +
> + case nir_op_unpack_64_2x32_split_x: {
> + assert(instr->src[0].src.ssa->num_components == 1);
> + LLVMValueRef tmp = LLVMBuildBitCast(ctx->builder, src[0],
> + LLVMVectorType(ctx->i32,
> 2),
> + "");
> + result = LLVMBuildExtractElement(ctx->builder, tmp,
> +ctx->i32zero, "");
> + break;
> + }
> +
> + case nir_op_unpack_64_2x32_split_y: {
> + assert(instr->src[0].src.ssa->num_components == 1);
> + LLVMValueRef tmp = LLVMBuildBitCast(ctx->builder, src[0],
> + LLVMVectorType(ctx->i32,
> 2),
> + "");
> + result = LLVMBuildExtractElement(ctx->builder, tmp,
> +ctx->i32one, "");
> + break;
> + }
> +
> + case nir_op_pack_64_2x32_split: {
> + LLVMValueRef tmp = LLVMGetUndef(LLVMVectorType(ctx->i32, 2));
> + tmp = LLVMBuildInsertElement(ctx->builder, tmp,
> +src[0], ctx->i32zero, "");
> + tmp = LLVMBuildInsertElement(ctx->builder, tmp,
> +src[1], ctx->i32one, "");
> + result = LLVMBuildBitCast(ctx->builder, tmp, ctx->i64, "");
> + break;
> + }
> +
> default:
> fprintf(stderr, "Unknown NIR alu instr: ");
> nir_print_instr(&instr->instr, stderr);
> diff --git a/src/amd/vulkan/radv_pipeline.c b/src/amd/vulkan/radv_pipeline.c
> index efe641d..d05acd2 100644
> --- a/src/amd/vulkan/radv_pipeline.c
> +++ b/src/amd/vulkan/radv_pipeline.c
> @@ -151,6 +151,7 @@ radv_optimize_nir(struct nir_shader *shader)
> progress = false;
>
> NIR_PASS_V(shader, nir_lower_vars_to_ssa);
> + NIR_PASS_V(shader, nir_lower_64bit_pack);
> NIR_PASS_V(shader, nir_lower_alu_to_scalar);
> NIR_PASS_V(shader, nir_lower_phis_to_scalar);
>
> --
> 2.9.4
>
> ___
> 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 18/18] nir/spirv: Rework function argument setup
On Fri, Jun 30, 2017 at 4:31 PM, Connor Abbott wrote:
> On Fri, Jun 30, 2017 at 4:25 PM, Jason Ekstrand
> wrote:
> > On June 30, 2017 3:28:51 PM Connor Abbott wrote:
> >
> >> Now, that we're handling the pointers explicitly, can't we delete the
> >> code in vtn_ssa_value()
> >> to implicitly load pointers? I'd expect to see that in this patch.
> >
> >
> > Almost. It's still used to implement some glsl.450 functions which take
> a
> > variable rather than an SSA vale as an input. I'm happy to fix those up
> or
> > at least to move the hack to glsl_450 but it'll have to be a separate
> patch.
>
> Ok... at least you should change the comment there that says "This is
> needed for function parameters" though. And making those cases aware
> of pointers vs. SSA would be nice. It would probably make the code
> less confusing too, since it would match the spec.
>
I've sent a 17.5/18 which fixes the problem so it can be deleted in this
one.
> >
> >
> >> On Thu, Jun 29, 2017 at 10:33 AM, Jason Ekstrand
> >> wrote:
> >>>
> >>> Now that we have proper pointer types, we can be more sensible about
> the
> >>> way we set up function arguments and deal with the two cases of pointer
> >>> vs. SSA parameters distinctly.
> >>> ---
> >>> src/compiler/spirv/vtn_cfg.c | 62
> >>> +---
> >>> 1 file changed, 35 insertions(+), 27 deletions(-)
> >>>
> >>> diff --git a/src/compiler/spirv/vtn_cfg.c
> b/src/compiler/spirv/vtn_cfg.c
> >>> index 83e77e2..f53572b 100644
> >>> --- a/src/compiler/spirv/vtn_cfg.c
> >>> +++ b/src/compiler/spirv/vtn_cfg.c
> >>> @@ -65,6 +65,7 @@ vtn_cfg_handle_prepass_instruction(struct
> vtn_builder
> >>> *b, SpvOp opcode,
> >>>func->return_type = func_type->return_type->type;
> >>>
> >>>b->func->impl = nir_function_impl_create(func);
> >>> + b->nb.cursor = nir_before_cf_list(&b->func->impl->body);
> >>>
> >>>b->func_param_idx = 0;
> >>>break;
> >>> @@ -77,43 +78,50 @@ vtn_cfg_handle_prepass_instruction(struct
> vtn_builder
> >>> *b, SpvOp opcode,
> >>>
> >>> case SpvOpFunctionParameter: {
> >>>struct vtn_type *type = vtn_value(b, w[1],
> >>> vtn_value_type_type)->type;
> >>> - if (type->base_type == vtn_base_type_pointer) {
> >>> - type = type->deref;
> >>> - assert(type->base_type != vtn_base_type_pointer);
> >>> - }
> >>>
> >>>assert(b->func_param_idx < b->func->impl->num_params);
> >>>nir_variable *param = b->func->impl->params[b->func_
> param_idx++];
> >>>
> >>> - assert(type->type == param->type);
> >>> + if (type->base_type == vtn_base_type_pointer) {
> >>> + struct vtn_variable *vtn_var = rzalloc(b, struct
> vtn_variable);
> >>> + vtn_var->type = type->deref;
> >>> + vtn_var->var = param;
> >>> +
> >>> + assert(vtn_var->type->type == param->type);
> >>> +
> >>> + struct vtn_type *without_array = vtn_var->type;
> >>> + while(glsl_type_is_array(without_array->type))
> >>> +without_array = without_array->array_element;
> >>> +
> >>> + if (glsl_type_is_image(without_array->type)) {
> >>> +vtn_var->mode = vtn_variable_mode_image;
> >>> +param->interface_type = without_array->type;
> >>> + } else if (glsl_type_is_sampler(without_array->type)) {
> >>> +vtn_var->mode = vtn_variable_mode_sampler;
> >>> +param->interface_type = without_array->type;
> >>> + } else {
> >>> +vtn_var->mode = vtn_variable_mode_param;
> >>> + }
> >>>
> >>> - struct vtn_variable *vtn_var = rzalloc(b, struct vtn_variable);
> >>> - vtn_var->type = type;
> >>> - vtn_var->var = param;
> >>> + struct vtn_value *val =
> >>> +vtn_push_value(b, w[2], vtn_value_type_pointer);
> >>>
> >>> - struct vtn_type *without_array = type;
> >>> - while(glsl_type_is_array(without_array->type))
> >>> - without_array = without_array->array_element;
> >>> + /* Name the parameter so it shows up nicely in NIR */
> >>> + param->name = ralloc_strdup(param, val->name);
> >>>
> >>> - if (glsl_type_is_image(without_array->type)) {
> >>> - vtn_var->mode = vtn_variable_mode_image;
> >>> - param->interface_type = without_array->type;
> >>> - } else if (glsl_type_is_sampler(without_array->type)) {
> >>> - vtn_var->mode = vtn_variable_mode_sampler;
> >>> - param->interface_type = without_array->type;
> >>> + val->pointer = rzalloc(b, struct vtn_pointer);
> >>> + val->pointer->mode = vtn_var->mode;
> >>> + val->pointer->type = type;
> >>> + val->pointer->var = vtn_var;
> >>>} else {
> >>> - vtn_var->mode = vtn_variable_mode_param;
> >>> - }
> >>> + /* We're a regular SSA value. */
> >>> + struct vtn_value *val = vtn_push_value(b, w[2],
> >>> vtn_value_type_ssa);
> >>>
> >>> - struct vtn_val
Re: [Mesa-dev] [PATCH 15/19] mesa: hook up UUID queries for driver and device
On 2017-07-01 11:29 AM, Jason Ekstrand wrote:
On June 30, 2017 5:58:24 PM Andres Rodriguez wrote:
On 2017-06-30 07:21 PM, Jason Ekstrand wrote:
On June 30, 2017 4:04:31 PM Andres Rodriguez wrote:
Signed-off-by: Andres Rodriguez
---
src/mesa/main/dd.h | 6 ++
src/mesa/main/get.c | 17 +
src/mesa/main/version.c | 16
src/mesa/main/version.h | 6 ++
src/mesa/state_tracker/st_context.c | 10 ++
5 files changed, 55 insertions(+)
diff --git a/src/mesa/main/dd.h b/src/mesa/main/dd.h
index 27c6efc..65bc97e 100644
--- a/src/mesa/main/dd.h
+++ b/src/mesa/main/dd.h
@@ -1108,6 +1108,12 @@ struct dd_function_table {
GLenum usage,
struct gl_buffer_object *bufObj);
+ /**
+* Fill uuid with an unique identifier for this driver
+*
+* uuid must point to UUID_SIZE_EXT bytes of available memory
+*/
+ void (*GetUuid)(struct gl_context *ctx, char *uuid);
/*@}*/
/**
diff --git a/src/mesa/main/get.c b/src/mesa/main/get.c
index 9f26ad1..bcbec1a 100644
--- a/src/mesa/main/get.c
+++ b/src/mesa/main/get.c
@@ -40,6 +40,7 @@
#include "framebuffer.h"
#include "samplerobj.h"
#include "stencil.h"
+#include "version.h"
/* This is a table driven implemetation of the glGet*v() functions.
* The basic idea is that most getters just look up an int somewhere
@@ -832,6 +833,14 @@ find_custom_value(struct gl_context *ctx, const
struct value_desc *d, union valu
ctx->Texture.Unit[unit].CurrentTex[d->offset]->Name;
break;
+ /* GL_EXT_external_objects */
+ case GL_DRIVER_UUID_EXT:
+ _mesa_get_driver_uuid(ctx, v->value_int_4);
+ break;
+ case GL_DEVICE_UUID_EXT:
+ _mesa_get_device_uuid(ctx, v->value_int_4);
+ break;
+
/* GL_EXT_packed_float */
case GL_RGBA_SIGNED_COMPONENTS_EXT:
{
@@ -2491,6 +2500,14 @@ find_value_indexed(const char *func, GLenum
pname, GLuint index, union value *v)
goto invalid_value;
v->value_int = ctx->Const.MaxComputeVariableGroupSize[index];
return TYPE_INT;
+
+ /* GL_EXT_external_objects */
+ case GL_DRIVER_UUID_EXT:
+ _mesa_get_driver_uuid(ctx, v->value_int_4);
+ return TYPE_INT_4;
+ case GL_DEVICE_UUID_EXT:
+ _mesa_get_device_uuid(ctx, v->value_int_4);
+ return TYPE_INT_4;
}
invalid_enum:
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 34f8bbb..402fc01 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -635,3 +635,19 @@ _mesa_compute_version(struct gl_context *ctx)
break;
}
}
+
+
+void
+_mesa_get_driver_uuid(struct gl_context *ctx, GLint *uuid)
+{
+ uuid[0] = 'M';
+ uuid[1] = 'E';
+ uuid[2] = 'S';
+ uuid[4] = 'A';
This isn't right. The driver uuid is supposed to encompass not only the
driver but also a version. This is used to ensure that all of the magic
between GL and Vulkan will "just work". That magic includes whatever
heuristics are used to choose image layout. Since these may change from
version to version, this should be some sort of version number and
probably needs to be provided by the actual driver.
This is something I've been on the fence about for a while, mostly
because the vulkan and gl driver for mesa come out of the same source
base. It is very unlikely that an end user will have an incompatible
version of mesa-gl and mesa-vulkan since they will probably be built
from the same commit.
The possible users that could end up mixing and matching different
versions of vulkan and gl are developers or testers. And, while I don't
personally agree with having a mix-and-match of shared libraries, some
people sometimes do it. And that is something that has always been "at
your own risk". I didn't want to kill this use case with a version check.
Killing that use-case is exactly why that query exists in the first
place. Texture layout is a very complex operation with, at least for
Intel, several arbitrary choices. If any of that code changes, things
are liable to break in strange, unpredictable, and hard to debug ways.
The individual developers may not know if a particular addrlib or ISL
change will affect things so it's better off to assume that they all do.
Also, I don't think users trying to run mixed setups is as unlikely as
you make it sound. There are all sorts of people out there that will
build a custom mesa if needed to play their game. If they try to use
that with their system mesa, they're in for trouble.
Having said that, your suggestion is 100% according to spec. I'm just
abusing the fact that mesa-gl and mesa-vk are release tagged together.
It lets us be less restrictive for funky dev/test setups (and it lets me
be a little lazy).
If we still want the version in there, that can be accommodated. If so,
would the mesa version number be sufficient, or do we want something
more specific?
I think w
Re: [Mesa-dev] [PATCH] glthread: get rid of unmarshal dispatch enum/table
Instead of passing the function pointer through the queue, passing
just a call ID (uint16_t) is preferable.
If the switch statement is an issue, doing a function pointer lookup
from a static array should be OK.
Marek
On Fri, Jun 30, 2017 at 7:14 PM, Grigori Goronzy wrote:
> On 2017-06-30 15:27, Nicolai Hähnle wrote:
>>
>> On 30.06.2017 02:29, Grigori Goronzy wrote:
>>>
>>> Use function pointers to identify the unmarshalling function, which
>>> is simpler and gets rid of a lot generated code.
>>>
>>> This removes an indirection and possibly results in a slight speedup
>>> as well.
>>
>>
>> The fact that it blows up cmd_base from 4 bytes to 16 bytes might
>> result in a slowdown. Marek's recent changes clearly indicated that
>> looking at memory behavior matters quite a bit for glthread. So I'm
>> inclined to say No on this unless you can demonstrate a consistent
>> speedup.
>>
>
> That's indeed a notable difference. I suspect it isn't so much the byte size
> of the marshalled commands that affects throughput, but the number of
> commands per batch and their associated costs when unmarshalling, so the
> larger size of cmd_base might not matter much (perhaps with adjusted max
> batch size). In any case, I'll try get hold of some numbers.
>
> Best regards
> Grigori
>
>
>> Cheers,
>> Nicolai
>>
>>
>>> ---
>>> src/mapi/glapi/gen/Makefile.am | 4 --
>>> src/mapi/glapi/gen/gl_marshal.py | 36 ++--
>>> src/mapi/glapi/gen/gl_marshal_h.py | 86
>>> --
>>> src/mesa/Android.gen.mk| 7
>>> src/mesa/Makefile.sources | 1 -
>>> src/mesa/SConscript| 8
>>> src/mesa/main/.gitignore | 1 -
>>> src/mesa/main/glthread.c | 9 +++-
>>> src/mesa/main/glthread.h | 2 -
>>> src/mesa/main/marshal.c| 19 -
>>> src/mesa/main/marshal.h| 14 +++
>>> 11 files changed, 26 insertions(+), 161 deletions(-)
>>> delete mode 100644 src/mapi/glapi/gen/gl_marshal_h.py
>>>
>>> diff --git a/src/mapi/glapi/gen/Makefile.am
>>> b/src/mapi/glapi/gen/Makefile.am
>>> index bd04519..62007a4 100644
>>> --- a/src/mapi/glapi/gen/Makefile.am
>>> +++ b/src/mapi/glapi/gen/Makefile.am
>>> @@ -76,7 +76,6 @@ EXTRA_DIST= \
>>> gl_genexec.py \
>>> gl_gentable.py \
>>> gl_marshal.py \
>>> - gl_marshal_h.py \
>>> gl_procs.py \
>>> gl_SPARC_asm.py \
>>> gl_table.py \
>>> @@ -297,9 +296,6 @@ $(MESA_DIR)/main/api_exec.c: gl_genexec.py apiexec.py
>>> $(COMMON)
>>> $(MESA_DIR)/main/marshal_generated.c: gl_marshal.py marshal_XML.py
>>> $(COMMON)
>>> $(PYTHON_GEN) $(srcdir)/gl_marshal.py -f
>>> $(srcdir)/gl_and_es_API.xml > $@
>>> -$(MESA_DIR)/main/marshal_generated.h: gl_marshal_h.py marshal_XML.py
>>> $(COMMON)
>>> - $(PYTHON_GEN) $(srcdir)/gl_marshal_h.py -f
>>> $(srcdir)/gl_and_es_API.xml > $@
>>> -
>>> $(MESA_DIR)/main/dispatch.h: gl_table.py $(COMMON)
>>> $(PYTHON_GEN) $(srcdir)/gl_table.py -f
>>> $(srcdir)/gl_and_es_API.xml -m remap_table > $@
>>> diff --git a/src/mapi/glapi/gen/gl_marshal.py
>>> b/src/mapi/glapi/gen/gl_marshal.py
>>> index efa4d9e..e71ede3 100644
>>> --- a/src/mapi/glapi/gen/gl_marshal.py
>>> +++ b/src/mapi/glapi/gen/gl_marshal.py
>>> @@ -34,7 +34,6 @@ header = """
>>> #include "dispatch.h"
>>> #include "glthread.h"
>>> #include "marshal.h"
>>> -#include "marshal_generated.h"
>>> """
>>> @@ -106,7 +105,7 @@ class PrintCode(gl_XML.gl_print_base):
>>> def print_async_dispatch(self, func):
>>> out('cmd = _mesa_glthread_allocate_command(ctx, '
>>> -'DISPATCH_CMD_{0}, cmd_size);'.format(func.name))
>>> +'(unmarshal_func)_mesa_unmarshal_{0},
>>> cmd_size);'.format(func.name))
>>> for p in func.fixed_params:
>>> if p.count:
>>> out('memcpy(cmd->{0}, {0}, {1});'.format(
>>> @@ -166,7 +165,7 @@ class PrintCode(gl_XML.gl_print_base):
>>> out('};')
>>> def print_async_unmarshal(self, func):
>>> -out('static inline void')
>>> +out('static void')
>>> out(('_mesa_unmarshal_{0}(struct gl_context *ctx, '
>>>'const struct marshal_cmd_{0} *cmd)').format(func.name))
>>> out('{')
>>> @@ -205,6 +204,7 @@ class PrintCode(gl_XML.gl_print_base):
>>> else:
>>> out('variable_data +=
>>> {0};'.format(p.size_string(False)))
>>> +out('debug_print_unmarshal("{0}");'.format(func.name))
>>> self.print_sync_call(func)
>>> out('}')
>>> @@ -276,35 +276,6 @@ class PrintCode(gl_XML.gl_print_base):
>>> out('')
>>> out('')
>>> -def print_unmarshal_dispatch_cmd(self, api):
>>> -out('size_t')
>>> -out('_mesa_unmarshal_dispatch_cmd(struct gl_context *ctx, '
>>> -'const void *cmd)')
>>> -out('{')
>>> -w
Re: [Mesa-dev] [PATCH] i965: Print access flags in INTEL_DEBUG=buf output.
Reviewed-by: Matt Turner ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 101668] Counter-Strike: Global Offense - Everything is purple
https://bugs.freedesktop.org/show_bug.cgi?id=101668 --- Comment #2 from omin...@autistici.org --- Package: libgl1-mesa-glx Version: 1:17.2~git170629170600.277621b~x~padoka0 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Fiji [Radeon R9 FURY / NANO Series] [1002:7300] (rev cb) Trace file: http://b2.ge.tt/gett/5MYOqal2/csgo_linux64.trace.7z -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Remove clearing of bo->map_gtt after failure
On Saturday, July 1, 2017 3:14:00 AM PDT Chris Wilson wrote:
> With the conversion to storing the result of drm_mmap to a local and not
> directly to bo->map_gtt itself, we no longer should clear bo->map_gtt.
> In the best the operation is redundant as we know bo->map_gtt to already
> be NULL, but in the worst case we overwrite a concurrent thread that
> successfully mmaped the GTT.
>
> Fixes: 314647c4c206 ("i965: Drop global bufmgr lock from brw_bo_map_*
> functions.")
> Signed-off-by: Chris Wilson
> Cc: Kenneth Graunke
> Cc: Matt Turner
> ---
> src/mesa/drivers/dri/i965/brw_bufmgr.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> index 8ed6ba5f41..d05885cfaf 100644
> --- a/src/mesa/drivers/dri/i965/brw_bufmgr.c
> +++ b/src/mesa/drivers/dri/i965/brw_bufmgr.c
> @@ -747,7 +747,6 @@ brw_bo_map_gtt(struct brw_context *brw, struct brw_bo
> *bo, unsigned flags)
>map = drm_mmap(0, bo->size, PROT_READ | PROT_WRITE,
> MAP_SHARED, bufmgr->fd, mmap_arg.offset);
>if (map == MAP_FAILED) {
> - bo->map_gtt = NULL;
> DBG("%s:%d: Error mapping buffer %d (%s): %s .\n",
> __FILE__, __LINE__, bo->gem_handle, bo->name, strerror(errno));
> return NULL;
>
Thanks, sorry for botching this. I tested this and pushed the patch.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 101668] Counter-Strike: Global Offense - Everything is purple
https://bugs.freedesktop.org/show_bug.cgi?id=101668 --- Comment #3 from Laurent carlier --- Probably a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=101561 , now fixed in llvm trunk -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug.___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/16]: Allow Gallium drivers to support driver-specific drirc options
On Friday, June 30, 2017 5:59:43 AM PDT Nicolai Hähnle wrote: > There is one change that I forgot to mention: > > The existing xmlconfig system can filter drirc settings by X screen > number. After the series, this no longer works. Or rather, the system > behaves as if we're always on screen 0. > > I really don't think this is a big deal, since multiple X screens is not > exactly a feature people use at all, let alone in this context. There's > also no way it can possibly work reliably for radeonsi-specific options, > because our pipe_screen is per-process/device, not per-X-screen. > > But perhaps we should warn users explicitly that this screen-filtering > is deprecated. > > Cheers, > Nicolai Thanks for doing this! I don't think that's a big deal either. I wasn't even aware it could do that, much less whether it works. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] anv: fix reported timestampPeriod value
We lost some precision on a previous change due to switching to
integers. Since we report a float in timestampPeriod, we want the
division to happen in floats.
CID: 1413021
Fixes: c77d98ef32 ("intel: common: express timestamps units in frequency")
Signed-off-by: Lionel Landwerlin
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 29064f073d0..38db1268825 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -888,7 +888,7 @@ void anv_GetPhysicalDeviceProperties(
.storageImageSampleCounts = VK_SAMPLE_COUNT_1_BIT,
.maxSampleMaskWords = 1,
.timestampComputeAndGraphics = false,
- .timestampPeriod = 10ull /
devinfo->timestamp_frequency,
+ .timestampPeriod = 10.0 /
devinfo->timestamp_frequency,
.maxClipDistances = 8,
.maxCullDistances = 8,
.maxCombinedClipAndCullDistances = 8,
--
2.13.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] anv: fix reported timestampPeriod value
Rb
On July 1, 2017 4:43:45 PM Lionel Landwerlin
wrote:
We lost some precision on a previous change due to switching to
integers. Since we report a float in timestampPeriod, we want the
division to happen in floats.
CID: 1413021
Fixes: c77d98ef32 ("intel: common: express timestamps units in frequency")
Signed-off-by: Lionel Landwerlin
---
src/intel/vulkan/anv_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/intel/vulkan/anv_device.c b/src/intel/vulkan/anv_device.c
index 29064f073d0..38db1268825 100644
--- a/src/intel/vulkan/anv_device.c
+++ b/src/intel/vulkan/anv_device.c
@@ -888,7 +888,7 @@ void anv_GetPhysicalDeviceProperties(
.storageImageSampleCounts = VK_SAMPLE_COUNT_1_BIT,
.maxSampleMaskWords = 1,
.timestampComputeAndGraphics = false,
- .timestampPeriod = 10ull /
devinfo->timestamp_frequency,
+ .timestampPeriod = 10.0 /
devinfo->timestamp_frequency,
.maxClipDistances = 8,
.maxCullDistances = 8,
.maxCombinedClipAndCullDistances = 8,
--
2.13.2
___
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] anv: merge tessellation's primitive mode in merge_tess_info()
On Wednesday, June 28, 2017 3:20:29 AM PDT Samuel Iglesias Gonsálvez wrote: > SPIR-V tessellation shaders that were created from HSLS will have > the primitive generation domain set in tessellation control shader > (hull shader in HLSL) instead of the tessellation evaluation shader. > > Signed-off-by: Samuel Iglesias Gonsálvez > --- > src/intel/vulkan/anv_pipeline.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/intel/vulkan/anv_pipeline.c b/src/intel/vulkan/anv_pipeline.c > index c43915e..76b45b9 100644 > --- a/src/intel/vulkan/anv_pipeline.c > +++ b/src/intel/vulkan/anv_pipeline.c > @@ -587,6 +587,7 @@ merge_tess_info(struct shader_info *tes_info, >tcs_info->tess.spacing == tes_info->tess.spacing); > tes_info->tess.spacing |= tcs_info->tess.spacing; > > + tes_info->tess.primitive_mode |= tcs_info->tess.primitive_mode; > tes_info->tess.ccw |= tcs_info->tess.ccw; > tes_info->tess.point_mode |= tcs_info->tess.point_mode; > } > Oops. I even had the comment and everything. Please add: assert(tcs_info->tess.primitive_mode == 0 || tes_info->tess.primitive_mode == 0 || tcs_info->tess.primitive_mode == tes_info->tess.primitive_mode); Reviewed-by: Kenneth Graunke Thanks for fixing this. I looked to see if radv needed a similar change, but it doesn't look like they have any merging code like this. signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/12] i965: Don't recalculate partial_clear inside brw_fast_clear_depth
On Monday, June 26, 2017 4:22:36 PM PDT Ian Romanick wrote:
> From: Ian Romanick
>
>text data bss dec hex filename
> 7155954256860 37332 7450146 71ae22 32-bit i965_dri.so before
> 7155858256860 37332 7450050 71adc2 32-bit i965_dri.so after
> 6789395328056 50704 7168155 6d609b 64-bit i965_dri.so before
> 6789299328056 50704 7168059 6d603b 64-bit i965_dri.so after
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/drivers/dri/i965/brw_clear.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_clear.c
> b/src/mesa/drivers/dri/i965/brw_clear.c
> index 7fbaa3a..1e434c9 100644
> --- a/src/mesa/drivers/dri/i965/brw_clear.c
> +++ b/src/mesa/drivers/dri/i965/brw_clear.c
> @@ -99,7 +99,7 @@ noop_scissor(struct gl_framebuffer *fb)
> * at least until a resolve to the real depth buffer happens.
> */
> static bool
> -brw_fast_clear_depth(struct gl_context *ctx)
> +brw_fast_clear_depth(struct gl_context *ctx, bool partial_clear)
> {
> struct brw_context *brw = brw_context(ctx);
> struct gl_framebuffer *fb = ctx->DrawBuffer;
> @@ -118,7 +118,7 @@ brw_fast_clear_depth(struct gl_context *ctx)
> * a previous clear had happened at a different clear value and resolve it
> * first.
> */
> - if ((ctx->Scissor.EnableFlags & 1) && !noop_scissor(fb)) {
> + if (partial_clear) {
>perf_debug("Failed to fast clear %dx%d depth because of scissors. "
> "Possible 5%% performance win if avoided.\n",
> mt->logical_width0, mt->logical_height0);
> @@ -213,7 +213,7 @@ brw_clear(struct gl_context *ctx, GLbitfield mask)
> brw_workaround_depthstencil_alignment(brw, partial_clear ? 0 : mask);
>
> if (mask & BUFFER_BIT_DEPTH) {
> - if (brw_fast_clear_depth(ctx)) {
> + if (brw_fast_clear_depth(ctx, partial_clear)) {
>DBG("fast clear: depth\n");
>mask &= ~BUFFER_BIT_DEPTH;
>}
>
This is technically not equivalent...brw_fast_clear_depth checks if
scissor 0 is enabled, while the caller checks if any scissor is enabled.
Only checking scissor 0 seems like the right thing to do to me.
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/12] i965/urb: Trigger upload_urb on NEW_BLORP
On Monday, June 26, 2017 4:22:35 PM PDT Ian Romanick wrote:
> From: Jason Ekstrand
>
> It's a bit rare, but blorp can trigger a urb reconfiguration. When that
> happens, we need to re-upload the URB config. Fortunately, this isn't as
> bad as it looks because gen7_upload_urb will not re-emit the packet if it
> would end up being a no-op so this doesn't mean that running blorp always
> triggers a URB reconfig.
>
> v2 (idr): Sort BRW_NEW_ tokens to match brw_recalculate_urb_fence and
> gen6_urb.
>
> v3 (idr): Don't whack BRW_NEW_URB_SIZE in blorp. Suggested by Jason.
> ---
> src/mesa/drivers/dri/i965/gen7_urb.c| 3 ++-
> src/mesa/drivers/dri/i965/genX_blorp_exec.c | 2 --
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/gen7_urb.c
> b/src/mesa/drivers/dri/i965/gen7_urb.c
> index 525c9c4..c4b479c 100644
> --- a/src/mesa/drivers/dri/i965/gen7_urb.c
> +++ b/src/mesa/drivers/dri/i965/gen7_urb.c
> @@ -236,7 +236,8 @@ gen7_upload_urb(struct brw_context *brw, unsigned vs_size,
> const struct brw_tracked_state gen7_urb = {
> .dirty = {
>.mesa = 0,
> - .brw = BRW_NEW_CONTEXT |
> + .brw = BRW_NEW_BLORP |
> + BRW_NEW_CONTEXT |
> BRW_NEW_URB_SIZE |
> BRW_NEW_GS_PROG_DATA |
> BRW_NEW_TCS_PROG_DATA |
> diff --git a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> index 8fd17fb..af3d609 100644
> --- a/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> +++ b/src/mesa/drivers/dri/i965/genX_blorp_exec.c
> @@ -183,8 +183,6 @@ blorp_emit_urb_config(struct blorp_batch *batch,
> brw->urb.vsize >= vs_entry_size)
>return;
>
> - brw->ctx.NewDriverState |= BRW_NEW_URB_SIZE;
> -
> gen7_upload_urb(brw, vs_entry_size, false, false);
> #elif GEN_GEN == 6
> gen6_upload_urb(brw, vs_entry_size, false, 0);
>
The commit message is a bit confusing. It makes it sound like we were
failing to re-emit 3DSTATE_URB_* from the main drawing path after BLORP
trashed it. However, the brw->ctx.NewDriverState |= BRW_NEW_URB_SIZE
line that you deleted here guaranteed that it would happen.
The real benefit appears to be that flagging BRW_NEW_URB_SIZE ("the
total size of the URB portion of the L3 cache has changed") causes
BLORP to think it needs to re-configure it again, so say, back-to-back
BLORP operations would configure it every time.
Using BRW_NEW_BLORP is definitely better - that's what it's there for.
Reviewed-by: Kenneth Graunke
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
