Re: [Mesa-dev] mesa compilatin

[Ernst Sjöstrand]

I would suggest ignoring the debian packages and installing Mesa in a
special directory somewhere in your home folder.
You can follow these steps:
https://docs.mesa3d.org/install.html#running-against-a-local-build


Den tors 30 sep. 2021 kl 11:45 skrev rajeev agrawal :

> thanks for the reply .
> I compiled everything and copied the files generated on my machine . But
> while running glxinfo | grep -i "OpenGL version" -> it was showing mesa
> 20.0.8 while the mesa version is 21.3 which I compiled .
>
> Can you please suggest which I can try or is it expected ?
>
> Thanks
> Rajeev
>
> On Thu, Sep 30, 2021 at 2:50 PM Ernst Sjöstrand  wrote:
>
>> The Mesa project itself has no support for building debian packages, it's
>> something added ontop by debian based distributions.
>>
>> There are various updated packages for Ubuntu on Launchpad in a number of
>> PPAs like Oibaf and Kisak PPAs.
>> Also this guy has a PPA:
>> https://launchpad.net/~ernstp/+archive/ubuntu/mesarc
>>
>> If you want to build packages locally I suggest cloning from
>> https://salsa.debian.org/xorg-team/lib/mesa
>> and then searching general instructions for how to build debian packages.
>>
>> //E
>>
>>
>> Den tors 30 sep. 2021 kl 09:45 skrev rajeev agrawal <
>> rjv.16agra...@gmail.com>:
>>
>>> Hi ,
>>>
>>> I am trying to compile mesa from the repo.
>>> https://gitlab.freedesktop.org/mesa/mesa/-/tree/main
>>>
>>> Are there any steps on how to create the deb file.
>>> After compiling and installing to a local folder a copied the folder to
>>> my device ,still I can see the mesa version as old only.(20.0.8)
>>> Am i missing anything.PLease help me out in resolving the issue.
>>>
>>> Thanks
>>> Rajeev
>>>
>>>

Re: [Mesa-dev] mesa compilatin

[Ernst Sjöstrand]

The Mesa project itself has no support for building debian packages, it's
something added ontop by debian based distributions.

There are various updated packages for Ubuntu on Launchpad in a number of
PPAs like Oibaf and Kisak PPAs.
Also this guy has a PPA:
https://launchpad.net/~ernstp/+archive/ubuntu/mesarc

If you want to build packages locally I suggest cloning from
https://salsa.debian.org/xorg-team/lib/mesa
and then searching general instructions for how to build debian packages.

//E


Den tors 30 sep. 2021 kl 09:45 skrev rajeev agrawal :

> Hi ,
>
> I am trying to compile mesa from the repo.
> https://gitlab.freedesktop.org/mesa/mesa/-/tree/main
>
> Are there any steps on how to create the deb file.
> After compiling and installing to a local folder a copied the folder to my
> device ,still I can see the mesa version as old only.(20.0.8)
> Am i missing anything.PLease help me out in resolving the issue.
>
> Thanks
> Rajeev
>
>

Re: [Mesa-dev] Can't get self-built Mesa to work on the Raspberry Pi 4

[Ernst Sjöstrand]

LIBGL_DEBUG=verbose could be a good start?

Regards
//Ernst

Den ons 6 jan. 2021 kl 12:31 skrev :

> Hi all,
>
> In order to check whether a OpenGL ES driver bug I'm hitting on the
> Raspberry Pi 4 still appears in the latest Mesa version, I'm trying to
> build Mesa myself and run my application with that. Unfortunately I'm
> having no success with either 19.3.2 (the version distributed with
> raspbian), 20.3.2 (the latest release) or the current master. Each time
> the driver initialization fails with the following messages printed to
> the console:
>
> libGL error: failed to create dri screen
> libGL error: failed to load driver: vc4
>
> This is my meson setup command line:
>
> ~/Downloads/meson-0.56.0/meson.py setup -Ddri-drivers=
> -Dgallium-drivers=v3d,vc4 -Dvulkan-drivers= -Dplatforms=x11
> -Dbuildtype=debug -Dbackend=ninja -Dprefix=/home/pi/mesa-build build
>
> (vc4 seems to be required in the gallium-drivers option, otherwise it
> failed with 'libGL error: MESA-LOADER: failed to open vc4 [...]'. I
> guess this makes sense given the dependency on vc4 as explained here
> https://docs.mesa3d.org/drivers/v3d.html ?)
>
> I'm having this issue using both SDL or freeglut and either starting the
> app from ssh (using 'export DISPLAY=:0') or directly on the desktop.
>
> I'm a total beginner when it comes to Mesa and the pi graphics driver
> stack, so any help would be highly appreciated :) Thanks!
>
> Lukas
> ___
> 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] [MR] Update README to recommend MRs instead of `git send-email`

[Ernst Sjöstrand]

git send-email with a gmail account is quite messy IMHO, I'd much
rather do a pull request.

Regards
//Ernst

Den mån 8 juli 2019 kl 15:32 skrev Eric Engestrom :
>
> On Saturday, 2019-07-06 13:39:16 -0400, Ilia Mirkin wrote:
> > I see this as driving away contributions, esp from new people. MR's
> > are annoying to create, since they require dealing with the hosting
> > provider, getting it to host clones, etc. Everyone has email.
>
> MRs have a one-time cost of having to create an account and forking the
> repo, I agree, although I really don't understand why a couple of you
> guys consider that cost so high...
>
> Anyway, we're not talking about preventing people from sending patches
> via email, or even just telling people not to do that, we are simply
> updating the recommendation for people who don't know where to start.
>
> As for "driving away contributions", we have noticed the exact opposite,
> which is exactly what we expected since that's what everyone else had
> been reporting as well: web interfaces instead of email make it much
> *easier* for new people to submit patches, which translated into many
> new people sending patches since we enabled MRs.
>
> On the technical side, MRs also allow things like the pre-merge CI to
> make sure we don't accidentally break the build for other people, and
> that alone is enough for many of us to want to eventually not let anyone
> push anything that hasn't gone through that CI, so while this is *not*
> what we're talking about here, let's be clear that it's the end-goal for
> many of us.
>
> >
> > Cheers,
> >
> >   -ilia
> >
> > On Sat, Jul 6, 2019 at 7:41 AM Eric Engestrom  wrote:
> > >
> > > Hi,
> > >
> > > I sent an MR to update the README, but as pointed out there I should
> > > make sure people who don't look at MRs are also aware of it, so here is:
> > >
> > > https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1223
> > >
> > > ---8<---
> > > diff --git a/README.rst b/README.rst
> > > index 4ccd72eca38a0845571c..eba097e652edde48a735 100644
> > > --- a/README.rst
> > > +++ b/README.rst
> > > @@ -56,5 +56,6 @@ Contributions are welcome, and step-by-step 
> > > instructions can be found in our
> > >  documentation (`docs/submittingpatches.html
> > >  `_).
> > >
> > > -Note that Mesa uses email mailing-lists for patches submission, review 
> > > and
> > > -discussions.
> > > +We recommend using GitLab Merge Requests (MRs) for patch submission and
> > > +review, and email mailing-lists for discussions, but the old `git 
> > > send-email`
> > > +method is still accepted.
> > > --->8---
> > > ___
> > > 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 mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] meson: upgrade minimum meson version

[Ernst Sjöstrand]

For people building newer Mesa pip3 install --user meson is quite a
lot better and more accessible.
Not a solutions for distributions that want to backport newer Mesa etc though.

Those build dependencies look more like runtime dependencies btw,
Meson is just pure python right?

Regards
//Ernst

Den tis 9 apr. 2019 kl 13:00 skrev Eero Tamminen :
>
> Hi,
>
> On 9.4.2019 0.22, Dylan Baker wrote:
> > It would be nice if people wouldn't try to build bleeding edge mesa on a 12 
> > year
> > old distro :D. Unfortunately as Eero ppoints out they do. I'd like to bump 
> > the
> > meson version to 0.47 in the future for some of the other features it adds
> > (automatically figuring out the dependencies for pkg-config, feature 
> > options,
> > etc), but that'll have to wait a bit for distros to catch up.
>
> Currently at least Meson 0.45 is required, which I think to rule out any
> 12 year old distros :D.  Requiring Meson 0.47 would rule out 2 year old
> distro releases.
>
> If somebody can test latest stable distros to see they work if one just
> takes newer Meson binary package from newer version of the distro, maybe
> Mesa could add instruction for users to do that?
>
> In Ubuntu 18.04 those instructions would be:
> - replace "bionic" in /etc/apt/sources.list temporarily with "cosmic"
> - do "sudo apt update && sudo apt install meson"
> - revert /etc/apt/sources.list back to bionic
>
> In Debian stable/stretch (which has Meson v0.37):
> - enable "stretch-backports" repo to install Meson (v0.49)
>
>
> - Eero
>
> PS. reason why I say Meson binary packages from newer distro version
> need to work is that I think expecting users to build also new Meson
> version from source is not realistic as it seems to need huge amount
> of esoteric build dependencies:
> https://packages.ubuntu.com/source/cosmic/meson
>
> > We've actually talked about removing these deprecation warnings in cases 
> > where
> > the minimum version doesn't have the recommended replacement, but that's 
> > hard.
> >
> > Dylan
> >
> > Quoting Eero Tamminen (2019-04-08 04:16:49)
> >> Hi,
> >>
> >> On 6.4.2019 11.44, Khaled Emara wrote:
> >>> Sorry, I though LTS distros used old versions of mesa.
> >>> Got it.
> >>
> >> Those *provide* older Mesa version, so naturally people want to build
> >> latest Mesa on them (especially if they've just bought HW that isn't
> >> supported by distro version of Mesa).  Building would fail if Mesa would
> >> require newer Meson version than the one in the distro.
> >>
> >>
> >>  - Eero
> >>
> >> PS. On Ubuntu 18.04 LTS, one can install 0.47 Meson binary package
> >> from 18.10, it works fine.  Maybe something similar can be done also
> >> on other LTS distros.
> >>
> >>> On Sat, Apr 6, 2019 at 12:38 AM Dylan Baker  >>> > wrote:
> >>>
> >>>  Quoting Khaled Emara (2019-04-05 11:28:28)
> >>>   > Upgraded meson's minimum version from 0.45 to 0.47
> >>>   > Version 0.47 is required to use build_always_stale
> >>>   > ---
> >>>   >  meson.build | 2 +-
> >>>   >  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>   >
> >>>   > diff --git a/meson.build b/meson.build
> >>>   > index 2c98e9e18a9..454928e244a 100644
> >>>   > --- a/meson.build
> >>>   > +++ b/meson.build
> >>>   > @@ -25,7 +25,7 @@ project(
> >>>   >  [find_program('python', 'python2', 'python3'),
> >>>  'bin/meson_get_version.py']
> >>>   >).stdout(),
> >>>   >license : 'MIT',
> >>>   > -  meson_version : '>= 0.45',
> >>>   > +  meson_version : '>= 0.47',
> >>>   >default_options : ['buildtype=debugoptimized',
> >>>  'b_ndebug=if-release', 'c_std=c99', 'cpp_std=c++11']
> >>>   >  )
> >>>   >
> >>>   > --
> >>>   > 2.21.0
> >>>   >
> >>>   > ___
> >>>   > mesa-dev mailing list
> >>>   > mesa-dev@lists.freedesktop.org
> >>>  
> >>>   > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> >>>
> >>>  Unfortunately we can't bump the minimum version at the moment, there
> >>>  are a
> >>>  couple of LTS distros we need support for that only ship 0.45.x
> >>>  currently. As an
> >>>  upstream meson dev, we have no time table in place for the removal of
> >>>  build_always.
> >>>
> >>>  Dylan
> >>>
> >>>
> >>> ___
> >>> 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 mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] vl/dri3: remove the wait before getting back buffer

[Ernst Sjöstrand]

What's the expected change in behavior? Does it fix any bugs?

Regards
//Ernst

Den ons 20 mars 2019 kl 16:42 skrev Liu, Leo :
>
> The wait here is unnecessary since we got a pool of back buffers,
> and the wait for swap buffer will happen before the present pixmap,
> at the same time the previous back buffer will be put back to pool
> for reuse after the check for PresentIdleNotify event
>
> Signed-off-by: Leo Liu 
> ---
>  src/gallium/auxiliary/vl/vl_winsys_dri3.c | 18 +++---
>  1 file changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/src/gallium/auxiliary/vl/vl_winsys_dri3.c 
> b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> index 152d28e59fc..1558d832555 100644
> --- a/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> +++ b/src/gallium/auxiliary/vl/vl_winsys_dri3.c
> @@ -88,7 +88,6 @@ struct vl_dri3_screen
> uint64_t send_sbc, recv_sbc;
> int64_t last_ust, ns_frame, last_msc, next_msc;
>
> -   bool flushed;
> bool is_different_gpu;
>  };
>
> @@ -570,11 +569,9 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
> if (!back)
> return;
>
> -   if (scrn->flushed) {
> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
> - if (!dri3_wait_present_events(scrn))
> -return;
> -   }
> +   while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
> +  if (!dri3_wait_present_events(scrn))
> + return;
>
> rectangle.x = 0;
> rectangle.y = 0;
> @@ -610,8 +607,6 @@ vl_dri3_flush_frontbuffer(struct pipe_screen *screen,
>
> xcb_flush(scrn->conn);
>
> -   scrn->flushed = true;
> -
> return;
>  }
>
> @@ -626,13 +621,6 @@ vl_dri3_screen_texture_from_drawable(struct vl_screen 
> *vscreen, void *drawable)
> if (!dri3_set_drawable(scrn, (Drawable)drawable))
>return NULL;
>
> -   if (scrn->flushed) {
> -  while (scrn->special_event && scrn->recv_sbc < scrn->send_sbc)
> - if (!dri3_wait_present_events(scrn))
> -return NULL;
> -   }
> -   scrn->flushed = false;
> -
> buffer = (scrn->is_pixmap) ?
>  dri3_get_front_buffer(scrn) :
>  dri3_get_back_buffer(scrn);
> --
> 2.17.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] [ANNOUNCE] mesa 18.0.0-rc4

[Ernst Sjöstrand]

Is there a lot of new patches queued up before the 18.0 release? In
that case you could push them to a branch (before tagging)
and it could be given a quick pre-test... Not sure how that ties in
the with current release process.

Regards
//Ernst

2018-02-09 3:27 GMT+01:00 Emil Velikov :
> The fourth release candidate for Mesa 18.0.0 is now available.
>
>
> Andres Gomez (1):
>   i965: perform 2 uploads with dual slot *64*PASSTHRU formats on gen<8
>
> Bas Nieuwenhuizen (1):
>   radv: Signal fence correctly after sparse binding.
>
> Dave Airlie (4):
>   r600/eg: construct proper rat mask for image/buffers.
>   r600/sb: insert the else clause when we might depart from a loop
>   radv/gfx9: fix block compression texture views. (v2)
>   virgl: also remove dimension on indirect.
>
> Dylan Baker (2):
>   meson: Don't confuse the install and search paths for dri drivers
>   meson: Check for actual LLVM required versions
>
> Emil Velikov (3):
>   radv: Stop advertising VK_KHX_multiview
>   cherry-ignore: radv: Don't expose VK_KHX_multiview on android.
>   Update version to 18.0.0-rc4
>
> Eric Anholt (1):
>   mesa: Drop incorrect A4B4G4R4
> _mesa_format_matches_format_and_type() cases.
>
> George Kyriazis (2):
>   meson/swr: re-shuffle generated files
>   meson/swr: Updated copyright dates
>
> Jason Ekstrand (3):
>   anv/cmd_buffer: Re-emit the pipeline at every subpass
>   anv: Stop advertising VK_KHX_multiview
>   i965: Call prepare_external after implicit window-system MSAA resolves
>
> Jon Turney (9):
>   meson: libdrm shouldn't appear in Requires.private: if it wasn't found
>   configure: Default to gbm=no on osx
>   osx: ld doesn't support --build-id
>   glx/apple: include util/debug.h for env_var_as_boolean prototype
>   glx/apple: locate dispatch table functions to wrap by name
>   glx/test: fix building for osx
>   travis: conditionalize building of prerequisites on if OS=linux
>   travis: pip -> pip2
>   travis: add osx autotools build
>
> Jordan Justen (1):
>   i965: Create new program cache bo when clearing the program cache
>
> Kenneth Graunke (1):
>   i965: Bump official kernel requirement to Linux v3.9.
>
> Lucas Stach (1):
>   renderonly: fix dumb BO allocation for non 32bpp formats
>
> Marc Dietrich (1):
>   meson: don't install windows headers on non-windows platforms
>
> Marek Olšák (1):
>   winsys/amdgpu: fix assertion failure with UVD and VCE rings
>
> Matthew Nicholls (1):
>   radv: remove predication on cache flushes
>
> Michel Dänzer (1):
>   winsys/radeon: Compute is_displayable in surf_drm_to_winsys
>
> Rafael Antognolli (2):
>   anv/gen10: Emit CS stall and mark push constants dirty.
>   i965/gen10: Use CS Stall instead of WriteImmediate.
>
> Roland Scheidegger (1):
>   r600: don't do stack workarounds for hemlock
>
> Stephan Gerhold (1):
>   util/build-id: Fix address comparison for binaries with LOAD vaddr > 0
>
> Tapani Pälli (3):
>   i965: fix prog_data leak in brw_disk_cache
>   i965: fix disk_cache leak when destroying context
>   nir: mark unused space in packed_tex_data
>
> Timothy Arceri (1):
>   st/shader_cache: restore num_tgsi_tokens when loading from cache
>
> git tag: mesa-18.0.0-rc4
>
> https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.gz
> MD5:  b09a18dd7a0ab9c3f55a820b5a25  mesa-18.0.0-rc4.tar.gz
> SHA1: b0785f1b2328e3d68a5e01cc00663301bb0829c2  mesa-18.0.0-rc4.tar.gz
> SHA256: e5d038a58221fe9c62b3f784df67210e87df81559032cfee7648d51bdce3a356
>  mesa-18.0.0-rc4.tar.gz
> SHA512: 
> e7d7898ab8b4788adaf34d7eb924f893314acd2dbf4970d71ecfa8e44b8662e1e924db97365ddb7b8fc3bd0744ba82dd1942439582cb685b54e86f00f8e51310
>  mesa-18.0.0-rc4.tar.gz
> PGP:  https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.gz.sig
>
> https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.xz
> MD5:  195889b71ee88785d55b03d99e0034d3  mesa-18.0.0-rc4.tar.xz
> SHA1: ea24546b10f1a089c25c992d01083d7eb005ec44  mesa-18.0.0-rc4.tar.xz
> SHA256: ad575becea192f04403b6783492955f395dd8faad7e51cbcbad203be70eb9075
>  mesa-18.0.0-rc4.tar.xz
> SHA512: 
> 91dd0a4396715a7896fc47aabf38c4b486df3b50c9764795805550ef01724d2e2281ba9b000e82760ea0e199c58d8c9943dbc732b2adab46554ff5c2f9e2ece1
>  mesa-18.0.0-rc4.tar.xz
> PGP:  https://mesa.freedesktop.org/archive/mesa-18.0.0-rc4.tar.xz.sig
> ___
> 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/8] radeonsi: mask out high VM address bits in registers where needed

[Ernst Sjöstrand]

I guess this fixes something since it's nominated for stable?
Could have a commit message with that.

Regards
//Ernst

2018-02-25 2:02 GMT+01:00 Marek Olšák :
> From: Marek Olšák 
>
> Cc: 17.3 18.0 
> ---
>  src/gallium/drivers/radeonsi/si_compute.c   |  4 ++--
>  src/gallium/drivers/radeonsi/si_state.c | 24 +---
>  src/gallium/drivers/radeonsi/si_state_shaders.c | 18 +-
>  3 files changed, 24 insertions(+), 22 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute.c 
> b/src/gallium/drivers/radeonsi/si_compute.c
> index 4192798..46873cc 100644
> --- a/src/gallium/drivers/radeonsi/si_compute.c
> +++ b/src/gallium/drivers/radeonsi/si_compute.c
> @@ -323,21 +323,21 @@ static void si_initialize_compute(struct si_context 
> *sctx)
> radeon_set_sh_reg(cs, R_00B82C_COMPUTE_MAX_WAVE_ID,
>   0x190 /* Default value */);
> }
>
> /* Set the pointer to border colors. */
> bc_va = sctx->border_color_buffer->gpu_address;
>
> if (sctx->b.chip_class >= CIK) {
> radeon_set_uconfig_reg_seq(cs, R_030E00_TA_CS_BC_BASE_ADDR, 
> 2);
> radeon_emit(cs, bc_va >> 8);  /* R_030E00_TA_CS_BC_BASE_ADDR 
> */
> -   radeon_emit(cs, bc_va >> 40); /* 
> R_030E04_TA_CS_BC_BASE_ADDR_HI */
> +   radeon_emit(cs, S_030E04_ADDRESS(bc_va >> 40)); /* 
> R_030E04_TA_CS_BC_BASE_ADDR_HI */
> } else {
> if (sctx->screen->info.drm_major == 3 ||
> (sctx->screen->info.drm_major == 2 &&
>  sctx->screen->info.drm_minor >= 48)) {
> radeon_set_config_reg(cs, R_00950C_TA_CS_BC_BASE_ADDR,
>   bc_va >> 8);
> }
> }
>
> sctx->cs_shader_state.emitted_program = NULL;
> @@ -460,21 +460,21 @@ static bool si_switch_compute_shader(struct si_context 
> *sctx,
> /* Shader code is placed after the amd_kernel_code_t
>  * struct. */
> shader_va += sizeof(amd_kernel_code_t);
> }
>
> radeon_add_to_buffer_list(>b, >b.gfx, shader->bo,
>   RADEON_USAGE_READ, 
> RADEON_PRIO_SHADER_BINARY);
>
> radeon_set_sh_reg_seq(cs, R_00B830_COMPUTE_PGM_LO, 2);
> radeon_emit(cs, shader_va >> 8);
> -   radeon_emit(cs, shader_va >> 40);
> +   radeon_emit(cs, S_00B834_DATA(shader_va >> 40));
>
> radeon_set_sh_reg_seq(cs, R_00B848_COMPUTE_PGM_RSRC1, 2);
> radeon_emit(cs, config->rsrc1);
> radeon_emit(cs, config->rsrc2);
>
> COMPUTE_DBG(sctx->screen, "COMPUTE_PGM_RSRC1: 0x%08x "
> "COMPUTE_PGM_RSRC2: 0x%08x\n", config->rsrc1, config->rsrc2);
>
> radeon_set_sh_reg(cs, R_00B860_COMPUTE_TMPRING_SIZE,
>   S_00B860_WAVES(sctx->scratch_waves)
> diff --git a/src/gallium/drivers/radeonsi/si_state.c 
> b/src/gallium/drivers/radeonsi/si_state.c
> index a6ec427..6c82257 100644
> --- a/src/gallium/drivers/radeonsi/si_state.c
> +++ b/src/gallium/drivers/radeonsi/si_state.c
> @@ -3039,34 +3039,34 @@ static void si_emit_framebuffer_state(struct 
> si_context *sctx, struct r600_atom
> cb_color_base |= tex->surface.tile_swizzle;
> if (!tex->fmask.size)
> cb_color_fmask = cb_color_base;
> cb_color_attrib |= 
> S_028C74_COLOR_SW_MODE(tex->surface.u.gfx9.surf.swizzle_mode) |
>
> S_028C74_FMASK_SW_MODE(tex->surface.u.gfx9.fmask.swizzle_mode) |
>
> S_028C74_RB_ALIGNED(meta.rb_aligned) |
>
> S_028C74_PIPE_ALIGNED(meta.pipe_aligned);
>
> radeon_set_context_reg_seq(cs, 
> R_028C60_CB_COLOR0_BASE + i * 0x3C, 15);
> radeon_emit(cs, cb_color_base); /* 
> CB_COLOR0_BASE */
> -   radeon_emit(cs, cb_color_base >> 32);   /* 
> CB_COLOR0_BASE_EXT */
> +   radeon_emit(cs, S_028C64_BASE_256B(cb_color_base >> 
> 32)); /* CB_COLOR0_BASE_EXT */
> radeon_emit(cs, cb->cb_color_attrib2);  /* 
> CB_COLOR0_ATTRIB2 */
> radeon_emit(cs, cb->cb_color_view); /* 
> CB_COLOR0_VIEW */
> radeon_emit(cs, cb_color_info); /* 
> CB_COLOR0_INFO */
> radeon_emit(cs, cb_color_attrib);   /* 
> CB_COLOR0_ATTRIB */
> radeon_emit(cs, cb->cb_dcc_control);/* 
> CB_COLOR0_DCC_CONTROL */
> radeon_emit(cs, tex->cmask.base_address_reg); /* 
> CB_COLOR0_CMASK */
> -   radeon_emit(cs, tex->cmask.base_address_reg >> 32); 
> /* 

Re: [Mesa-dev] Meson's default build type

[Ernst Sjöstrand]

Hi,

I haven't seen anyone mention -Og in this thread yet:
"-Og enables optimizations that do not interfere with debugging."
Was added in GCC 4.8.

Regards
//Ernst

2017-11-06 13:25 GMT+01:00 Eero Tamminen :
> Hi,
>
> On 04.11.2017 03:28, Christian Schmidbauer wrote:
>>>
>>> On Thu, Nov 2, 2017 at 11:45 AM, Andres Rodriguez 
>>> wrote:
>
> [...]
>>>
>>> In the autotools system we have today, we have --enable-debug, which
>>> adds -g and -O0 if some -g* and -O* are not already in CFLAGS. It also
>>> adds -DDEBUG which turns on lots of debugging code that has extra
>>> runtime cost, like nir_validate. Without --enable-debug, we pass
>>> -DNDEBUG to disable assertions, and otherwise use autotools' default
>>> CFLAGS (-g -O2) or whatever the user specified.
>>>
>>> Meson's debug build should correspond to --enable-debug.
>>> debugoptimized vs release is a little less obvious. Perhaps
>>> debugoptimized should default to -g -O2 but leave assertions enabled,
>>> and release should default to -g -O2 -DNDEBUG?
>>>
>>> Under that system, I agree that the default build type should be
>>> debugoptimized.
>>
>>
>> Does this mean that it is not easily possible to keep asserations in
>> general but remove heavy extra runtime cost (like nir_validate)?
>>
>> FWIW, it would be great if there would be a "debugoptimized" which
>> tries to keep the overhead minimal and still allow debugging in a
>> sensible, but not complete, way.
>
>
> I'd like that too.
>
>
> - Eero
>
>
> ___
> 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 14/16] ac: use amdgpu-flat-work-group-size

[Ernst Sjöstrand]

Isn't the logic inverted here?

2017-10-13 14:04 GMT+02:00 Marek Olšák :
> From: Marek Olšák 
>
> the old one is being deprecated or removed
> ---
>  src/amd/common/ac_nir_to_llvm.c  | 3 ++-
>  src/gallium/drivers/radeonsi/si_shader.c | 4 +++-
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/src/amd/common/ac_nir_to_llvm.c b/src/amd/common/ac_nir_to_llvm.c
> index 11ba487..4492d8e 100644
> --- a/src/amd/common/ac_nir_to_llvm.c
> +++ b/src/amd/common/ac_nir_to_llvm.c
> @@ -346,21 +346,22 @@ create_llvm_function(LLVMContextRef ctx, LLVMModuleRef 
> module,
> ac_add_function_attr(ctx, main_function, i + 1, 
> AC_FUNC_ATTR_BYVAL);
> ac_add_attr_dereferenceable(P, UINT64_MAX);
> }
> else {
> ac_add_function_attr(ctx, main_function, i + 1, 
> AC_FUNC_ATTR_INREG);
> }
> }
>
> if (max_workgroup_size) {
> ac_llvm_add_target_dep_function_attr(main_function,
> -
> "amdgpu-max-work-group-size",
> +HAVE_LLVM >= 0x0400 ? 
> "amdgpu-max-work-group-size" :
> +  
> "amdgpu-flat-work-group-size",
>  max_workgroup_size);
> }
> if (unsafe_math) {
> /* These were copied from some LLVM test. */
> LLVMAddTargetDependentFunctionAttr(main_function,
>"less-precise-fpmad",
>"true");
> LLVMAddTargetDependentFunctionAttr(main_function,
>"no-infs-fp-math",
>"true");
> diff --git a/src/gallium/drivers/radeonsi/si_shader.c 
> b/src/gallium/drivers/radeonsi/si_shader.c
> index ff372ae..506da6f 100644
> --- a/src/gallium/drivers/radeonsi/si_shader.c
> +++ b/src/gallium/drivers/radeonsi/si_shader.c
> @@ -4155,21 +4155,23 @@ static void si_create_function(struct 
> si_shader_context *ctx,
> } else
> lp_add_function_attr(ctx->main_fn, i + 1, 
> LP_FUNC_ATTR_INREG);
> }
>
> for (i = 0; i < fninfo->num_params; ++i) {
> if (fninfo->assign[i])
> *fninfo->assign[i] = LLVMGetParam(ctx->main_fn, i);
> }
>
> if (max_workgroup_size) {
> -   si_llvm_add_attribute(ctx->main_fn, 
> "amdgpu-max-work-group-size",
> +   si_llvm_add_attribute(ctx->main_fn,
> + HAVE_LLVM >= 0x0400 ? 
> "amdgpu-max-work-group-size" :
> +   
> "amdgpu-flat-work-group-size",
>   max_workgroup_size);
> }
> LLVMAddTargetDependentFunctionAttr(ctx->main_fn,
>"no-signed-zeros-fp-math",
>"true");
>
> if (ctx->screen->b.debug_flags & DBG(UNSAFE_MATH)) {
> /* These were copied from some LLVM test. */
> LLVMAddTargetDependentFunctionAttr(ctx->main_fn,
>"less-precise-fpmad",
> --
> 2.7.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 00/31] Mesa: Moving from _NEW flags to NewDriverState

[Ernst Sjöstrand]

Hi,

does GfxBench v4 work on RadeonSI at all?

Regards
//Ernst

2017-06-13 16:50 GMT+02:00 Eero Tamminen :
> Hi,
>
> On 13.06.2017 16:23, Marek Olšák wrote:
>>
>> On Tue, Jun 13, 2017 at 3:24 PM, Eero Tamminen
>>  wrote:
>>>
>>> On 13.06.2017 12:56, Marek Olšák wrote:

 Everything is here:

 git://people.freedesktop.org/~mareko/mesa state-optz
>>>
>>>
>>>
>>> Didn't see any changes in benchmark suites that had tests which are
>>> partially CPU bound.  Everything was within variation on BYT, BSW, BDW,
>>> BXT
>>> & SKL.
>>
>>
>> Note that this series only affects st/mesa. It has no effect on i965.
>
>
> It had some changes also in mesa/main/ and i965, so I though best to check
> it.
>
> I'm interested to hear whether it Driver2 performance for st/mesa. :-)
>
>
> - Eero
>
>
> ___
> 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] [RFC PATCH 1/1] st/dri: add a new driconf option override_glsl_version for ARK games

[Ernst Sjöstrand]

Are you sure? I still need the workaround, otherwise the game hangs
very quickly.

2017-03-15 15:13 GMT+01:00 Samuel Pitoiset :
> Quick update: The issue has been fixed since v255.2 (Survival Evolved only).
> I will ask for the "Survival Of The Fittest" because it still fails to
> start.
>
> On 02/06/2017 04:04 PM, Eero Tamminen wrote:
>>
>> Hi,
>> On 03.02.2017 19:23, Samuel Pitoiset wrote:
>>>
>>> This is similar to the MESA_GLSL_VERSION_OVERRIDE envvar (mainly
>>> for developers). But this one has the advantage to be configured
>>> for specific apps which require a context with an explicit version.
>>>
>>> For example, when an app requires a 3.2 core context, RadeonSI
>>> will return a 4.5 context but this might fail (eg. ARK games).
>>>
>>> No need to add both "ARK: Survival Evolved" and "ARK: Survival
>>> Of The Fittest" because the executable name is the same.
>>
>>
>> Those games use Unreal Engine v4 and "ShooterGame" is the binary name
>> for one of the demos included in UE v4 SDK:
>> https://wiki.unrealengine.com/Linux_Demos
>>
>> If ARK developers couldn't be bothered to change the name of their
>> binary before release, maybe other game developers don't/haven't either.
>>  I.e. I'm not sure it's unique enough.
>>
>>
>> -> Safer to have an option that just tells Mesa to use context version
>> that the application requested (if Mesa supports that on given HW).
>>
>>
>> - Eero
>>
>>> Signed-off-by: Samuel Pitoiset 
>>> ---
>>>  src/gallium/include/state_tracker/st_api.h  | 1 +
>>>  src/gallium/state_trackers/dri/dri_screen.c | 3 +++
>>>  src/gallium/state_trackers/osmesa/osmesa.c  | 1 +
>>>  src/mesa/drivers/dri/common/drirc   | 4 
>>>  src/mesa/drivers/dri/common/xmlpool/t_options.h | 5 +
>>>  src/mesa/drivers/dri/i965/brw_context.c | 3 +++
>>>  src/mesa/state_tracker/st_extensions.c  | 3 +++
>>>  7 files changed, 20 insertions(+)
>>>
>>> diff --git a/src/gallium/include/state_tracker/st_api.h
>>> b/src/gallium/include/state_tracker/st_api.h
>>> index a2e37d2e48..e0a73d74ad 100644
>>> --- a/src/gallium/include/state_tracker/st_api.h
>>> +++ b/src/gallium/include/state_tracker/st_api.h
>>> @@ -246,6 +246,7 @@ struct st_config_options
>>> boolean force_s3tc_enable;
>>> boolean allow_glsl_extension_directive_midshader;
>>> boolean glsl_zero_init;
>>> +   unsigned override_glsl_version;
>>>  };
>>>
>>>  /**
>>> diff --git a/src/gallium/state_trackers/dri/dri_screen.c
>>> b/src/gallium/state_trackers/dri/dri_screen.c
>>> index a950f5241d..a1fa0a3be3 100644
>>> --- a/src/gallium/state_trackers/dri/dri_screen.c
>>> +++ b/src/gallium/state_trackers/dri/dri_screen.c
>>> @@ -70,6 +70,7 @@ const __DRIconfigOptionsExtension
>>> gallium_config_options = {
>>>   DRI_CONF_DISABLE_SHADER_BIT_ENCODING("false")
>>>   DRI_CONF_FORCE_GLSL_VERSION(0)
>>>   DRI_CONF_ALLOW_GLSL_EXTENSION_DIRECTIVE_MIDSHADER("false")
>>> + DRI_CONF_OVERRIDE_GLSL_VERSION(0)
>>>DRI_CONF_SECTION_END
>>>
>>>DRI_CONF_SECTION_MISCELLANEOUS
>>> @@ -100,6 +101,8 @@ dri_fill_st_options(struct st_config_options
>>> *options,
>>> options->allow_glsl_extension_directive_midshader =
>>>driQueryOptionb(optionCache,
>>> "allow_glsl_extension_directive_midshader");
>>> options->glsl_zero_init = driQueryOptionb(optionCache,
>>> "glsl_zero_init");
>>> +   options->override_glsl_version =
>>> +  driQueryOptioni(optionCache, "override_glsl_version");
>>>  }
>>>
>>>  static const __DRIconfig **
>>> diff --git a/src/gallium/state_trackers/osmesa/osmesa.c
>>> b/src/gallium/state_trackers/osmesa/osmesa.c
>>> index 18f1b88128..8102be14ed 100644
>>> --- a/src/gallium/state_trackers/osmesa/osmesa.c
>>> +++ b/src/gallium/state_trackers/osmesa/osmesa.c
>>> @@ -679,6 +679,7 @@ OSMesaCreateContextAttribs(const int *attribList,
>>> OSMesaContext sharelist)
>>> attribs.options.disable_shader_bit_encoding = FALSE;
>>> attribs.options.force_s3tc_enable = FALSE;
>>> attribs.options.force_glsl_version = 0;
>>> +   attribs.options.override_glsl_version = 0;
>>>
>>> osmesa_init_st_visual(,
>>>   PIPE_FORMAT_R8G8B8A8_UNORM,
>>> diff --git a/src/mesa/drivers/dri/common/drirc
>>> b/src/mesa/drivers/dri/common/drirc
>>> index 20fd8123e4..52c121a064 100644
>>> --- a/src/mesa/drivers/dri/common/drirc
>>> +++ b/src/mesa/drivers/dri/common/drirc
>>> @@ -104,5 +104,9 @@ TODO: document the other workarounds.
>>>  >> executable="EoCApp">
>>>  >> value="true" />
>>>  
>>> +
>>> +>> executable="ShooterGame">
>>> +
>>> +
>>>  
>>>  
>>> diff --git a/src/mesa/drivers/dri/common/xmlpool/t_options.h
>>> b/src/mesa/drivers/dri/common/xmlpool/t_options.h
>>> index a189bbedec..fb9ecbe3e7 100644
>>> --- a/src/mesa/drivers/dri/common/xmlpool/t_options.h
>>> +++ b/src/mesa/drivers/dri/common/xmlpool/t_options.h

Re: [Mesa-dev] [PATCH 1/2] radeonsi: add support for an on-disk shader cache

[Ernst Sjöstrand]

Notice that git worries about collisions between the 7 char abbreviated
sha1s in large repositories, and sometime have to use 10 or 12 chars, etc:
https://github.com/blog/2288-git-2-11-has-been-released

"This is exactly what happened in the Linux kernel repository; it now has
over 5 million objects, meaning we'd expect collisions with names shorter
than 12 hexadecimal characters."

I think that speaks for itself.

Also, SHA1 is very good at generating a completely different hash for small
changes. So to generate a collision with X, you can't have X +/- a few
bytes.

Regards
//Ernst


2017-02-27 13:20 GMT+01:00 Marek Olšák :

> On Mon, Feb 27, 2017 at 10:57 AM, Michel Dänzer 
> wrote:
> > On 25/02/17 01:56 PM, Timothy Arceri wrote:
> >> On 24/02/17 21:02, Marek Olšák wrote:
> >>> On Fri, Feb 24, 2017 at 3:18 AM, Timothy Arceri
> >>>  wrote:
>  On 24/02/17 08:49, Timothy Arceri wrote:
> > On 24/02/17 05:12, Marek Olšák wrote:
> >> On Thu, Feb 23, 2017 at 3:09 AM, Timothy Arceri
> >>  wrote:
> >>>
> >>> From: kdj0c 
> >>>
> >>> V2 (Timothy Arceri):
> >>> - when loading from disk cache also binary insert into memory
> cache.
> >>> - check that the binary loaded from disk is the correct size. If
> not
> >>>   delete the cache item and skip loading from cache.
> >>> ---
> >>>  src/gallium/drivers/radeonsi/si_state_shaders.c | 69
> >>> ++---
> >>>  1 file changed, 62 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/src/gallium/drivers/radeonsi/si_state_shaders.c
> >>> b/src/gallium/drivers/radeonsi/si_state_shaders.c
> >>> index f615aa8..71556f9 100644
> >>> --- a/src/gallium/drivers/radeonsi/si_state_shaders.c
> >>> +++ b/src/gallium/drivers/radeonsi/si_state_shaders.c
> >>> @@ -36,6 +36,9 @@
> >>>  #include "util/u_memory.h"
> >>>  #include "util/u_prim.h"
> >>>
> >>> +#include "util/disk_cache.h"
> >>> +#include "util/mesa-sha1.h"
> >>> +
> >>>  /* SHADER_CACHE */
> >>>
> >>>  /**
> >>> @@ -182,10 +185,12 @@ static bool si_load_shader_binary(struct
> >>> si_shader *shader, void *binary)
> >>>   */
> >>>  static bool si_shader_cache_insert_shader(struct si_screen
> *sscreen,
> >>>   void *tgsi_binary,
> >>> - struct si_shader *shader)
> >>> + struct si_shader *shader,
> >>> + bool
> >>> insert_into_disk_cache)
> >>>  {
> >>> void *hw_binary;
> >>> struct hash_entry *entry;
> >>> +   uint8_t key[CACHE_KEY_SIZE];
> >>>
> >>> entry = _mesa_hash_table_search(sscreen->shader_cache,
> >>> tgsi_binary);
> >>> if (entry)
> >>> @@ -201,6 +206,12 @@ static bool si_shader_cache_insert_shader(
> struct
> >>> si_screen *sscreen,
> >>> return false;
> >>> }
> >>>
> >>> +   if (sscreen->b.disk_shader_cache &&
> insert_into_disk_cache) {
> >>> +   _mesa_sha1_compute(tgsi_binary, *((uint32_t
> >>> *)tgsi_binary), key);
> >>
> >>
> >> What happens if we randomly get a sha1 collision?
> >
> >
> > You should stop playing your game which will be rendering incorrectly
> > and by a lotto ticket.
> >
> >> Shouldn't we store the whole key as well?
> >
> >
> > Sure I can add that, its cheap to check here anyway. Although the
> other
> > cache stages rely on a collision being improbable.
> 
> 
> 
>  For some reason I thought the key was simpler than it is. It seems
>  excessive
>  to store and compare the tgsi again. I don't think git even worries
>  about
>  the possibility of a collision and we will be dealing with much
> smaller
>  amounts of cache items then commits in a git repository.
> 
>  Thoughts?
> >>>
> >>> I'll let others comment on this. If nobody comments, checking only the
> >>> key can stay.
> >>
> >> Seems SVN didn't used to worry about collisions either.
> >>
> >> https://arstechnica.com/security/2017/02/watershed-
> sha1-collision-just-broke-the-webkit-repository-others-may-follow/
> >
> > What scenario are we concerned about here? Getting a genuine SHA1
> > collision between two shader objects is still as unlikely as it ever was
> > (virtually impossible?), and someone with access to the shader cache
> > files can wreak havoc much more easily than via a hash collision.
>
> I'm concerned about the random scenario where 2 shaders can have the
> same hash. That is, if the user doesn't do anything wrong and nobody
> else corrupts the cache, can we say for sure that a collision will
> never ever happen?
>
> The patch can land as-is, but the topic is 

Re: [Mesa-dev] [RFC] spec: MESA_program_binary

[Ernst Sjöstrand]

Also, what if the user switches between say AMDGPU-PRO and RadeonSI?

Regards
//Ernst

2017-02-17 1:33 GMT+01:00 Timothy Arceri :

>
>
> On 17/02/17 10:44, Ian Romanick wrote:
>
>> On 02/15/2017 11:58 PM, Timothy Arceri wrote:
>>
>>>
>>>
>>> On 16/02/17 17:55, Tapani Pälli wrote:
>>>

 On 02/16/2017 04:52 AM, Timothy Arceri wrote:

> In order add functionality to ARB_get_program_binary we need
> binary format enums.
>

 I've understood that this is a driver internal enumeration. When
 application gets the binary it also receives enum (integer value) what
 format we gave. Then when loading application needs to query what
 formats are supported by the implementation and load the correct binary.
 We just need to internally make agreement on format list and return
 correct one matching the current driver in use?

>>>
>>> Not that it's actually likely to happen but if we were to only have a
>>> single MESA enum an application could only distribute a single binary.
>>>
>>
>> Applications really, really, *REALLY* should not distribute binaries
>> retrieved from the driver.  The intention of this extension is for
>> applications to implement their own shader cache, for example, at
>> application installation.  The driver can reject the binary at any time
>> for any reason.  Driver changes, hardware changes, OS changes, phase of
>> the moon, etc.
>>
>> Looking at the GLES extension registry, it appears that the other
>> vendors have just a single binary for all the hardware they make.  Based
>> on that, having a single Mesa enum isn't an insane idea.  We would just
>> need to agree on the format of the header so that the driver receiving
>> the blob could determine which driver generated the blob.
>>
>
> The only other thing to consider with a single enum is that it will
> require a laptop with an Intel cpu and Nvidia gpu for example to recompile
> the binary if the user were to switch between using the Intel and Nvidia
> gpus. This might happen depending on if the laptop is plugged into a power
> source or not.
>
> If we don't care about this than one enum is fine.
>
>
>
>> e.g either for AMD, INTEL or NVIDIA but not one for each. That is unless
>>> we were to compile and pack all gpu vendor binarys at the same time
>>> which seems overly complicated and expensive.
>>>
>>> I could see an intenal id being used for gpu generations from hardware
>>> vendors.
>>>
>>> ---
>
> Techland games such as Dead Island and Dying Light make use of
> GetProgramBinary(). My current guess is the Dead Island crash
> https://bugs.freedesktop.org/show_bug.cgi?id=85564 is caused
> due to buggy handling of this feature not being available.
>
> Anyway I'm not sure how we go about getting Khronos to assign
> enums for the binary formats but thought I'd send this to the
> list for discussion.
>

>> There's a two step process:
>>
>> 1. Vendors request a block of values via the Khronos internal bugzilla.
>>
>> 2. When the spec is ready, another bug is submitted requesting the spec
>> be published.
>>
>> Mesa might still have some available enums assigned to it.  I'll have to
>> check...
>>
>>  docs/specs/MESA_program_binary.txt | 78
> ++
>  1 file changed, 78 insertions(+)
>  create mode 100644 docs/specs/MESA_program_binary.txt
>
> diff --git a/docs/specs/MESA_program_binary.txt
> b/docs/specs/MESA_program_binary.txt
> new file mode 100644
> index 000..b34e42e
> --- /dev/null
> +++ b/docs/specs/MESA_program_binary.txt
> @@ -0,0 +1,78 @@
> +Name
> +
> +MESA_program_binary
> +
> +Name Strings
> +
> +GL_MESA_program_binary
> +
> +Contact
> +
> +Timothy Arceri (tarceri 'at' itsqueeze.com)
> +
> +Status
> +
> +Complete.
> +
> +Version
> +
> +Last Modified Date: February 16, 2017
> +Revision: #1
> +
> +Number
> +
> +???
> +
> +Dependencies
> +
> +OpenGL ES 2.0 is required.
> +
> +Written based on the wording of the OpenGL ES 2.0 specification.
> +
> +This extension interacts with OES_get_program_binary.
> +
> +Overview
> +
> +MESA provides drivers for multiple hardware vendors. This
> extension
> +provides binary formats in order to avoid conflicts between
> drivers when
> +loading precompiled binaries.
> +
> +New Procedures and Functions
> +
> +None.
> +
> +New Tokens
> +
> +Accepted by the  parameter of ShaderBinary:
> +
> +MESA_PROGRAM_BINARY_AMD
> +MESA_PROGRAM_BINARY_NV 
> +MESA_PROGRAM_BINARY_INTEL  
> +MESA_PROGRAM_BINARY_BCOM   
> +

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Ernst Sjöstrand]

2017-02-09 18:06 GMT+01:00 Eero Tamminen :

My personal feeling is that minimal merging criteria should be:
> * no known segfaults
>

I bet that glmark2 just does something that's not allowed. Mesa can't
prevent all application bugs? Seems like it has a very buggy history with
lots of segfaults in other situations also.

Regards
//Ernst
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Time to merge threaded GL dispatch? (aka glthread)

[Ernst Sjöstrand]

I benchmarked Total War: Attila and CS:GO quickly yesterday, both ran fine
but none of them seemed to gain any performance. Maybe lost a little.
I saw that Tomb Raider only had ~130% cpu usage on my system, perhaps
that's a candidate even though it's a Feral title? It's 32-bit though and I
couldn't bother to cross compile.

FYI I think glmark2 is a bit buggy: https://bugs.launchpad.net/glmark2
Tough it does run fine for me without threading right now...

Regards
//Ernst

2017-02-08 18:45 GMT+01:00 Marek Olšák :

> On Wed, Feb 8, 2017 at 6:29 PM, Eero Tamminen 
> wrote:
> > Hi,
> >
> > On 08.02.2017 15:10, Marek Olšák wrote:
> >>
> >> On Feb 8, 2017 11:15 AM, "Eero Tamminen"  >> If there are known crashes, and no piglit statistics, how you can
> >> trust that the games which the patch series seems to already help,
> >> actually do work?  That they don't crash or deadlock at some point
> >> because of it?
> >>
> >> I hate to repeat myself, but it was tested with quite a bunch of games.
> >> You know, I actually made it work for Gallium including bug fixes in
> >> glthread like bad locking and race conditions. I know Samuel Pitoiset
> >> also tested it with good results. A bunch of people on IRC tested it
> too.
> >
> >
> > Do you have some e.g. wiki page where this status info is collected?
> >
> >
> > So far the data provided in this thread is following:
> >
> > Improves performance:
> > * Borderlands 2 (with multiple game gfx settings & driver/HW?)
> >
> > Regresses performance:
> > * Shadow of Mordor (with multiple game gfx settings & driver/HW?)
> > * PCSX2 emulator
> >
> > Crashes:
> > * glmark2 (one test? all tests?  both GL & GLES version?)
> > * fgl_glxgears
> >
> >
> >> Concerning the glmark crash, I don't care. Get over it.
> >
> > Glmark & glxgears are rather simple, so it's just a bit surprising.
>
> I don't understand why any of this is important. Did you not notice
> that it's disabled by default and the implementation is not complete?
> I think I said it somewhere.
>
> Marek
> ___
> 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] Time to merge threaded GL dispatch? (aka glthread)

[Ernst Sjöstrand]

FYI glmark2 segfaults with mesa_glthread=true. Expected that some programs
will segfault?

ATTENTION: default value of option mesa_glthread overridden by environment.
[New Thread 0x7fffed73d700 (LWP 23060)]
_mesa_glthread_init
===
glmark2 2014.03
===
OpenGL Information
GL_VENDOR: X.Org
GL_RENDERER:   Gallium 0.4 on AMD FIJI (DRM 3.9.0 / 4.10.0-rc3+, LLVM
5.0.0)
GL_VERSION:3.0 Mesa 17.1.0-devel (git-c91d721)
===
[New Thread 0x7fffecf3c700 (LWP 23061)]
_mesa_glthread_init
_mesa_glthread_destroy
[Thread 0x7fffed73d700 (LWP 23060) exited]

Thread 1 "glmark2" received signal SIGSEGV, Segmentation fault.

Here's the backtrace:
http://pastebin.com/0FrM0Q0A

Regards
//Ernst


2017-02-06 1:11 GMT+01:00 Marek Olšák :

> Hi,
>
> Back in 2012-2013, then-Intel employees Eric Anholt and Paul Berry
> wrote this threaded GL dispatch where GL calls are queued and executed
> in a different thread. It was supposed to deal with high CPU overhead
> of Mesa, but at the time most games used the compatibility profile and
> Steam didn't really exist on Linux, so it didn't help many (if any)
> apps.
>
> Things are different today. We have Steam and most games use the GL
> core profile. We know of several games that have better performance
> with glthread, namely Borderlands 2, and some people reported to me
> that some other games also benefit. It's about time we put this into
> mainline Mesa.
>
> My plan is that we merge it as-is or with minor changes, and then
> we'll clean it up and improve it while it's in master. It's disabled
> by default, so it shouldn't bother anyone who doesn't want it. There
> is a drirc option to turn it on (just use the corresponding env var).
> All Gallium drivers support it.
>
> A note on synchronizations. Borderlands 2 has 170 thread syncs per
> frame. That means the app thread has to stop and wait 170x per frame.
> Despite that, it still has 70% higher performance in some cases. My
> theory is that if you have a lot of draw calls, you can have a lot of
> syncs, because the sheer amount of draw calls will just make those
> syncs irrelevant. 200 syncs per 4k draw calls is like 1 sync per 20
> draw calls.
>
> Here it is: https://cgit.freedesktop.org/~mareko/mesa/log/?h=glthread
>
> The plan is to merge everything up to the gallium commit (without the
> Intel commits, I'll let Intel decide what to do with them). I can send
> the whole series to the list if that's preferable.
>
> Opinions?
>
> Marek
> ___
> 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 03/17] gallium/radeon: allow VRAM-only placements again on APUs & recent amdgpu

[Ernst Sjöstrand]

Should this code be able to handle drm 4.0.0?

2017-01-26 17:04 GMT+01:00 Marek Olšák :

> From: Marek Olšák 
>
> ---
>  src/gallium/drivers/radeon/r600_buffer_common.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
> b/src/gallium/drivers/radeon/r600_buffer_common.c
> index c6f4d0d..da6f020 100644
> --- a/src/gallium/drivers/radeon/r600_buffer_common.c
> +++ b/src/gallium/drivers/radeon/r600_buffer_common.c
> @@ -163,22 +163,26 @@ void r600_init_resource_fields(struct
> r600_common_screen *rscreen,
> !rtex->surface.is_linear) {
> res->domains = RADEON_DOMAIN_VRAM;
> res->flags &= ~RADEON_FLAG_CPU_ACCESS;
> res->flags |= RADEON_FLAG_NO_CPU_ACCESS |
>  RADEON_FLAG_GTT_WC;
> }
>
> /* If VRAM is just stolen system memory, allow both VRAM and
>  * GTT, whichever has free space. If a buffer is evicted from
>  * VRAM to GTT, it will stay there.
> +*
> +* DRM 3.6.0 has good BO move throttling, so we can allow VRAM-only
> +* placements even with a low amount of stolen VRAM.
>  */
> if (!rscreen->info.has_dedicated_vram &&
> +   (rscreen->info.drm_major < 3 || rscreen->info.drm_minor < 6) &&
> res->domains == RADEON_DOMAIN_VRAM)
> res->domains = RADEON_DOMAIN_VRAM_GTT;
>
> if (rscreen->debug_flags & DBG_NO_WC)
> res->flags &= ~RADEON_FLAG_GTT_WC;
>
> /* Set expected VRAM and GART usage for the buffer. */
> res->vram_usage = 0;
> res->gart_usage = 0;
>
> --
> 2.7.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] Proposal of date-based Mesa versioning for 2017

[Ernst Sjöstrand]

I've seen many get confused by the fact that Ubuntu 16.10 is newer than
16.04, they think of it as 16.1 and 16.4. So avoiding that is nice.

Regards
//Ernst

2016-10-02 13:56 GMT+02:00 Nicolai Hähnle :

> On 01.10.2016 22:22, Tobias Klausmann wrote:
>
>> On 01.10.2016 21:46, Marek Olšák wrote:
>>
>>> Hi,
>>>
>>> I propose that we use versioning in the form of "year.quarter".
>>>
>>> 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
>>> quarters of the year, respectively.
>>> 2018 would start with 18.0, then 18.1, 18.2, 18.3.
>>>
>>> The motivation is that you can easily tell when a specific Mesa
>>> version was released with an accuracy of 3 months.
>>>
>>> That's the only scheme that seems practical to me. Everything else
>>> seems arbitrary or random.
>>>
>>> Opinions?
>>>
>>
>> Why not just use year.month instead, would be more accurate...and
>> releases happen semi random anyway and not after a given time.
>>
>
> That's fine for something like Ubuntu where they really stick to their two
> releases per year, in the same months each year. I'm not so sure that
> that's a realistic goal for Mesa, and if releases *aren't* consistently
> happening in the same months, you end up introducing a lot of confusion
> about which version numbers exist and which don't.
>
> Time-based with YY.0 for the first release of the year, and then YY.1,
> YY.2, etc. works fine.
>
> Cheers,
> Nicolai
>
> ___
> 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] Improving ralloc performance for the GLSL compiler

[Ernst Sjöstrand]

Haven't I read in many places that the Linux port of NS2 is extremely
crappy?
Perhaps you shouldn't pay too much attention to that... Then again, maybe
it's a good torture test. :-)

Regards
//Ernst

2016-09-01 18:11 GMT+02:00 Marek Olšák :

> On Aug 31, 2016 11:31 AM, "Eero Tamminen" 
> wrote:
> >
> > Hi,
> >
> >
> > On 31.08.2016 08:03, Kenneth Graunke wrote:
> >>
> >> On Tuesday, August 30, 2016 3:52:12 PM PDT Ian Romanick wrote:
> >> [snip]
> >>>
> >>> I don't recall any native Linux games encountering this, but my memory
> >>> may have faded.  There were some Windows DirectX games that would
> >>> exhaust VMA when run inside VMware.  Once we got to the point where the
> >>> GLSL IR was freed after linking, I believe pretty much all of these
> >>> problems went away.
> >>>
> >>> If we might do something that would dramatically increase our peak
> >>> memory usage, we'll need to test it in that environment.
> >>
> >>
> >> Dota 2 (32-bit) used to hit this a long time ago, but hasn't in quite
> >> some time.
> >
> >
> > Dota 2 is nowadays 64-bit.
> >
> > I think Natural Selection 2 (which is still 32-bit) also used to crash
> to memory issues.
> >
> > I don't think I saw other games with this issue, but DOTA2 & NS2 were
> probably the games that compiled largest number of shaders (many thousands
> of them
>
> While I agree with your earlier post, the number of shaders that is
> compiled is mostly irrelevant assuming all drivers release GLSL IR at link
> time. What remains to test is memory usage on 32-bit.
>
> Marek
>
> ___
> 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 08/15] mesa: kill off _mesa_do_init_remap_table()

[Ernst Sjöstrand]

2016-06-07 18:33 GMT+02:00 Emil Velikov :

> From: Emil Velikov 
>
> ... and inline its contents in _mesa_do_init_remap_table().
>


 in _mesa_init_remap_table().


Signed-off-by: Emil Velikov 
> ---
>  src/mesa/main/remap.c | 25 +++--
>  1 file changed, 7 insertions(+), 18 deletions(-)
>
> diff --git a/src/mesa/main/remap.c b/src/mesa/main/remap.c
> index a756057..6dc4235 100644
> --- a/src/mesa/main/remap.c
> +++ b/src/mesa/main/remap.c
> @@ -98,10 +98,8 @@ map_function_spec(const char *spec)
>   * The remap table needs to be initialized before calling the
>   * CALL/GET/SET macros defined in main/dispatch.h.
>   */
> -static void
> -_mesa_do_init_remap_table(const char *pool,
> - int size,
> - const struct gl_function_pool_remap *remap)
> +void
> +_mesa_init_remap_table(void)
>  {
> static bool initialized = false;
> GLint i;
> @@ -110,17 +108,17 @@ _mesa_do_init_remap_table(const char *pool,
>return;
> initialized = true;
>
> -   /* initialize the remap table */
> -   for (i = 0; i < size; i++) {
> +   /* initialize the MESA_remap_table_functions table */
> +   for (i = 0; i < driDispatchRemapTable_size; i++) {
>int offset;
>const char *spec;
>
>/* sanity check */
> -  assert(i == remap[i].remap_index);
> -  spec = _mesa_function_pool + remap[i].pool_index;
> +  assert(i == MESA_remap_table_functions[i].remap_index);
> +  spec = _mesa_function_pool +
> MESA_remap_table_functions[i].pool_index;
>
>offset = map_function_spec(spec);
> -  /* store the dispatch offset in the remap table */
> +  /* store the dispatch offset in the MESA_remap_table_functions
> table */
>driDispatchRemapTable[i] = offset;
>if (offset < 0) {
>   const char *name = spec + strlen(spec) + 1;
> @@ -128,12 +126,3 @@ _mesa_do_init_remap_table(const char *pool,
>}
> }
>  }
> -
> -
> -void
> -_mesa_init_remap_table(void)
> -{
> -   _mesa_do_init_remap_table(_mesa_function_pool,
> -driDispatchRemapTable_size,
> -MESA_remap_table_functions);
> -}
> --
> 2.8.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 00/14] radeonsi: Offchip tessellation

[Ernst Sjöstrand]

Hi,

nice! The windows driver has an option to limit tessellation factor to x16
etc, would it be possible to implement something similar in radeonsi? Of
course that's kindof to opposite to actually making x32 and x64 faster like
you're doing here. :-)

Regards
//Ernst

2016-05-10 12:52 GMT+02:00 Bas Nieuwenhuizen :

> This patchset implements offchip tessellation after which we can finally
> process
> more than one patch per wave without decreasing tessmark scores.
>
> For tessmark this improves performance by ~20% for the x32 case and ~80%
> for the
> x64 case. x8 and x16 have roughly the same performance as before. Unigine
> heaven
> gets 43 fps compared to 28 before (roughly +50%). Amdgpu-pro gets 44 fps
> for
> heaven. For Shadow of Mordor the performance changes from 28 fps to 40 fps
> (roughly +40%).
>
> Remaining ideas for improvement are:
>
>   - Don't store TCS outputs to TCS and don't unnecessarily allocate LDS.
> This
> has pretty much no measurable effect in the games I tried.
>
>   - Only store TCS outputs to memory when the tess factors exceed a
> threshold. I
> haven't been able to get the LDS case working with dynamic HS enabled,
> but
> the decompiled amdgpu-pro shaders give a very strong hint that this is
> possible. However amdgpu-pro sets the thresshold to -1, so pretty much
> always
> stores to memory too as far as I can see. Maybe it does not work on VI,
> or there is some interaction with the VI only distribution modes and
> these
> were considered more profitable.
>
>   - Hardware swizzled buffers. The swizzling by hand I use results in
> extra VALU
> instructions and it would be nice if we did not need to have them.
> However,
> my attempts have not resulted in a performance improvement yet.
>
> I have run the piglit gpu suite and found no regressions on a Tonga card.
>
> Bas Nieuwenhuizen (14):
>   radeonsi: Add buffer for offchip storage between TCS and TES.
>   radeonsi: Add offchip tessellation parameters.
>   radeonsi: Define build_tbuffer_store_dwords earlier to support new
> users.
>   radeonsi: Add buffer load functions.
>   radeonsi: Use correct parameter index for LS_OUT_LAYOUT.
>   radeonsi: Add user SGPR for the layout of the offchip buffer.
>   radeonsi: Add offchip buffer address calculation.
>   radeonsi: Store inputs to memory when not using a TCS.
>   radeonsi: Use buffer loads and stores for passing data from TCS to
> TES.
>   radeonsi: Remove LDS layout user SGPR's from TES.
>   radeonsi: Enable dynamic HS.
>   radeonsi: Use barrier instructions for TCS barriers.
>   radeonsi: Process multiple patches per threadgroup.
>   radeonsi: Allow TES distribution between shader engines.
>
>  src/gallium/drivers/radeonsi/si_pipe.c  |   1 +
>  src/gallium/drivers/radeonsi/si_pipe.h  |   1 +
>  src/gallium/drivers/radeonsi/si_shader.c| 567
> ++--
>  src/gallium/drivers/radeonsi/si_shader.h|  32 +-
>  src/gallium/drivers/radeonsi/si_state.c |   5 +
>  src/gallium/drivers/radeonsi/si_state.h |   1 +
>  src/gallium/drivers/radeonsi/si_state_draw.c|  59 ++-
>  src/gallium/drivers/radeonsi/si_state_shaders.c |  67 ++-
>  8 files changed, 560 insertions(+), 173 deletions(-)
>
> --
> 2.8.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] gallium/radeon: add an env variable to force a level of aniso filtering

[Ernst Sjöstrand]

2016-04-12 19:27 GMT+02:00 Ian Romanick :
> On 04/12/2016 09:39 AM, Marek Olšák wrote:
>> On Tue, Apr 12, 2016 at 6:32 PM, Ian Romanick  wrote:
>>> On 04/12/2016 05:21 AM, Marek Olšák wrote:
 On Mon, Apr 11, 2016 at 9:33 PM, Ian Romanick  wrote:
> radeon and r200 have a driconf option that is similar to this.  It sets
> a default initial max anisotropy value.  Maybe that would be better?

 If driconf didn't copy /etc/drirc into ~/.drirc, it would indeed be
 better. This needs to be fixed in driconf before we can consider it
 usable. After that, we can move such options there.
>>>
>>> I'm not sure what that means.  You mean the driconf app?
>>
>> Yes, the driconf app. It unconditionally copies all app workarounds
>> into ~/.drirc and following Mesa updates can't remove them. If you
>> don't run driconf, ~/.drirc won't be created and you'll always get
>> updated app workarounds with newer Mesa.
>
> That sounds awful... as a user, I'm pretty sure that would fill me with
> rage.  It seems like the app should only operate on the user's ~/.drirc.
>  Having an "import from /etc/drirc" button seems like the right answer.
>  Forcing it on people is never right. :(

Isn't the best strategy to overlay (merge) /etc/drirc with the users changes?

Regards
//Ernst
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Newbie task to get started

[Ernst Sjöstrand]

One idea I had was helping fixing Coverity errors, but they seem to be
locked in behind closed doors. There are other static checkers of
course, and one could look into various good compiler warnings (with
newer/alternative compilers)?

Regards
//Ernst

2016-04-11 11:54 GMT+02:00 Jakob Sinclair :
> On 2016-04-11 09:14, Jason Ekstrand wrote:
>>
>> Jakob,
>> Thanks for your interest and welcome to the mailing list!
>
>
> Thanks!
>
>> Yes, the NewbieProjects page, as with much of the mesa documentation, is a
>> bit
>> dated.  Before I can really tell you where to start, it would be good
>> to have a bit of background:
>>
>>  1) What graphics hardware do you have access to?  That will influence
>> what you can work on. :-)
>
>
> I currently have an R9 280x and is right now running the radeon + radeonsi
> driver. I also have an i5-3570K which makes me able to also work on the
> Intel driver.
>
>>  2) What kind of graphics experience do you have?  Have you ever
>> written a program that uses OpenGL?
>
>
> I have quite a lot of experience working with OpenGL. I have mostly used
> OpenGL for game engines that I have worked on.
>
>>  3) Do you have any compiler experience?  If not, that's ok, but be
>> warned that you might be getting some. ;-)
>
>
> I don't have experience working on any compiler but it would be really
> interesting to work on a compiler.
>
>>  4) Is there a particular area you like to work on?  If you have
>> something in particular that might help guide what you do.  If you
>> don't have any particular area, that's just fine.
>
>
> There is no area in particular that I'm more interested in than others. But
> normally I really like working on optimizations and making it more
> efficient. I don't though have a great deal of experience optimizing code.
>
>> The only real firm requirement to work on mesa is a decent working
>> knowledge of C.  Beyond that, there are a number of different projects
>> that one could work on that require varying levels of skill and/or
>> experience.  These include writing tests, adding compiler
>> optimizations, or even hooking up simple extensions.
>
>
> Thanks for the help! Really appreciate it.
>
>> On Sun, Apr 10, 2016 at 12:45 PM, Jakob Sinclair
>>  wrote:
>>
>>> Hi! My name is Jakob Sinclair and I would like to start contributing
>>> to mesa development. I was wondering if anyone has any easy tasks
>>> that I as a newbie could start working on. I tried looking at
>>> https://wiki.freedesktop.org/dri/NewbieProjects/ [1] but it seems
>>> that page is outdated and most of the tasks over there have already
>>> been done. Thanks in advance for your help!
>>>
>>> --
>>> Jakob Sinclair
>>> ___
>>> mesa-dev mailing list
>>> mesa-dev@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/mesa-dev [2]
>>
>>
>>
>>
>> Links:
>> --
>> [1] https://wiki.freedesktop.org/dri/NewbieProjects/
>> [2] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> --
> Mvh Jakob Sinclair.
>
> ___
> 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] Gallium Vulkan state tracker?

[Ernst Sjöstrand]

Hi!

Sorry if this is a silly question but I was thinking that there would
be a Vulkan Gallium state tracker in development behind closed doors
somehow. However I guess that's not the case?
I guess the Nouveau and Freedreno people are interested in this at
least, and AMD is busy with their closed source userspace library
using the amdgpu kernel interface?

Regards
//Ernst
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev