Re: [Mesa-dev] Rename "master" branch to "main"?

[Mike Lothian]

On Mon, 3 Aug 2020 at 18:42, Erik Faye-Lund
 wrote:
>
> On Mon, 2020-08-03 at 10:30 -0500, Jason Ekstrand wrote:
> > All,
> >
> > I'm sure by now you've all seen the articles, LKML mails, and other
> > chatter around inclusive language in software.  While mesa doesn't
> > provide a whole lot of documentation (hah!), we do have a website, a
> > code-base, and a git repo and this is something that we, as a project
> > should consider.
> >
> > What I'm proposing today is simply re-naming the primary Git branch
> > from "master" to "main".  Why "main"?  Because that's what GitHub has
> > chosen "main" as their new default branch name and so it sounds to me
> > like the most likely new default.
> >
> > As far as impact on the project goes, if and when we rename the
> > primary branch, the old "master" branch will be locked (no
> > pushing/merging allowed) and all MRs will have to be re-targeted
> > against the new branch.  Fortunately, that's very easy to do.  You
> > just edit the MR and there's a little drop-down box at the top for
> > which branch it targets.  I just tested this with one of mine and it
> > seems to work ok.
> >
> > As far as other bits of language in the code-base, I'm happy to see
> > those cleaned up as people have opportunity.  I'm not aware of any
> > particularly egregious offenders.  However, changing the name of the
> > primary branch is something which will cause a brief hiccup in
> > people's development process and so warrants broader discussion.
> >
> > Thoughts?
> >
>
> I'm all for renaming it, but I'm a bit worried about doing it in a way
> where we don't break all merge-requests...
>
> As far as I know, GitLab doesn't allow changing the target-branch of a
> merge-request, so all pending merge-requests would all of a sudden
> point to the wrong branch. Unless we have a a plan for somehow making
> sure both branches are updated in lock-step in a grace-period or
> something like that...
>
> I dunno. Does anyone have any great ideas for avoiding this problem?
>
Is that one that can be fixed in GitLab itself? I imagine a lot of
projects are going to be making similar changes
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] meson: Always include 'coroutines' in llvm optional modules

[Mike Lothian]

Without this I get build failures:

error: undefined reference to 'LLVMAddCoroEarlyPass'
error: undefined reference to 'LLVMAddCoroSplitPass'
error: undefined reference to 'LLVMAddCoroElidePass'
error: undefined reference to 'LLVMAddCoroCleanupPass'

Cc: Dylan Baker 
Signed-off-by: Mike Lothian 
---
 meson.build | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meson.build b/meson.build
index db21d4dbce4..9a3a9e1e0e1 100644
--- a/meson.build
+++ b/meson.build
@@ -1227,7 +1227,7 @@ if dep_libdrm.found()
 endif
 
 llvm_modules = ['bitwriter', 'engine', 'mcdisassembler', 'mcjit']
-llvm_optional_modules = []
+llvm_optional_modules = ['coroutines']
 if with_amd_vk or with_gallium_radeonsi or with_gallium_r600
   llvm_modules += ['amdgpu', 'native', 'bitreader', 'ipo']
   if with_gallium_r600
@@ -1239,7 +1239,6 @@ if with_gallium_opencl
 'all-targets', 'linker', 'coverage', 'instrumentation', 'ipo', 'irreader',
 'lto', 'option', 'objcarcopts', 'profiledata',
   ]
-  llvm_optional_modules += ['coroutines']
 endif
 
 if with_amd_vk or with_gallium_radeonsi
-- 
2.23.0

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

Re: [Mesa-dev] [PATCH 0/7] panfrost: GLES3 textures (and primitive restart)

[Mike Lothian]

Hi

Are there plans to add Panfrost to docs/features.txt?

Cheers

Mike

On Thu, 27 Jun 2019 at 14:13, Alyssa Rosenzweig
 wrote:
>
> Just a bit of potpourrie of low-hanging fruit for GLES3 features, e.g.
> floating-point textures and ES-class primitive restart.
>
> Alyssa Rosenzweig (7):
>   panfrost: Implement primitive restart
>   panfrost: Remove dubious assert
>   panfrost/midgard: Implement integer sampler
>   panfrost: Add some special formats
>   panfrost/midgard: Fix 3D texture regression
>   panfrost: Dump unknown formats before aborting
>   panfrost: Disable DXT-style texture compression
>
>  .../drivers/panfrost/include/panfrost-job.h   |  1 +
>  .../drivers/panfrost/midgard/disassemble.c| 22 +++
>  .../drivers/panfrost/midgard/midgard.h| 10 +++--
>  .../panfrost/midgard/midgard_compile.c| 21 +++---
>  src/gallium/drivers/panfrost/pan_context.c| 16 +++---
>  src/gallium/drivers/panfrost/pan_format.c |  6 +
>  src/gallium/drivers/panfrost/pan_screen.c |  4 +---
>  7 files changed, 65 insertions(+), 15 deletions(-)
>
> --
> 2.20.1
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation

[Mike Lothian]

Can someone with access revert from master until this is fixed? It's
been broken for 3 days now

On Tue, 21 May 2019 at 09:01, Juan A. Suarez Romero  wrote:
>
> On Tue, 2019-05-21 at 09:36 +0200, Gert Wollny wrote:
> > Hi Marek,
> >
> > it seems that this patch is causing a few issues [1], any idea what is
> > going on? Maybe it is best to revert the patch for now?
> >
> > Best,
> > Gert
> >
>
>
> As this is commit is causing issues, I'm withdrawing it out of 19.1 branch.
>
> If later a fix is provided, let me know so I can re-add it to the branch,
> together with the fix.
>
> Thanks.
>
> J.A.
>
> > [1] https://bugzilla.freedesktop.org/show_bug.cgi?id=110701
> >
> > On Fr, 2019-05-10 at 01:19 -0400, Marek Olšák wrote:
> > > From: Marek Olšák 
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108824
> > >
> > > Cc: 19.1 
> > > ---
> > >  src/gallium/drivers/radeonsi/si_descriptors.c | 94 -
> > > --
> > >  src/gallium/drivers/radeonsi/si_pipe.h|  2 +
> > >  src/gallium/drivers/radeonsi/si_state_draw.c  |  9 +-
> > >  3 files changed, 72 insertions(+), 33 deletions(-)
> > >
> > > diff --git a/src/gallium/drivers/radeonsi/si_descriptors.c
> > > b/src/gallium/drivers/radeonsi/si_descriptors.c
> > > index 744fc9a15d7..6a4dcacc0f3 100644
> > > --- a/src/gallium/drivers/radeonsi/si_descriptors.c
> > > +++ b/src/gallium/drivers/radeonsi/si_descriptors.c
> > > @@ -1580,242 +1580,272 @@ void
> > > si_update_needs_color_decompress_masks(struct si_context *sctx)
> > > si_samplers_update_needs_color_decompress_mask(
> > > > samplers[i]);
> > > si_images_update_needs_color_decompress_mask(
> > > > images[i]);
> > > si_update_shader_needs_decompress_mask(sctx, i);
> > > }
> > >
> > > si_resident_handles_update_needs_color_decompress(sctx);
> > >  }
> > >
> > >  /* BUFFER DISCARD/INVALIDATION */
> > >
> > > -/** Reset descriptors of buffer resources after \p buf has been
> > > invalidated. */
> > > +/* Reset descriptors of buffer resources after \p buf has been
> > > invalidated.
> > > + * If buf == NULL, reset all descriptors.
> > > + */
> > >  static void si_reset_buffer_resources(struct si_context *sctx,
> > >   struct si_buffer_resources
> > > *buffers,
> > >   unsigned descriptors_idx,
> > >   unsigned slot_mask,
> > >   struct pipe_resource *buf,
> > >   enum radeon_bo_priority priority)
> > >  {
> > > struct si_descriptors *descs = 
> > > > descriptors[descriptors_idx];
> > > unsigned mask = buffers->enabled_mask & slot_mask;
> > >
> > > while (mask) {
> > > unsigned i = u_bit_scan();
> > > -   if (buffers->buffers[i] == buf) {
> > > -   si_set_buf_desc_address(si_resource(buf),
> > > buffers->offsets[i],
> > > +   struct pipe_resource *buffer = buffers->buffers[i];
> > > +
> > > +   if (buffer && (!buf || buffer == buf)) {
> > > +   si_set_buf_desc_address(si_resource(buffer),
> > > buffers->offsets[i],
> > > descs->list + i*4);
> > > sctx->descriptors_dirty |= 1u <<
> > > descriptors_idx;
> > >
> > > radeon_add_to_gfx_buffer_list_check_mem(sctx,
> > > -   si_reso
> > > urce(buf),
> > > +   si_reso
> > > urce(buffer),
> > > buffers
> > > ->writable_mask & (1u << i) ?
> > >
> > > RADEON_USAGE_READWRITE :
> > >
> > > RADEON_USAGE_READ,
> > > priorit
> > > y, true);
> > > }
> > > }
> > >  }
> > >
> > > -/* Update all resource bindings where the buffer is bound, including
> > > +/* Update all buffer bindings where the buffer is bound, including
> > >   * all resource descriptors. This is invalidate_buffer without
> > > - * the invalidation. */
> > > + * the invalidation.
> > > + *
> > > + * If buf == NULL, update all buffer bindings.
> > > + */
> > >  void si_rebind_buffer(struct si_context *sctx, struct pipe_resource
> > > *buf)
> > >  {
> > > struct si_resource *buffer = si_resource(buf);
> > > unsigned i, shader;
> > > unsigned num_elems = sctx->vertex_elements ?
> > >sctx->vertex_elements->count :
> > > 0;
> > >
> > > /* We changed the buffer, now we need to bind it where the old
> > > one
> > >  * was bound. This consists of 2 things:
> > >  *   1) Updating the resource descriptor and dirtying it.
> > >  *   2) Adding a relocation to the CS, so that it's usable.
> > >  */
> > >
> > > /* Vertex buffers. */
> > > -   if (buffer->bind_history & PIPE_BIND_VERTEX_BUFFER) {
> > > +   if (!buffer) 

Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation

[Mike Lothian]

I managed to trigger the bug remotely using that branch :(

On Mon, 20 May 2019 at 09:03, Juan A. Suarez Romero  wrote:
>
> On Sat, 2019-05-18 at 15:52 +0100, Mike Lothian wrote:
> > This patch is causing strange behaviour for me (and someone else on
> > IRC) on my Raven system
> >
>
> Are you testing with master branch? Could you try with the staging/19.1 branch
> (current HEAD is fb6cce5817d)?
>
>
> If the problem persists, I can remove that patch from the queue, unless Marek
> can provide a fix for it.
>
> Thanks!
>
> J.A.
>
> > May 18 15:31:43 quark kwin_x11[607]: qt.qpa.xcb: QXcbConnection: XCB
> > error: 3 (BadWindow), sequence: 2825, resource id: 37748896, major
> > code: 18 (ChangeProperty), minor code: 0
> > May 18 15:31:44 quark systemsettings5[839]: WARNING:
> > viewBackgroundColor is deprecated, use backgroundColor with colorSet:
> > Theme.View instead
> > May 18 15:31:44 quark systemsettings5[839]: WARNING:
> > viewBackgroundColor is deprecated, use backgroundColor with colorSet:
> > Theme.View instead
> > May 18 15:31:44 quark systemsettings5[839]:
> > file:///usr/lib64/qt5/qml/QtQuick/Controls.2/org.kde.desktop/private/MobileTextActionsToolBar.qml:49:
> > TypeError: Cannot read property 'height' of null
> > May 18 15:31:44 quark systemsettings5[839]:
> > file:///usr/lib64/qt5/qml/QtQuick/Controls.2/org.kde.desktop/private/MobileTextActionsToolBar.qml:38:
> > TypeError: Cannot read property 'width' of null
> > May 18 15:31:44 quark systemsettings5[839]: WARNING:
> > viewBackgroundColor is deprecated, use backgroundColor with colorSet:
> > Theme.View instead
> > May 18 15:31:44 quark systemsettings5[839]: WARNING:
> > viewBackgroundColor is deprecated, use backgroundColor with colorSet:
> > Theme.View instead
> > May 18 15:31:44 quark systemsettings5[839]: KActivities: Database
> > connection:  "kactivities_db_resources_140035686410368_readonly"
> >query_only:
> > QVariant(qlonglong, 1)
> >journal_mode:
> > QVariant(QString, "wal")
> >wal_autocheckpoint:
> > QVariant(qlonglong, 100)
> >synchronous:
> > QVariant(qlonglong, 0)
> > May 18 15:31:44 quark systemsettings5[839]: Nothing to load - the
> > client id is empty
> > May 18 15:31:44 quark systemsettings5[839]: Nothing to load - the
> > client id is empty
> > May 18 15:31:44 quark systemsettings5[839]: WARNING:
> > viewBackgroundColor is deprecated, use backgroundColor with colorSet:
> > Theme.View instead
> > May 18 15:31:44 quark systemsettings5[839]: WARNING:
> > viewBackgroundColor is deprecated, use backgroundColor with colorSet:
> > Theme.View instead
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> > fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> > pid 839 thread systemsett:cs0 pid 842)
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> > at address 0x80010105 from 27
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> > VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> > fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> > pid 839 thread systemsett:cs0 pid 842)
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> > at address 0x80010105 from 27
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> > VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> > fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> > pid 839 thread systemsett:cs0 pid 842)
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> > at address 0x80010105 from 27
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> > VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> > fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
> > pid 839 thread systemsett:cs0 pid 842)
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
> > at address 0x80010105 from 27
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0:
> > VM_L2_PROTECTION_FAULT_STATUS:0x00501031
> > May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
> > fault (

Re: [Mesa-dev] [PATCH 2/2] radeonsi: update buffer descriptors in all contexts after buffer invalidation

[Mike Lothian]

This patch is causing strange behaviour for me (and someone else on
IRC) on my Raven system

May 18 15:31:43 quark kwin_x11[607]: qt.qpa.xcb: QXcbConnection: XCB
error: 3 (BadWindow), sequence: 2825, resource id: 37748896, major
code: 18 (ChangeProperty), minor code: 0
May 18 15:31:44 quark systemsettings5[839]: WARNING:
viewBackgroundColor is deprecated, use backgroundColor with colorSet:
Theme.View instead
May 18 15:31:44 quark systemsettings5[839]: WARNING:
viewBackgroundColor is deprecated, use backgroundColor with colorSet:
Theme.View instead
May 18 15:31:44 quark systemsettings5[839]:
file:///usr/lib64/qt5/qml/QtQuick/Controls.2/org.kde.desktop/private/MobileTextActionsToolBar.qml:49:
TypeError: Cannot read property 'height' of null
May 18 15:31:44 quark systemsettings5[839]:
file:///usr/lib64/qt5/qml/QtQuick/Controls.2/org.kde.desktop/private/MobileTextActionsToolBar.qml:38:
TypeError: Cannot read property 'width' of null
May 18 15:31:44 quark systemsettings5[839]: WARNING:
viewBackgroundColor is deprecated, use backgroundColor with colorSet:
Theme.View instead
May 18 15:31:44 quark systemsettings5[839]: WARNING:
viewBackgroundColor is deprecated, use backgroundColor with colorSet:
Theme.View instead
May 18 15:31:44 quark systemsettings5[839]: KActivities: Database
connection:  "kactivities_db_resources_140035686410368_readonly"
   query_only:
QVariant(qlonglong, 1)
   journal_mode:
QVariant(QString, "wal")
   wal_autocheckpoint:
QVariant(qlonglong, 100)
   synchronous:
QVariant(qlonglong, 0)
May 18 15:31:44 quark systemsettings5[839]: Nothing to load - the
client id is empty
May 18 15:31:44 quark systemsettings5[839]: Nothing to load - the
client id is empty
May 18 15:31:44 quark systemsettings5[839]: WARNING:
viewBackgroundColor is deprecated, use backgroundColor with colorSet:
Theme.View instead
May 18 15:31:44 quark systemsettings5[839]: WARNING:
viewBackgroundColor is deprecated, use backgroundColor with colorSet:
Theme.View instead
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 842)
May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
at address 0x80010105 from 27
May 18 15:31:44 quark kernel: amdgpu :08:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00501031
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 842)
May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
at address 0x80010105 from 27
May 18 15:31:44 quark kernel: amdgpu :08:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00501031
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 842)
May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
at address 0x80010105 from 27
May 18 15:31:44 quark kernel: amdgpu :08:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00501031
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 842)
May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
at address 0x80010105 from 27
May 18 15:31:44 quark kernel: amdgpu :08:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00501031
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 842)
May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
at address 0x80010105 from 27
May 18 15:31:44 quark kernel: amdgpu :08:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00501031
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 842)
May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
at address 0x80010105 from 27
May 18 15:31:44 quark kernel: amdgpu :08:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00501031
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 842)
May 18 15:31:44 quark kernel: amdgpu :08:00.0:   in page starting
at address 0x80010105 from 27
May 18 15:31:44 quark kernel: amdgpu :08:00.0:
VM_L2_PROTECTION_FAULT_STATUS:0x00501031
May 18 15:31:44 quark kernel: amdgpu :08:00.0: [gfxhub] retry page
fault (src_id:0 ring:0 vmid:5 pasid:32769, for process systemsettings5
pid 839 thread systemsett:cs0 pid 

Re: [Mesa-dev] [PATCH 0/5] RadeonSI: Displayable DCC for Ravens

[Mike Lothian]

Thanks, I notice your 5.2-wip is version 3.30.0, so I'll wait until
it's updated before testing

Cheers

Mike

On Fri, 1 Mar 2019 at 15:17, Alex Deucher  wrote:
>
> On Fri, Mar 1, 2019 at 10:11 AM Mike Lothian  wrote:
> >
> > Hi
> >
> > What do you mean by kernel driver version? It doesn't seem to match up
> > with a kernel version or a DC Version
>
> It's not the DC version or the kernel version.  There is a drm
> interface to get the drm driver version so that userspace can check
> what features are supported by the kernel driver.  See amdgpu_drv.c in
> the amdgpu kernel driver.
>
> Alex
>
> >
> > Cheers
> >
> > Mike
> >
> > On Thu, 28 Feb 2019 at 21:20, Marek Olšák  wrote:
> > >
> > > Hi,
> > >
> > > This series enables DCC for scanout on Ravens.
> > >
> > > It requires kernel driver version >= 3.31.0 and my xf86-video-amdgpu 
> > > patch.
> > >
> > > There is one issue to resolve: Steam crashes in 
> > > addrlib/ComputeDccAddrFromCoord.
> > >
> > > Please review,
> > >
> > > Thanks,
> > > 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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 0/5] RadeonSI: Displayable DCC for Ravens

[Mike Lothian]

Hi

What do you mean by kernel driver version? It doesn't seem to match up
with a kernel version or a DC Version

Cheers

Mike

On Thu, 28 Feb 2019 at 21:20, Marek Olšák  wrote:
>
> Hi,
>
> This series enables DCC for scanout on Ravens.
>
> It requires kernel driver version >= 3.31.0 and my xf86-video-amdgpu patch.
>
> There is one issue to resolve: Steam crashes in 
> addrlib/ComputeDccAddrFromCoord.
>
> Please review,
>
> Thanks,
> 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] meson: drop the xcb-xrandr version requirement

[Mike Lothian]

I'm a bit confused by this patch

It's in a section called xlib_lease, for leases to work I think the
newer version is required, but I think the underlying code was changed
to build without the newer headers

Do leases work with the old code, or should this section be renamed?

On Sun, 3 Feb 2019 at 11:52, Erik Faye-Lund
 wrote:
>
> On Sat, 2019-02-02 at 12:58 -0500, Marek Olšák wrote:
> >
> >
> > On Sat, Feb 2, 2019, 12:41 PM Eric Engestrom <
> > eric.engest...@intel.com wrote:
> > > On Saturday, 2019-02-02 10:32:15 -0500, Marek Olšák wrote:
> > > > On Sat, Feb 2, 2019, 7:17 AM Eric Engestrom <
> > > eric.engest...@intel.com wrote:
> > > >
> > > > > On Friday, 2019-02-01 15:42:17 -0500, Marek Olšák wrote:
> > > > > > If there is no feedback soon, I'll push this.
> > > > >
> > > > > Have you tested that xcb-randr < 1.12 works?
> > > > > Probably shouldn't remove a restriction unless you're sure it
> > > isn't
> > > > > needed :)
> > > > >
> > > >
> > > > Is this a joke? I'm just mirroring autotools. Supporting the same
> > > linux
> > > > distributions as autotools is a requirement for meson's general
> > > acceptance.
> > >
> > > No, I'm being serious: just because a restriction didn't exist on
> > > autotools doesn't mean that code path was exercised by people
> > > running
> > > an old xcb-randr, hence the need to test it :)
> > >
> > > I didn't mean to offend you, I was just asking the question to make
> > > sure
> > > this was tested before we claim to support xcb-randr < 1.12, as it
> > > might
> > > be that autotools was simply missing the version check.
> >
> > Ok. I use old xcb-xrandr on some of my systems, one of them used to
> > be my main system. Not being able to use meson on those systems
> > without this patch is a big deal for me.
>
> This sounds like you have indeed tested on xcb-randr < 1.12, so I
> suppose the answer to the question is "yes"? If so, I think it's all
> good, no?
>
> Anyway, I think this seems like the right move, and since Keith has't
> responded, feel free to add:
>
> Reviewed-by: Erik Faye-Lund 
>
> ___
> 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] radv: take LDS into account for compute shader occupancy stats

[Mike Lothian]

Hi

I think you've left a few references to the old ac_nir_get_max_workgroup_size

FAILED: src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o
x86_64-pc-linux-gnu-gcc -m32
-Isrc/amd/vulkan/9198681@@vulkan_radeon@sha -Isrc/amd/vulkan
-I../mesa-/src/amd/vulkan -Isrc/../include
-I../mesa-/src/../include -Isrc -I../mesa-/src -Isrc/mapi
rc/mesa -I../mesa-/src/gallium/include -Isrc/gallium/auxiliary
-I../mesa-/src/gallium/auxiliary -Isrc/amd -I../mesa-/src/amd
-Isrc/amd/common -I../mesa-/src/amd/common -Isrc/compiler -I.
-/src/vulkan/util -Isrc/vulkan/wsi -I../mesa-/src/vulkan/wsi
-Isrc/compiler/nir -I../mesa-/src/compiler/nir
-I/usr/lib/llvm/9/include -I/usr/include/libdrm
-fdiagnostics-color=always -DNDEBU
'-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa;'
-DGLX_USE_TLS -DHAVE_ST_VDPAU -DENABLE_ST_OMX_BELLAGIO=0
-DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM -DGLX_INDIRECT_REND
M_PLATFORM -DHAVE_SURFACELESS_PLATFORM -DENABLE_SHADER_CACHE
-DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 -DHAVE___BUILTIN_CLZ
-DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -D
UILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
-DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATT
LT -DHAVE_FUNC_ATTRIBUTE_WEAK -DHAVE_FUNC_ATTRIBUTE_FORMAT
-DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS
-DHAVE_FUNC_ATT
S -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM
-DMAJOR_IN_SYSMACROS -DHAVE_SYS_SYSCTL_H -DHAVE_LINUX_FUTEX_H
-DHAVE_ENDIAN_H -DHAVE_DLFCN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP
-DHAVE_POSIX_MEMALI
RTOD_L -DHAVE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD
-DHAVE_PTHREAD_SETAFFINITY -DHAVE_LIBDRM -DHAVE_LLVM=0x0900
-DMESA_LLVM_VERSION_PATCH=0 -DHAVE_WAYLAND_PLATFORM
-DWL_HIDE_DEPRECATE
S=1 -Werror=implicit-function-declaration -Werror=missing-prototypes
-Werror=return-type -fno-math-errno -fno-trapping-math
-Wno-missing-field-initializers -Wno-format-truncation -fPIC -pthread
-D_FILE_
-D__STDC_LIMIT_MACROS -D_LARGEFILE_SOURCE -D__STDC_CONSTANT_MACROS
-fvisibility=hidden -Wno-override-init -DVK_USE_PLATFORM_XCB_KHR
-DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLAT
O3 -march=native -pipe -MD -MQ
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o' -MF
'src/amd/vulkan/9198681@@vulkan_radeon@sha/radv_nir_to_llvm.c.o.d' -o
'src/amd/vulkan/9198681@@vulkan_
/amd/vulkan/radv_nir_to_llvm.c
In file included from ../mesa-/src/mesa/main/macros.h:35,
 from ../mesa-/src/amd/vulkan/radv_private.h:51,
 from ../mesa-/src/amd/vulkan/radv_nir_to_llvm.c:28:
../mesa-/src/amd/vulkan/radv_nir_to_llvm.c: In function
‘ac_translate_nir_to_llvm’:
../mesa-/src/amd/vulkan/radv_nir_to_llvm.c:3453:33: error:
implicit declaration of function ‘ac_nir_get_max_workgroup_size’; did
you mean ‘radv_nir_get_max_workgroup_size’? [-Werror=implicit-functio

ac_nir_get_max_workgroup_size(ctx.options->chip_class,
 ^
../mesa-/src/util/u_math.h:659:31: note: in definition of macro ‘MAX2’
 #define MAX2( A, B )   ( (A)>(B) ? (A) : (B) )
   ^
cc1: some warnings being treated as errors

Cheers

Mike

On Fri, 1 Feb 2019 at 11:07, Timothy Arceri  wrote:
>
> Ported from d205faeb6c96.
> ---
>  src/amd/vulkan/radv_nir_to_llvm.c |  6 +++---
>  src/amd/vulkan/radv_private.h |  3 +++
>  src/amd/vulkan/radv_shader.c  | 10 --
>  3 files changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
> b/src/amd/vulkan/radv_nir_to_llvm.c
> index e80938527e5..d90a4c0de1e 100644
> --- a/src/amd/vulkan/radv_nir_to_llvm.c
> +++ b/src/amd/vulkan/radv_nir_to_llvm.c
> @@ -3372,9 +3372,9 @@ ac_setup_rings(struct radv_shader_context *ctx)
> }
>  }
>
> -static unsigned
> -ac_nir_get_max_workgroup_size(enum chip_class chip_class,
> - const struct nir_shader *nir)
> +unsigned
> +radv_nir_get_max_workgroup_size(enum chip_class chip_class,
> +   const struct nir_shader *nir)
>  {
> switch (nir->info.stage) {
> case MESA_SHADER_TESS_CTRL:
> diff --git a/src/amd/vulkan/radv_private.h b/src/amd/vulkan/radv_private.h
> index 85c18906f84..e5b8286ea62 100644
> --- a/src/amd/vulkan/radv_private.h
> +++ b/src/amd/vulkan/radv_private.h
> @@ -1934,6 +1934,9 @@ void radv_compile_nir_shader(struct ac_llvm_compiler 
> *ac_llvm,
>  int nir_count,
>  const struct radv_nir_compiler_options *options);
>
> +unsigned radv_nir_get_max_workgroup_size(enum chip_class chip_class,
> +const struct nir_shader *nir);
> +
>  /* radv_shader_info.h */
>  

Re: [Mesa-dev] [PATCH 2/3] winsys/amdgpu: add support for allocating GDS and OA resources

[Mike Lothian]

Same for OA

Cheers

Mike

On Tue, 27 Nov 2018, 01:57 Marek Olšák,  wrote:

> From: Marek Olšák 
>
> ---
>  src/gallium/drivers/radeon/radeon_winsys.h |  4 +-
>  src/gallium/winsys/amdgpu/drm/amdgpu_bo.c  | 55 +-
>  2 files changed, 36 insertions(+), 23 deletions(-)
>
> diff --git a/src/gallium/drivers/radeon/radeon_winsys.h
> b/src/gallium/drivers/radeon/radeon_winsys.h
> index 3d0bb75ef6e..a5dd3e6f9b1 100644
> --- a/src/gallium/drivers/radeon/radeon_winsys.h
> +++ b/src/gallium/drivers/radeon/radeon_winsys.h
> @@ -45,21 +45,23 @@ enum radeon_bo_layout {
>  RADEON_LAYOUT_LINEAR = 0,
>  RADEON_LAYOUT_TILED,
>  RADEON_LAYOUT_SQUARETILED,
>
>  RADEON_LAYOUT_UNKNOWN
>  };
>
>  enum radeon_bo_domain { /* bitfield */
>  RADEON_DOMAIN_GTT  = 2,
>  RADEON_DOMAIN_VRAM = 4,
> -RADEON_DOMAIN_VRAM_GTT = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT
> +RADEON_DOMAIN_VRAM_GTT = RADEON_DOMAIN_VRAM | RADEON_DOMAIN_GTT,
> +RADEON_DOMAIN_GDS = 8,
> +RADEON_DOMAIN_OA = 16,
>  };
>
>  enum radeon_bo_flag { /* bitfield */
>  RADEON_FLAG_GTT_WC =(1 << 0),
>  RADEON_FLAG_NO_CPU_ACCESS = (1 << 1),
>  RADEON_FLAG_NO_SUBALLOC =   (1 << 2),
>  RADEON_FLAG_SPARSE =(1 << 3),
>  RADEON_FLAG_NO_INTERPROCESS_SHARING = (1 << 4),
>  RADEON_FLAG_READ_ONLY = (1 << 5),
>  RADEON_FLAG_32BIT =(1 << 6),
> diff --git a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> index a9170a2bc69..1470c873a6a 100644
> --- a/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> +++ b/src/gallium/winsys/amdgpu/drm/amdgpu_bo.c
> @@ -177,22 +177,24 @@ void amdgpu_bo_destroy(struct pb_buffer *_buf)
>simple_mtx_lock(>global_bo_list_lock);
>LIST_DEL(>u.real.global_list_item);
>ws->num_buffers--;
>simple_mtx_unlock(>global_bo_list_lock);
> }
>
> simple_mtx_lock(>bo_export_table_lock);
> util_hash_table_remove(ws->bo_export_table, bo->bo);
> simple_mtx_unlock(>bo_export_table_lock);
>
> -   amdgpu_bo_va_op(bo->bo, 0, bo->base.size, bo->va, 0,
> AMDGPU_VA_OP_UNMAP);
> -   amdgpu_va_range_free(bo->u.real.va_handle);
> +   if (bo->initial_domain & RADEON_DOMAIN_VRAM_GTT) {
> +  amdgpu_bo_va_op(bo->bo, 0, bo->base.size, bo->va, 0,
> AMDGPU_VA_OP_UNMAP);
> +  amdgpu_va_range_free(bo->u.real.va_handle);
> +   }
> amdgpu_bo_free(bo->bo);
>
> amdgpu_bo_remove_fences(bo);
>
> if (bo->initial_domain & RADEON_DOMAIN_VRAM)
>ws->allocated_vram -= align64(bo->base.size,
> ws->info.gart_page_size);
> else if (bo->initial_domain & RADEON_DOMAIN_GTT)
>ws->allocated_gtt -= align64(bo->base.size,
> ws->info.gart_page_size);
>
> if (bo->u.real.map_count >= 1) {
> @@ -418,25 +420,26 @@ static struct amdgpu_winsys_bo
> *amdgpu_create_bo(struct amdgpu_winsys *ws,
>   unsigned alignment,
>   enum radeon_bo_domain
> initial_domain,
>   unsigned flags,
>   int heap)
>  {
> struct amdgpu_bo_alloc_request request = {0};
> amdgpu_bo_handle buf_handle;
> uint64_t va = 0;
> struct amdgpu_winsys_bo *bo;
> amdgpu_va_handle va_handle;
> -   unsigned va_gap_size;
> int r;
>
> /* VRAM or GTT must be specified, but not both at the same time. */
> -   assert(util_bitcount(initial_domain & RADEON_DOMAIN_VRAM_GTT) == 1);
> +   assert(util_bitcount(initial_domain & (RADEON_DOMAIN_VRAM_GTT |
> +  RADEON_DOMAIN_GDS |
> +  RADEON_DOMAIN_OA)) == 1);
>
> /* Gfx9: Overallocate the size to the next power of two for faster
> address
>  * translation if we don't waste too much memory.
>  */
> if (ws->info.chip_class >= GFX9) {
>uint64_t next_pot_size = util_next_power_of_two64(size);
>
>/* For slightly lower than 4 GB allocations, at most 32 MB are
> wasted.
> * For slightly lower than 256 MB allocations, at most 2 MB are
> wasted.
> * For slightly lower than 64 MB allocations, at most 512 KB are
> wasted.
> @@ -464,20 +467,24 @@ static struct amdgpu_winsys_bo
> *amdgpu_create_bo(struct amdgpu_winsys *ws,
>pb_cache_init_entry(>bo_cache, >u.real.cache_entry,
> >base,
>heap);
> }
> request.alloc_size = size;
> request.phys_alignment = alignment;
>
> if (initial_domain & RADEON_DOMAIN_VRAM)
>request.preferred_heap |= AMDGPU_GEM_DOMAIN_VRAM;
> if (initial_domain & RADEON_DOMAIN_GTT)
>request.preferred_heap |= AMDGPU_GEM_DOMAIN_GTT;
> +   if (initial_domain & RADEON_DOMAIN_GDS)
> +  request.preferred_heap |= AMDGPU_GEM_DOMAIN_GDS;
> +   if (initial_domain & RADEON_DOMAIN_OA)
> +  request.preferred_heap |= AMDGPU_GEM_DOMAIN_OA;
>
> /* Since VRAM and GTT have almost the 

Re: [Mesa-dev] [PATCH 1/3] radeonsi: allow si_cp_dma_clear_buffer to clear GDS from any IB

[Mike Lothian]

Hi

What's GDS and IB stand for?

Thanks

Mike

On Tue, 27 Nov 2018, 01:57 Marek Olšák,  wrote:

> From: Marek Olšák 
>
> ---
>  .../drivers/radeonsi/si_compute_blit.c|  4 +-
>  src/gallium/drivers/radeonsi/si_cp_dma.c  | 49 ++-
>  src/gallium/drivers/radeonsi/si_pipe.h|  8 +--
>  .../drivers/radeonsi/si_test_dma_perf.c   |  3 +-
>  4 files changed, 33 insertions(+), 31 deletions(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_compute_blit.c
> b/src/gallium/drivers/radeonsi/si_compute_blit.c
> index 20e4f591fbb..086793637f0 100644
> --- a/src/gallium/drivers/radeonsi/si_compute_blit.c
> +++ b/src/gallium/drivers/radeonsi/si_compute_blit.c
> @@ -212,22 +212,22 @@ void si_clear_buffer(struct si_context *sctx, struct
> pipe_resource *dst,
>  */
> if (clear_value_size > 4 ||
> (clear_value_size == 4 &&
>  offset % 4 == 0 &&
>  (size > 32*1024 || sctx->chip_class <= VI))) {
> si_compute_do_clear_or_copy(sctx, dst, offset,
> NULL, 0,
> aligned_size,
> clear_value,
> clear_value_size,
> coher);
> } else {
> assert(clear_value_size == 4);
> -   si_cp_dma_clear_buffer(sctx, dst, offset,
> -  aligned_size, *clear_value,
> coher,
> +   si_cp_dma_clear_buffer(sctx, sctx->gfx_cs, dst,
> offset,
> +  aligned_size, *clear_value,
> 0, coher,
>get_cache_policy(sctx,
> coher, size));
> }
>
> offset += aligned_size;
> size -= aligned_size;
> }
>
> /* Handle non-dword alignment. */
> if (size) {
> assert(dst);
> diff --git a/src/gallium/drivers/radeonsi/si_cp_dma.c
> b/src/gallium/drivers/radeonsi/si_cp_dma.c
> index 839b31b7fdf..33220d9f0fa 100644
> --- a/src/gallium/drivers/radeonsi/si_cp_dma.c
> +++ b/src/gallium/drivers/radeonsi/si_cp_dma.c
> @@ -47,25 +47,24 @@ static inline unsigned cp_dma_max_byte_count(struct
> si_context *sctx)
>
> /* make it aligned for optimal performance */
> return max & ~(SI_CPDMA_ALIGNMENT - 1);
>  }
>
>
>  /* Emit a CP DMA packet to do a copy from one buffer to another, or to
> clear
>   * a buffer. The size must fit in bits [20:0]. If CP_DMA_CLEAR is set,
> src_va is a 32-bit
>   * clear value.
>   */
> -static void si_emit_cp_dma(struct si_context *sctx, uint64_t dst_va,
> -  uint64_t src_va, unsigned size, unsigned flags,
> -  enum si_cache_policy cache_policy)
> +static void si_emit_cp_dma(struct si_context *sctx, struct radeon_cmdbuf
> *cs,
> +  uint64_t dst_va, uint64_t src_va, unsigned size,
> +  unsigned flags, enum si_cache_policy
> cache_policy)
>  {
> -   struct radeon_cmdbuf *cs = sctx->gfx_cs;
> uint32_t header = 0, command = 0;
>
> assert(size <= cp_dma_max_byte_count(sctx));
> assert(sctx->chip_class != SI || cache_policy == L2_BYPASS);
>
> if (sctx->chip_class >= GFX9)
> command |= S_414_BYTE_COUNT_GFX9(size);
> else
> command |= S_414_BYTE_COUNT_GFX6(size);
>
> @@ -139,21 +138,21 @@ static void si_emit_cp_dma(struct si_context *sctx,
> uint64_t dst_va,
>  }
>
>  void si_cp_dma_wait_for_idle(struct si_context *sctx)
>  {
> /* Issue a dummy DMA that copies zero bytes.
>  *
>  * The DMA engine will see that there's no work to do and skip this
>  * DMA request, however, the CP will see the sync flag and still
> wait
>  * for all DMAs to complete.
>  */
> -   si_emit_cp_dma(sctx, 0, 0, 0, CP_DMA_SYNC, L2_BYPASS);
> +   si_emit_cp_dma(sctx, sctx->gfx_cs, 0, 0, 0, CP_DMA_SYNC,
> L2_BYPASS);
>  }
>
>  static void si_cp_dma_prepare(struct si_context *sctx, struct
> pipe_resource *dst,
>   struct pipe_resource *src, unsigned
> byte_count,
>   uint64_t remaining_size, unsigned user_flags,
>   enum si_coherency coher, bool *is_first,
>   unsigned *packet_flags)
>  {
> /* Fast exit for a CPDMA prefetch. */
> if ((user_flags & SI_CPDMA_SKIP_ALL) == SI_CPDMA_SKIP_ALL) {
> @@ -200,51 +199,53 @@ static void si_cp_dma_prepare(struct si_context
> *sctx, struct pipe_resource *dst
>  */
> if (!(user_flags & SI_CPDMA_SKIP_SYNC_AFTER) &&
> byte_count == remaining_size) {
> *packet_flags |= CP_DMA_SYNC;
>
> if (coher == SI_COHERENCY_SHADER)
> *packet_flags |= CP_DMA_PFP_SYNC_ME;
> }
>  }

Re: [Mesa-dev] [PATCH] loader/dri3: Also wait for front buffer fence if we triggered it

[Mike Lothian]

I'm still seeing weird graphical corruptions in chrome and sometimes when
playing video

It's especially noticeable when in inbox.google.com

I might be suffering from a different issue however

On Thu, 11 Oct 2018 at 11:43 Mike Lothian  wrote:

> Do you think this why I've been seeing lots of weird flashing in Chrome
> recently?
>
> I'll test this patch out tonight and give you my tested by if you like
>
> On Thu, 11 Oct 2018 at 09:27 Michel Dänzer  wrote:
>
>>
>> Any feedback? Without negative feedback, I'll push this fix tomorrow.
>>
>>
>> On 2018-10-02 4:44 p.m., Michel Dänzer wrote:
>> > From: Michel Dänzer 
>> >
>> > In that case, we have to wait for the fence to synchronize with the
>> > corresponding drawing we triggered in the X server.
>> >
>> > Fixes incorrect display with the i965 and some applications, e.g.
>>
>> BTW, I've locally fixed this to say "the i965 driver".
>>
>>
>> > solvespace.
>> >
>> > Bugzilla: https://bugs.freedesktop.org/108097
>> > Fixes: aefac10fecc9 "loader/dri3: Only wait for back buffer fences in
>> >  dri3_get_buffer"
>> > Tested-by: Sergii Romantsov 
>> > Signed-off-by: Michel Dänzer 
>> > ---
>> >  src/loader/loader_dri3_helper.c | 7 +--
>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/src/loader/loader_dri3_helper.c
>> b/src/loader/loader_dri3_helper.c
>> > index f641a34e6d1..1981b5f0515 100644
>> > --- a/src/loader/loader_dri3_helper.c
>> > +++ b/src/loader/loader_dri3_helper.c
>> > @@ -1736,6 +1736,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>> >  struct loader_dri3_drawable *draw)
>> >  {
>> > struct loader_dri3_buffer *buffer;
>> > +   bool fence_await = buffer_type == loader_dri3_buffer_back;
>> > int buf_id;
>> >
>> > if (buffer_type == loader_dri3_buffer_back) {
>> > @@ -1791,6 +1792,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>> > 0, 0, 0, 0,
>> > draw->width, draw->height);
>> >  dri3_fence_trigger(draw->conn, new_buffer);
>> > +fence_await = true;
>> >   }
>> >   dri3_free_render_buffer(draw, buffer);
>> >} else if (buffer_type == loader_dri3_buffer_front) {
>> > @@ -1812,13 +1814,14 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
>> >new_buffer->linear_buffer,
>> >0, 0, draw->width,
>> draw->height,
>> >0, 0, 0);
>> > - }
>> > + } else
>> > +fence_await = true;
>> >}
>> >buffer = new_buffer;
>> >draw->buffers[buf_id] = buffer;
>> > }
>> >
>> > -   if (buffer_type == loader_dri3_buffer_back)
>> > +   if (fence_await)
>> >dri3_fence_await(draw->conn, draw, buffer);
>> >
>> > /*
>> >
>>
>>
>> --
>> Earthling Michel Dänzer   |   http://www.amd.com
>> Libre software enthusiast | Mesa and X developer
>> ___
>> 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] loader/dri3: Also wait for front buffer fence if we triggered it

[Mike Lothian]

Do you think this why I've been seeing lots of weird flashing in Chrome
recently?

I'll test this patch out tonight and give you my tested by if you like

On Thu, 11 Oct 2018 at 09:27 Michel Dänzer  wrote:

>
> Any feedback? Without negative feedback, I'll push this fix tomorrow.
>
>
> On 2018-10-02 4:44 p.m., Michel Dänzer wrote:
> > From: Michel Dänzer 
> >
> > In that case, we have to wait for the fence to synchronize with the
> > corresponding drawing we triggered in the X server.
> >
> > Fixes incorrect display with the i965 and some applications, e.g.
>
> BTW, I've locally fixed this to say "the i965 driver".
>
>
> > solvespace.
> >
> > Bugzilla: https://bugs.freedesktop.org/108097
> > Fixes: aefac10fecc9 "loader/dri3: Only wait for back buffer fences in
> >  dri3_get_buffer"
> > Tested-by: Sergii Romantsov 
> > Signed-off-by: Michel Dänzer 
> > ---
> >  src/loader/loader_dri3_helper.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/loader/loader_dri3_helper.c
> b/src/loader/loader_dri3_helper.c
> > index f641a34e6d1..1981b5f0515 100644
> > --- a/src/loader/loader_dri3_helper.c
> > +++ b/src/loader/loader_dri3_helper.c
> > @@ -1736,6 +1736,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> >  struct loader_dri3_drawable *draw)
> >  {
> > struct loader_dri3_buffer *buffer;
> > +   bool fence_await = buffer_type == loader_dri3_buffer_back;
> > int buf_id;
> >
> > if (buffer_type == loader_dri3_buffer_back) {
> > @@ -1791,6 +1792,7 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> > 0, 0, 0, 0,
> > draw->width, draw->height);
> >  dri3_fence_trigger(draw->conn, new_buffer);
> > +fence_await = true;
> >   }
> >   dri3_free_render_buffer(draw, buffer);
> >} else if (buffer_type == loader_dri3_buffer_front) {
> > @@ -1812,13 +1814,14 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> >new_buffer->linear_buffer,
> >0, 0, draw->width,
> draw->height,
> >0, 0, 0);
> > - }
> > + } else
> > +fence_await = true;
> >}
> >buffer = new_buffer;
> >draw->buffers[buf_id] = buffer;
> > }
> >
> > -   if (buffer_type == loader_dri3_buffer_back)
> > +   if (fence_await)
> >dri3_fence_await(draw->conn, draw, buffer);
> >
> > /*
> >
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> 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] docs/features: add EXT_direct_state_access features

[Mike Lothian]

You might want to remove the " we DO NOT WANT implementations of these
extensions for Mesa" if you're planning on implementing them

On Tue, 18 Sep 2018 at 10:48 Timothy Arceri  wrote:

> Acked-by: Timothy Arceri 
>
> On 18/9/18 1:31 pm, Marek Olšák wrote:
> > From: Marek Olšák 
> >
> > ---
> >   docs/features.txt | 57 +++
> >   1 file changed, 57 insertions(+)
> >
> > diff --git a/docs/features.txt b/docs/features.txt
> > index 9ccf803d470..a97f998a5cc 100644
> > --- a/docs/features.txt
> > +++ b/docs/features.txt
> > @@ -337,20 +337,77 @@ Khronos, ARB, and OES extensions that are not part
> of any OpenGL or OpenGL ES ve
> > GL_OES_texture_float  DONE
> (freedreno, i965, r300, r600, radeonsi, nv30, nv50, nvc0, softpipe,
> llvmpipe)
> > GL_OES_texture_float_linear   DONE
> (freedreno, i965, r300, r600, radeonsi, nv30, nv50, nvc0, softpipe,
> llvmpipe)
> > GL_OES_texture_half_float DONE
> (freedreno, i965, r300, r600, radeonsi, nv30, nv50, nvc0, softpipe,
> llvmpipe)
> > GL_OES_texture_half_float_linear  DONE
> (freedreno, i965, r300, r600, radeonsi, nv30, nv50, nvc0, softpipe,
> llvmpipe)
> > GL_OES_texture_view   DONE
> (i965/gen8+)
> > GL_OES_viewport_array DONE (i965,
> nvc0, radeonsi)
> > GLX_ARB_context_flush_control not started
> > GLX_ARB_robustness_application_isolation  not started
> > GLX_ARB_robustness_share_group_isolation  not started
> >
> > +GL_EXT_direct_state_access subfeatures (in the spec order):
> > +  GL 1.1: Client commands   not started
> > +  GL 1.0-1.3: Matrix and transpose matrix commands  not started
> > +  GL 1.1-1.2: Texture commands  not started
> > +  GL 1.2: 3D texture commands   not started
> > +  GL 1.2.1: Multitexture commands   not started
> > +  GL 1.2.1-3.0: Indexed texture commandsnot started
> > +  GL 1.2.1-3.0: Indexed generic queries not started
> > +  GL 1.2.1: EnableIndexed.. Get*Indexed not started
> > +  GL_ARB_vertex_program not started
> > +  GL 1.3: Compressed texture and multitexture commands  not started
> > +  GL 1.5: Buffer commands   not started
> > +  GL 2.0-2.1: Uniform and uniform matrix commands   not started
> > +  GL_EXT_texture_buffer_object  not started
> > +  GL_EXT_texture_integernot started
> > +  GL_EXT_gpu_shader4not started
> > +  GL_EXT_gpu_program_parameters not started
> > +  GL_NV_gpu_program4n/a
> > +  GL_NV_framebuffer_multisample_coveragen/a
> > +  GL 3.0: Renderbuffer/framebuffer commands, Gen*Mipmap not started
> > +  GL 3.0: CopyBuffer commandnot started
> > +  GL_EXT_geometry_shader4 commands (expose in GL 3.2)   not started
> > +  GL_NV_explicit_multisamplen/a
> > +  GL 3.0: Vertex array/attrib/query/map commandsnot started
> > +  Matrix GL tokens  not started
> > +
> > +GL_EXT_direct_state_access additions from other extensions (complete
> list):
> > +  GL_AMD_framebuffer_sample_positions   n/a
> > +  GL_AMD_gpu_shader_int64   not started
> > +  GL_ARB_bindless_texture   not started
> > +  GL_ARB_buffer_storage not started
> > +  GL_ARB_clear_buffer_objectnot started
> > +  GL_ARB_framebuffer_no_attachments not started
> > +  GL_ARB_gpu_shader_fp64not started
> > +  GL_ARB_instanced_arrays   not started
> > +  GL_ARB_internalformat_query2  not started
> > +  GL_ARB_sparse_texture n/a
> > +  GL_ARB_sparse_buffer  not started
> > +  GL_ARB_texture_buffer_range   not started
> > +  GL_ARB_texture_storagenot started
> > +  GL_ARB_texture_storage_multisamplenot started
> > +  GL_ARB_vertex_attrib_64bitnot started
> > +  GL_ARB_vertex_attrib_binding  not started
> > +  GL_EXT_buffer_storage not started
> > +  GL_EXT_external_buffernot started
> > +  GL_EXT_separate_shader_objectsn/a
> > +  GL_EXT_sparse_texture n/a
> > +  

Re: [Mesa-dev] [PATCH 1/2] loader/dri3: Only wait for back buffer fences in dri3_get_buffer

[Mike Lothian]

Hi

If this is prime related I can test it tonight for you

Cheers

Mike

On Tue, 11 Sep 2018 at 14:06 Thomas Hellstrom  wrote:

>
> On 09/11/2018 02:41 PM, Michel Dänzer wrote:
> > Any feedback on this patch? Without negative feedback, I'll push it
> > later this week.
> Hi, Michel,
>
> This looks ok to me.
>
> Reviewed-by: Thomas Hellstrom 
>
> /Thomas
>
> >
> >
> > On 2018-09-04 6:22 p.m., Michel Dänzer wrote:
> >> From: Michel Dänzer 
> >>
> >> We don't need to wait before drawing to the fake front buffer, as front
> >> buffer rendering by definition is allowed to produce artifacts.
> >>
> >> Fixes hangs in some cases when re-using the fake front buffer, due to it
> >> still being busy (i.e. in use for presentation).
> >>
> >> Cc: mesa-sta...@lists.freedesktop.org
> >> Bugzilla:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2F106404data=02%7C01%7Cthellstrom%40vmware.com%7C758cf6c04efd4541578a08d617e3e821%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636722664962505455sdata=RvqyEylP%2B96KAl6k9H5j7cyx1PW%2B3FFMmtpD0PwiQwU%3Dreserved=0
> >> Bugzilla:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.freedesktop.org%2F107757data=02%7C01%7Cthellstrom%40vmware.com%7C758cf6c04efd4541578a08d617e3e821%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636722664962505455sdata=PC8P3cOYWvFLWmb8uorlEHbf8PgdSnznaRprhrCm1BU%3Dreserved=0
> >> Signed-off-by: Michel Dänzer 
> >> ---
> >>   src/loader/loader_dri3_helper.c | 4 +++-
> >>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/src/loader/loader_dri3_helper.c
> b/src/loader/loader_dri3_helper.c
> >> index 91bad86afd8..6c162553f33 100644
> >> --- a/src/loader/loader_dri3_helper.c
> >> +++ b/src/loader/loader_dri3_helper.c
> >> @@ -1819,7 +1819,9 @@ dri3_get_buffer(__DRIdrawable *driDrawable,
> >> buffer = new_buffer;
> >> draw->buffers[buf_id] = buffer;
> >>  }
> >> -   dri3_fence_await(draw->conn, draw, buffer);
> >> +
> >> +   if (buffer_type == loader_dri3_buffer_back)
> >> +  dri3_fence_await(draw->conn, draw, buffer);
> >>
> >>  /*
> >>   * Do we need to preserve the content of a previous buffer?
> >>
> >
>
> ___
> 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] radv: add Doom workaround

[Mike Lothian]

Do you need the game name here, isn't that set in driconf?

On Wed, 15 Aug 2018 at 12:12 Timothy Arceri  wrote:

> Cc: 
> ---
>  src/amd/vulkan/radv_device.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/amd/vulkan/radv_device.c b/src/amd/vulkan/radv_device.c
> index 33f24b9d302..cc88abb57a8 100644
> --- a/src/amd/vulkan/radv_device.c
> +++ b/src/amd/vulkan/radv_device.c
> @@ -480,6 +480,9 @@ radv_handle_per_app_options(struct radv_instance
> *instance,
>  */
> instance->perftest_flags |= RADV_PERFTEST_SISCHED;
> }
> +   } else if (!strcmp(name, "DOOM_VFR")) {
> +   /* Work around a Doom VFR game bug */
> +   instance->debug_flags |= RADV_DEBUG_NO_DYNAMIC_BOUNDS;
> }
>  }
>
> --
> 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

[Mesa-dev] libdrm: Fix amdgpu build failure

[Mike Lothian]

Hi

I'm not sure if this is the right mailing list or not but the
following patch gets things building with meson again

Signed-of-by: Mike Lothian 

diff --git a/amdgpu/meson.build b/amdgpu/meson.build
index f39d7bf6..d9d7de2d 100644
--- a/amdgpu/meson.build
+++ b/amdgpu/meson.build
@@ -26,8 +26,7 @@ libdrm_amdgpu = shared_library(
   [
 files(
   'amdgpu_asic_id.c', 'amdgpu_bo.c', 'amdgpu_cs.c', 'amdgpu_device.c',
-  'amdgpu_gpu_info.c', 'amdgpu_vamgr.c', 'amdgpu_vm.c', 'util_hash.c',
-  'util_hash_table.c',
+  'amdgpu_gpu_info.c', 'amdgpu_vamgr.c', 'amdgpu_vm.c', 'handle_table.c',
 ),
 config_file,
   ],
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Mesa master branch vulkan/build question

[Mike Lothian]

That's packaged for bionic, might be worth creating your own PPA and base
the pkgbuild on that - apologies if I'm getting the lingo wrong - I don't
use Ubuntu myself

Alternatively maybe check for other PPAs that might have them already
packaged for you, I think Padoka and Oibaf might have what you're after

On Thu, 2 Aug 2018 at 18:00 Guang Bai  wrote:

> On Thu, 2 Aug 2018 17:55:21 +0100
> Mike Lothian  wrote:
>
> > Which distro are you using?
>
> uBuntu-14.045 & uBuntu-16.04
> Thanks,
> Guang
>
> >
> > On Thu, 2 Aug 2018 at 17:35 Guang Bai  wrote:
> >
> > > This is the reason for me to look for helps from our mesa-dev
> > > community. Thanks,
> > > Guang
> > >
> > > On Thu, 2 Aug 2018 17:10:16 +0100
> > > Mike Lothian  wrote:
> > >
> > > > Yeah the lease stuff was added in the newer version of xcb-protos
> > > > I think, I'm surprised the configure didn't error out
> > > >
> > > > On Thu, 2 Aug 2018, 17:07 Guang Bai,  wrote:
> > > >
> > > > > On Thu, 2 Aug 2018 16:54:58 +0100
> > > > > Mike Lothian  wrote:
> > > > >
> > > > > > Hi
> > > > > My mesa build was ok with 18.1 and previous versions and it's
> > > > > just broken with latest master and 18.2.
> > > > >
> > > > > Here are my build errors with 18.2 & master -
> > > > >
> > > > > Thanks,
> > > > > Guang
> > > > >
> > > > >  Making all in vulkan
> > > > > make[3]: Entering directory '.../mesa/src/vulkan'
> > > > >   CC   wsi/wsi_common_display.lo
> > > > >   CCLD libvulkan_util.la
> > > > > ar: `u' modifier ignored since `D' is the default (see `U')
> > > > > wsi/wsi_common_display.c:1134:4: error: unknown field
> > > > > ‘sequence_handler’ specified in initializer
> > > > > .sequence_handler = wsi_display_sequence_handler,
> > > > > ^
> > > > > wsi/wsi_common_display.c:1134:24: warning: initialization from
> > > > > incompatible pointer type [-Wincompatible-pointer-types]
> > > > > .sequence_handler = wsi_display_sequence_handler,
> > > > > ^
> > > > > wsi/wsi_common_display.c:1134:24: note: (near initialization for
> > > > > ‘event_context.page_flip_handler’)
> > > > > wsi/wsi_common_display.c: In function
> > > > > ‘wsi_register_vblank_event’: wsi/wsi_common_display.c:1516:17:
> > > > > error: implicit declaration of function
> > > > > ‘drmCrtcQueueSequence’ [-Werror=implicit-function-declaration]
> > > > > int ret = drmCrtcQueueSequence(wsi->fd, connector->crtc_id, ^
> > > > > wsi/wsi_common_display.c: In function
> > > > > ‘wsi_acquire_xlib_display’: wsi/wsi_common_display.c:2307:4:
> > > > > error: unknown type name ‘xcb_randr_lease_t’
> > > > > xcb_randr_lease_t lease = xcb_generate_id(connection);
> > > > > ^
> > > > > wsi/wsi_common_display.c:2308:4: error: unknown type name
> > > > > ‘xcb_randr_create_lease_cookie_t’
> > > > > xcb_randr_create_lease_cookie_t cl_c =
> > > > > ^
> > > > > wsi/wsi_common_display.c:2309:7: error: implicit declaration of
> > > > > function
> > > > > ‘xcb_randr_create_lease’ [-Werror=implicit-function-declaration]
> > > > > xcb_randr_create_lease(connection, root, lease, 1, 1, ^
> > > > > wsi/wsi_common_display.c:2311:4: error: unknown type name
> > > > > ‘xcb_randr_create_lease_reply_t’
> > > > > xcb_randr_create_lease_reply_t *cl_r =
> > > > > ^
> > > > > wsi/wsi_common_display.c:2312:7: error: implicit declaration of
> > > > > function
> > > > > ‘xcb_randr_create_lease_reply’
> [-Werror=implicit-function-declaration]
> > > > > xcb_randr_create_lease_reply(connection, cl_c, NULL); ^
> > > > > wsi/wsi_common_display.c:2312:7: warning: initialization makes
> > > > > pointer from integer without a cast [-Wint-conversion]
> > > > > wsi/wsi_common_display.c:2317:12: error: request for member
> > > > > ‘nfd’ in something not a structure or union
> > > > > if (cl_r->nfd > 0) {
> > > > > ^
> > > > > wsi/wsi_common_display.c:2318:20: err

Re: [Mesa-dev] Mesa master branch vulkan/build question

[Mike Lothian]

Which distro are you using?

On Thu, 2 Aug 2018 at 17:35 Guang Bai  wrote:

> This is the reason for me to look for helps from our mesa-dev community.
> Thanks,
> Guang
>
> On Thu, 2 Aug 2018 17:10:16 +0100
> Mike Lothian  wrote:
>
> > Yeah the lease stuff was added in the newer version of xcb-protos I
> > think, I'm surprised the configure didn't error out
> >
> > On Thu, 2 Aug 2018, 17:07 Guang Bai,  wrote:
> >
> > > On Thu, 2 Aug 2018 16:54:58 +0100
> > > Mike Lothian  wrote:
> > >
> > > > Hi
> > > My mesa build was ok with 18.1 and previous versions and it's just
> > > broken with latest master and 18.2.
> > >
> > > Here are my build errors with 18.2 & master -
> > >
> > > Thanks,
> > > Guang
> > >
> > >  Making all in vulkan
> > > make[3]: Entering directory '.../mesa/src/vulkan'
> > >   CC   wsi/wsi_common_display.lo
> > >   CCLD libvulkan_util.la
> > > ar: `u' modifier ignored since `D' is the default (see `U')
> > > wsi/wsi_common_display.c:1134:4: error: unknown field
> > > ‘sequence_handler’ specified in initializer
> > > .sequence_handler = wsi_display_sequence_handler,
> > > ^
> > > wsi/wsi_common_display.c:1134:24: warning: initialization from
> > > incompatible pointer type [-Wincompatible-pointer-types]
> > > .sequence_handler = wsi_display_sequence_handler,
> > > ^
> > > wsi/wsi_common_display.c:1134:24: note: (near initialization for
> > > ‘event_context.page_flip_handler’)
> > > wsi/wsi_common_display.c: In function ‘wsi_register_vblank_event’:
> > > wsi/wsi_common_display.c:1516:17: error: implicit declaration of
> > > function
> > > ‘drmCrtcQueueSequence’ [-Werror=implicit-function-declaration] int
> > > ret = drmCrtcQueueSequence(wsi->fd, connector->crtc_id, ^
> > > wsi/wsi_common_display.c: In function ‘wsi_acquire_xlib_display’:
> > > wsi/wsi_common_display.c:2307:4: error: unknown type name
> > > ‘xcb_randr_lease_t’
> > > xcb_randr_lease_t lease = xcb_generate_id(connection);
> > > ^
> > > wsi/wsi_common_display.c:2308:4: error: unknown type name
> > > ‘xcb_randr_create_lease_cookie_t’
> > > xcb_randr_create_lease_cookie_t cl_c =
> > > ^
> > > wsi/wsi_common_display.c:2309:7: error: implicit declaration of
> > > function
> > > ‘xcb_randr_create_lease’ [-Werror=implicit-function-declaration]
> > > xcb_randr_create_lease(connection, root, lease, 1, 1, ^
> > > wsi/wsi_common_display.c:2311:4: error: unknown type name
> > > ‘xcb_randr_create_lease_reply_t’
> > > xcb_randr_create_lease_reply_t *cl_r =
> > > ^
> > > wsi/wsi_common_display.c:2312:7: error: implicit declaration of
> > > function
> > > ‘xcb_randr_create_lease_reply’ [-Werror=implicit-function-declaration]
> > > xcb_randr_create_lease_reply(connection, cl_c, NULL); ^
> > > wsi/wsi_common_display.c:2312:7: warning: initialization makes
> > > pointer from integer without a cast [-Wint-conversion]
> > > wsi/wsi_common_display.c:2317:12: error: request for member ‘nfd’ in
> > > something not a structure or union
> > > if (cl_r->nfd > 0) {
> > > ^
> > > wsi/wsi_common_display.c:2318:20: error: implicit declaration of
> > > function
> > > ‘xcb_randr_create_lease_reply_fds’
> [-Werror=implicit-function-declaration]
> > > int *rcl_f = xcb_randr_create_lease_reply_fds(connection, cl_r); ^
> > > wsi/wsi_common_display.c:2318:20: warning: initialization makes
> > > pointer from integer without a cast [-Wint-conversion]
> > > wsi/wsi_common_display.c: In function ‘wsi_get_swapchain_counter’:
> > > wsi/wsi_common_display.c:2456:14: error: implicit declaration of
> > > function
> > > ‘drmCrtcGetSequence’ [-Werror=implicit-function-declaration] int
> > > ret = drmCrtcGetSequence(wsi->fd, connector->crtc_id, value, NULL);
> > > ^ cc1: some warnings being treated as errors
> > > Makefile:743: recipe for target 'wsi/wsi_common_display.lo' failed
> > > make[3]: *** [wsi/wsi_common_display.lo] Error 1
> > >
> > > > It would be helpful if you posted the failure output, without it
> > > > its difficult to diagnose
> > > >
> > > > I'm not seeing any issues with the master branch on the meson
> > > > build
> > > >
> &

Re: [Mesa-dev] Mesa master branch vulkan/build question

[Mike Lothian]

Hi

It would be helpful if you posted the failure output, without it its
difficult to diagnose

I'm not seeing any issues with the master branch on the meson build

Is this your first time building mesa, or has something suddenly stopped
working?

Cheers

Mike

On Thu, 2 Aug 2018 at 16:46 Guang Bai  wrote:

> All,
>
> I'm seeing build failures on mesa 18.2 & master branches with
> "--with-vulkan-drivers=intel"
>
> And also notice some web-posting that libxcb-xrandr 1.13 would be
> needed to get the build successful.
>
> What's the correct solution for my build issue?
> (I'm still new to mesa)
>
> Thanks!
> Guang
> ___
> 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 0/7] ASTC texture compression for all Gallium drivers

[Mike Lothian]

Hi

Glxinfo reporting things correctly, as does es2info and my GLES apps
continue to work

Are there any apps that explicitly use GLES3.2 that I can test for you?

Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD Radeon R9 M295X (TONGA, DRM 3.27.0, 4.18.0-rc3-agd5f+, LLVM
7.0.0) (0x6921)
Version: 18.2.0
Accelerated: yes
Video memory: 4096MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 4.4
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2

Feel free to add my tested by:

Tested-by: Mike Lothian 

Cheers

Mike

On Tue, 24 Jul 2018 at 00:52 Marek Olšák  wrote:

> Hi,
>
> This series enables ASTC texture compression for all Gallium drivers
> that don't support it in hardware. The works the same as the ETC2
> fallback, i.e. it decompresses ASTC inside glCompressedTexImage to
> a supported uncompressed format.
>
> RadeonSI now finally supports the following:
> - GL_KHR_texture_compression_astc_ldr
> - GL_ANDROID_extension_pack_es31a
> - OpenGL ES 3.2 !!!
>
> All ASTC dEQP tests pass.
>
> Please review.
>
> Thanks,
> 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

[Mesa-dev] Broken Tags

[Mike Lothian]

Hi

Is there any change the following tags could be deleted (and recreated
if required) from the git repo:

R300_DRIVER_0
before_upgrade_03_01_05
blended_fountain
embedded-1-20030120
embedded-1-20030224
embedded-1-20030305
embedded-1-20030324
embedded-1-20030417
embedded-1-20030502
gliding_penguin
jump_and_click
kw-mesa-1
mesa-6_5-20060712
mesa_20050504
mesa_20050526
mesa_20050610
mesa_20050715
mesa_20060201
mesa_20060325
mesa_3_1
mesa_3_1_beta_3
mesa_3_2
mesa_3_2_1
mesa_3_2_beta_1
mesa_3_3
mesa_3_4
mesa_3_4_1
mesa_3_4_2
mesa_3_5
mesa_4_0
mesa_4_0_1
mesa_4_0_2
mesa_4_0_3
mesa_4_0_4
mesa_4_1
mesa_5_0
mesa_5_0_1
mesa_6_3
mesa_6_3_1
mesa_6_3_1_1
mesa_6_3_2
mesa_6_4
mesa_6_4_1
mesa_6_4_2
mesa_6_5
mesa_6_5_1
mesa_6_5_2
mesa_texman_20060210
noisy_cube
red_tinted_cube
rotating_gears
shimmering_gears
start
texman_0_1_20060325
texman_0_1_20060330
texman_0_1_20060621
texman_0_1_20060705
texman_0_1_pre_ttm
texmem_0_2_20060912
texmem_0_3_20060923
texmem_0_3_20060929
the_perfect_frag
trunk_20040329
unichrome-last-xinerama
vtx-0-2-21112003-freeze
vtx-0-2-24112003
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Radeonsi OpenGL 4.4 compat profile support

[Mike Lothian]

Hi

I can confirm Dying Light is still working great with this series, it
doesn't require any overrides and changes to the graphical settings no
longer cause crashes

Tropico 5 also launches and plays with the allow_higher_compat_version option
removed from /etc/drirc (I don't own the other 2 games that have this
option set)

Tested-by: Mike Lothian 

Thanks again for this

On Thu, 28 Jun 2018 at 07:47 Timothy Arceri  wrote:

> Sorry to keep spamming the list with this stuff, but Dave helped
> out with ARB_vertex_attrib_64bit support and the spec bug I
> submitted for indirect compute dispatch was resolved so it
> seemed like a good idea to send it all out again together with
> these updates.
>
> Pretty much everything has corresponding piglit tests, but I've
> also been testing with a few games and I'm now seeing games such
> Doom and Wolfenstein working on wine where previously the version
> overrides were not enough to get them to work.
>
> There has also been a report that proper compat support fixes
> some issues with Dying Light.
>
> Please review.
>
>
> ___
> 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] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

[Mike Lothian]

Hi

I can confirm I no longer need to pass MESA_GL_VERSION_OVERRIDE to Dying
Light

Tested-by: Mike Lothian 

Cheers

Mike

On Tue, 26 Jun 2018 at 04:41 Dieter Nützel  wrote:

> Am 25.06.2018 13:26, schrieb Timothy Arceri:
> > Please note I've fixed up make check where is was broken when enabling
> > some of these extensions. You can see all of the latests compat
> > patches here:
> >
> > https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64
>
> For the whole series
>
> (1-9 from this set,
> Radeonsi OpenGL 4.0 compat profile, 1-5
> and
> mesa: add missing display list support for ARB_compute_shader)
>
> your 'whole' ARB_gpu_shader_fp64 branch
>
> Tested-by: Dieter Nützel 
>
> with KDE Plasma 5, UH, UV, glmark2
>
> OpenGL vendor string: X.Org
> OpenGL renderer string: Radeon RX 580 Series (POLARIS10, DRM 3.25.0,
> 4.17.2-3.g2290680-default, LLVM 7.0.0)
> OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.2.0-devel
> (git-6e8bf98e7e)
> OpenGL core profile shading language version string: 4.50
> OpenGL core profile context flags: (none)
> OpenGL core profile profile mask: core profile
> OpenGL core profile extensions:
> OpenGL version string: 4.4 (Compatibility Profile) Mesa 18.2.0-devel
> (git-6e8bf98e7e)
> OpenGL shading language version string: 4.40
> OpenGL context flags: (none)
> OpenGL profile mask: compatibility profile
> OpenGL extensions:
> OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.2.0-devel
> (git-6e8bf98e7e)
> OpenGL ES profile shading language version string: OpenGL ES GLSL ES
> 3.10
> OpenGL ES profile extensions:
>
> Dieter
>
> > On 22/06/18 18:47, Timothy Arceri wrote:
> >> I've send all of these patches out already. The only change is to the
> >> first 2 patches which fixes things so we store a double as 2 unsigned
> >> ints
> >> rather than 2 floats.
> >>
> >> Everything here has corresponding piglit tests all of which are now
> >> upstream with the exception of the compute shader display list test.
> >>
> >> Our current TODO list has 2 remaining extensions on it before it
> >> should be ok to enable OpenGL 4.4 compat contexts in radeonsi.
> >>
> >>
> >> ___
> >> 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
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

[Mike Lothian]

I'll test these tonight, Dying Light in particular required an override -
hopefully that won't be necessary any more

On Mon, 25 Jun 2018 at 12:26 Timothy Arceri  wrote:

> Please note I've fixed up make check where is was broken when enabling
> some of these extensions. You can see all of the latests compat patches
> here:
>
> https://gitlab.freedesktop.org/tarceri/mesa/commits/ARB_gpu_shader_fp64
>
> On 22/06/18 18:47, Timothy Arceri wrote:
> > I've send all of these patches out already. The only change is to the
> > first 2 patches which fixes things so we store a double as 2 unsigned
> ints
> > rather than 2 floats.
> >
> > Everything here has corresponding piglit tests all of which are now
> > upstream with the exception of the compute shader display list test.
> >
> > Our current TODO list has 2 remaining extensions on it before it
> > should be ok to enable OpenGL 4.4 compat contexts in radeonsi.
> >
> >
> > ___
> > 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] Enable/fix a bunch of OpenGL 4.0-4.3 extensions for compat profile

[Mike Lothian]

I think you forgot to bump PIPE_CAP_GLSL_FEATURE_LEVEL_COMPATIBILITY to 430

On Fri, 22 Jun 2018 at 09:48 Timothy Arceri  wrote:

> I've send all of these patches out already. The only change is to the
> first 2 patches which fixes things so we store a double as 2 unsigned ints
> rather than 2 floats.
>
> Everything here has corresponding piglit tests all of which are now
> upstream with the exception of the compute shader display list test.
>
> Our current TODO list has 2 remaining extensions on it before it
> should be ok to enable OpenGL 4.4 compat contexts in radeonsi.
>
>
> ___
> 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/2] mesa: remove drirc workarounds for Worms, Tropico 5 and Crookz

[Mike Lothian]

I've just checked myself - this isn't in i965 yet:


Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)  (0x191b)
Version: 18.2.0
Accelerated: yes
Video memory: 3072MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2


Extended renderer info (GLX_MESA_query_renderer):
Vendor: X.Org (0x1002)
Device: AMD Radeon R9 M295X (TONGA, DRM 3.26.0, 4.17.0-rc5-agd5f+, LLVM
7.0.0) (0x6921)
Version: 18.2.0
Accelerated: yes
Video memory: 4096MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.3
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1



On Fri, 22 Jun 2018 at 14:28 Mike Lothian  wrote:

> Hi
>
> Does the whole of mesa support that or just radeonsi?
>
> Cheers
>
> Mike
>
> On Fri, 22 Jun 2018 at 14:10 Samuel Pitoiset 
> wrote:
>
>> Since mesa now exposes OpenGL 3.3 compat, we no longer need
>> those workarounds.
>>
>> Signed-off-by: Samuel Pitoiset 
>> ---
>>  src/util/drirc | 12 
>>  1 file changed, 12 deletions(-)
>>
>> diff --git a/src/util/drirc b/src/util/drirc
>> index 7f91035ae8..e50ec81865 100644
>> --- a/src/util/drirc
>> +++ b/src/util/drirc
>> @@ -120,18 +120,6 @@ TODO: document the other workarounds.
>>  > value="true" />
>>  
>>
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>> -
>>  
>>  
>>  
>> --
>> 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] [PATCH 1/2] mesa: remove drirc workarounds for Worms, Tropico 5 and Crookz

[Mike Lothian]

Hi

Does the whole of mesa support that or just radeonsi?

Cheers

Mike

On Fri, 22 Jun 2018 at 14:10 Samuel Pitoiset 
wrote:

> Since mesa now exposes OpenGL 3.3 compat, we no longer need
> those workarounds.
>
> Signed-off-by: Samuel Pitoiset 
> ---
>  src/util/drirc | 12 
>  1 file changed, 12 deletions(-)
>
> diff --git a/src/util/drirc b/src/util/drirc
> index 7f91035ae8..e50ec81865 100644
> --- a/src/util/drirc
> +++ b/src/util/drirc
> @@ -120,18 +120,6 @@ TODO: document the other workarounds.
>   value="true" />
>  
>
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -
> -
>  
>  
>  
> --
> 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

[Mesa-dev] [PATCH] meson: allow x86 asm on x86_64 cross compiles

[Mike Lothian]

This patch allows building asm for x86 on x86_64 cross compiles

Fixes: 2d62fc064652 ("meson: disable x86 asm in fewer cases.")
Signed-off-by: Mike Lothian 

---

If you're happy with this change, please can you commit it as I don't
have access
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 4d4ca5d557..9f2d836e80 100644
--- a/meson.build
+++ b/meson.build
@@ -846,7 +846,7 @@ endif
 # TODO: it should be possible to use an exe_wrapper to run the binary during
 # the build. 
 if meson.is_cross_build() 
-  if not (build_machine.cpu_family() == 'x86_64' and host_machine.cpu_family() 
== 'x86'
+  if not (build_machine.cpu_family() == 'x86' and host_machine.cpu_family() == 
'x86'
   and build_machine.system() == host_machine.system())
 message('Cross compiling to x86 from non-x86, disabling asm')
 with_asm = false
-- 
2.17.1

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

Re: [Mesa-dev] [PATCH 00/16] Move the Mesa Website to Sphinx

[Mike Lothian]

Hi

Is it possible to get all 3 gears lined up under the points of the "M" and
have the 3rd gear go under the "e" if need be

Cheers

Mike

On Thu, 7 Jun 2018 at 10:02 Erik Faye-Lund  wrote:

> Just as a fun toy, I decided to give an animated SVG "variation" of
> this a go myself:
>
> https://codepen.io/kusma/pen/vrXppL
>
> The actual SVG can be found here:
>
> https://gitlab.freedesktop.org/snippets/492
>
> The gears were generated by this python script, based on the glxgears
> source code:
>
> https://gitlab.freedesktop.org/snippets/491
>
> Now, dropping this onto the black background doesn't work that well,
> as it gets a bit bland, so it's probably better to add back the colors
> then.
>
> Also, I'm not really sure if animation is a good idea or not. But I
> definitely think logos should be vector rather than raster ;)
>
> On Sun, Jun 3, 2018 at 1:49 AM, Jason Ekstrand 
> wrote:
> > With all this talk of fancy looking new websites, I decided to take a
> crack
> > at being artsy and coming up with a fancy-looking logo to put on it.
> Here's
> > a first rough draft:
> >
> > https://people.freedesktop.org/~jekstrand/gears-logo-bold.png
> >
> > It's not great but it turned out better than I expected.  That version
> looks
> > good on a light background but it could probably be tweaked to look good
> on
> > dark/black if we want.
> >
> > --Jason
> >
> >
> >
> > On Fri, Jun 1, 2018 at 2:46 AM, Eric Engestrom  >
> > wrote:
> >>
> >> On Thursday, 2018-05-31 21:33:16 -0400,
> >> mesa-dev-boun...@lists.freedesktop.org wrote:
> >> > On Thu, May 31, 2018 at 8:31 PM, Jordan Justen
> >> >  wrote:
> >> > > On 2018-05-31 16:06:13, Laura Ekstrand wrote:
> >> > >> A little bit of messing around this afternoon, led to this:
> >> > >>
> >> > >>
> https://drive.google.com/file/d/1rteTv9415XEMN1E11fyN0l3hTUCCbgwz/view?usp=sharing
> >> > >
> >> > > Nice. That confirms we can easily get back to a something closer to
> >> > > the older look in short order. (Unless the consensus is to actually
> >> > > stay with the generic look.)
> >> > >
> >> > >> The gears are from Font Awesome, which comes with the RTD format.
> >> > >
> >> > > It'd be nice to get the icon back, but the gear glyph is an
> >> > > improvement compared to the house glyph.
> >> > >
> >> > > Anyway, I stick by what I said below too in reply to Eric about
> >> > > withdrawing my feedback.
> >> >
> >> > my $0.02 (which is probably worth even less when it comes to the topic
> >> > of aesthetics), Laura's new proposal looks much nicer than generic rtd
> >> > which looks better than current site..
> >> >
> >> > I mostly don't want to get a much needed infrastructure/process
> >> > improvement derailed with a bikeshed discussion about themes.  Nothing
> >> > against playing with theme options and seeing what people (with better
> >> > taste than me) like, just don't want that to be something that derails
> >> > the bigger picture ;-)
> >>
> >> Entirely agreed. I also think the old style was distinctive and had
> >> become part of the "personality" of our website, and I would like the
> >> new website to look similar, but this is a minor detail that we can
> >> trivially alter later.
> >>
> >> For now let's focus on the infrastructure changes, discussing the style
> >> can be done in parallel or later, but shouldn't block this.
> >>
> >> >
> >> > BR,
> >> > -R
> >> >
> >> >
> >> > >
> >> > > Thanks,
> >> > >
> >> > > -Jordan
> >> > >
> >> > >> On Thu, May 31, 2018 at 1:55 PM, Jordan Justen
> >> > >> 
> >> > >> wrote:
> >> > >>
> >> > >> > On 2018-05-31 12:27:04, Eric Anholt wrote:
> >> > >> > > Jordan Justen  writes:
> >> > >> > >
> >> > >> > > > On 2018-05-24 17:37:09, Laura Ekstrand wrote:
> >> > >> > > >> A few of the commits are quite large and awaiting list
> >> > >> > > >> approval.  I
> >> > >> > suggest
> >> > >> > > >> that you take a look at the code here:
> >> > >> > > >> https://gitlab.freedesktop.org/ldeks/mesa/tree/website1_75,
> >> > >> > > >> and the new website here: https://mesa-test.freedesktop.
> >> > >> > org/index.html
> >> > >> > > >
> >> > >> > > > I think the theme should be changed to look somewhat close to
> >> > >> > > > the
> >> > >> > > > current mesa3d.org website before changing the main site.
> >> > >> > > > (Color
> >> > >> > > > scheme and missing icons.)
> >> > >> > > >
> >> > >> > > > Right now the test website looks like a million other sphinx
> >> > >> > > > websites,
> >> > >> > > > including every readthedocs book.
> >> > >> > > >
> >> > >> > > > Based on http://www.sphinx-doc.org/en/master/ and
> >> > >> > > > https://www.python.org/, I would say sphinx gives a lot of
> >> > >> > > > opportunities for a custom look.
> >> > >> > >
> >> > >> > > I think looking like a generic other sphinx website is a step
> >> > >> > > forward,
> >> > >> > > and I look forward to this series landing.  No need for
> >> > >> > > continuity with
> >> > >> > > the old theme.
> >> > >> >
> >> > >> > I think it is 1 step forward, 1 step back. As no 

Re: [Mesa-dev] [PATCH 4/5] egl/wayland: Allow client->server format conversion for PRIME offload.

[Mike Lothian]

Hi Mario

Can you explain how I can test this? I'll test it out on an Intel+AMD system

Cheers

Mike

On Wed, 23 May 2018 at 05:51 Mario Kleiner 
wrote:

> On Mon, May 21, 2018 at 4:42 PM, Eric Engestrom
>  wrote:
> > On Saturday, 2018-05-19 05:32:41 +0200, Mario Kleiner wrote:
> >> Support PRIME render offload between a Wayland server gpu and a Wayland
> >> client gpu with different channel ordering for their color formats,
> >> e.g., between Intel drivers which currently only support ARGB2101010
> >> and XRGB2101010 import/display and nouveau which only supports
> ABGR2101010
> >> rendering and display on nv-50 and later.
> >>
> >> In the wl_visuals table, we also store for each format an alternate
> >> sibling format which stores colors at the same precision, but with
> >> different channel ordering, e.g., ARGB2101010 <-> ABGR2101010.
> >>
> >> If a given client-gpu renderable format is not supported by the server
> >> for import, but the alternate format is supported by the server, expose
> >> the client-gpu renderable format as a valid EGLConfig to the client. At
> >> eglSwapBuffers time, during the blitImage() detiling blit from the
> client
> >> backbuffer to the linear buffer, the client format is converted to the
> >> server supported format. As we have to do a copy for PRIME anyway,
> >> this channel swizzling conversion comes essentially for free.
> >>
> >> Note that even if a server gpu in principle does support sampling
> >> from the clients native format, this conversion will be a performance
> >> advantage if it allows to convert to the servers preferred format
> >> for direct scanout, as the Wayland compositor may then be able to
> >> directly page-flip a fullscreen client wl_buffer onto the primary
> >> plane, or onto a hardware overlay plane, avoiding an extra data copy
> >> for desktop composition.
> >>
> >> Tested so far under Weston with: nouveau single-gpu, Intel single-gpu,
> >> AMD single-gpu, "Optimus" Intel server iGPU for display + NVidia
> >> client dGPU for rendering.
> >>
> >> Signed-off-by: Mario Kleiner 
> >> Cc: Daniel Stone 
> >> ---
> >>  src/egl/drivers/dri2/platform_wayland.c | 67
> -
> >>  1 file changed, 58 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/src/egl/drivers/dri2/platform_wayland.c
> b/src/egl/drivers/dri2/platform_wayland.c
> >> index 89a7f90118..fb364a6233 100644
> >> --- a/src/egl/drivers/dri2/platform_wayland.c
> >> +++ b/src/egl/drivers/dri2/platform_wayland.c
> >> @@ -68,49 +68,50 @@ static const struct dri2_wl_visual {
> >> uint32_t wl_drm_format;
> >> uint32_t wl_shm_format;
> >> int dri_image_format;
> >> +   int alt_dri_image_format;
> >
>
> Thanks for the review.
>
> > A comment here wouldn't hurt, to explain what this "alt" is to someone
> > who sees the code after it landed :)
> >
>
> Will do, although i usually feel a bit guilty that my patches usually
> suffer from over-commenting and essay length commit messages :)
>
> >> int bpp;
> >> unsigned int rgba_masks[4];
> >>  } dri2_wl_visuals[] = {
> >> {
> >>   "XRGB2101010",
> >>   WL_DRM_FORMAT_XRGB2101010, WL_SHM_FORMAT_XRGB2101010,
> >> - __DRI_IMAGE_FORMAT_XRGB2101010, 32,
> >> + __DRI_IMAGE_FORMAT_XRGB2101010, __DRI_IMAGE_FORMAT_XBGR2101010,
> 32,
> >>   { 0x3ff0, 0x000ffc00, 0x03ff, 0x }
> >> },
> >> {
> >>   "ARGB2101010",
> >>   WL_DRM_FORMAT_ARGB2101010, WL_SHM_FORMAT_ARGB2101010,
> >> - __DRI_IMAGE_FORMAT_ARGB2101010, 32,
> >> + __DRI_IMAGE_FORMAT_ARGB2101010, __DRI_IMAGE_FORMAT_ABGR2101010,
> 32,
> >>   { 0x3ff0, 0x000ffc00, 0x03ff, 0xc000 }
> >> },
> >> {
> >>   "XBGR2101010",
> >>   WL_DRM_FORMAT_XBGR2101010, WL_SHM_FORMAT_XBGR2101010,
> >> - __DRI_IMAGE_FORMAT_XBGR2101010, 32,
> >> + __DRI_IMAGE_FORMAT_XBGR2101010, __DRI_IMAGE_FORMAT_XRGB2101010,
> 32,
> >>   { 0x03ff, 0x000ffc00, 0x3ff0, 0x }
> >> },
> >> {
> >>   "ABGR2101010",
> >>   WL_DRM_FORMAT_ABGR2101010, WL_SHM_FORMAT_ABGR2101010,
> >> - __DRI_IMAGE_FORMAT_ABGR2101010, 32,
> >> + __DRI_IMAGE_FORMAT_ABGR2101010, __DRI_IMAGE_FORMAT_ARGB2101010,
> 32,
> >>   { 0x03ff, 0x000ffc00, 0x3ff0, 0xc000 }
> >> },
> >> {
> >>   "XRGB",
> >>   WL_DRM_FORMAT_XRGB, WL_SHM_FORMAT_XRGB,
> >> - __DRI_IMAGE_FORMAT_XRGB, 32,
> >> + __DRI_IMAGE_FORMAT_XRGB, __DRI_IMAGE_FORMAT_NONE, 32,
> >>   { 0x00ff, 0xff00, 0x00ff, 0x }
> >> },
> >> {
> >>   "ARGB",
> >>   WL_DRM_FORMAT_ARGB, WL_SHM_FORMAT_ARGB,
> >> - __DRI_IMAGE_FORMAT_ARGB, 32,
> >> + __DRI_IMAGE_FORMAT_ARGB, __DRI_IMAGE_FORMAT_NONE, 32,
> >>   { 0x00ff, 0xff00, 0x00ff, 0xff00 }
> >> },
> >> {
> >>   "RGB565",
> >>   

Re: [Mesa-dev] [PATCH] dri3: Stricter SBC wraparound handling

[Mike Lothian]

I had hoped this would land in 18.1.0

Any signs of a review and can we get this backported asap?

On Wed, 16 May 2018, 15:49 Michel Dänzer, <mic...@daenzer.net> wrote:

> On 2018-05-16 01:39 PM, Mike Lothian wrote:
> > Can this be added to stable too?
>
> Right, I meant add that but forgot, thanks for the reminder. Consider it
> done.
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] dri3: Stricter SBC wraparound handling

[Mike Lothian]

Can this be added to stable too?

On Wed, 16 May 2018 at 10:33 Michel Dänzer  wrote:

> On 2018-05-16 11:14 AM, Axel Davy wrote:
> > Hi,
> >
> > Shouldn't this be fixed on the xserver or the ddx side, rather than in
> > Mesa ?
> No, it's a Mesa bug, the X server is doing what it's asked. (This wasn't
> noticed earlier because Xorg drivers using the old DRM_IOCTL_WAIT_VBLANK
> ioctl effectively ignore the upper 32 bits of the target MSC value).
>
>
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> 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] glx/dri: Take an extra reference on our own GLX drawables

[Mike Lothian]

With Michel's suggestion I've not seen a freeze in Plasmashell or Steam so
far

Tested-by: Mike Lothian <m...@fireburn.co.uk>

On Wed, 9 May 2018 at 21:47 Mike Lothian <m...@fireburn.co.uk> wrote:

> On Tue, 8 May 2018 at 20:47 Adam Jackson <a...@redhat.com> wrote:
>
>> dri*_bind_context, when switching current drawables, will drop the
>> reference on the old one; since that refcount has probably now gone to
>> zero that means we lose all the state we applied to that drawable
>> before, like when swaps are expected to complete.
>>
>> Dropping this reference might make some sense for drawables that aren't
>> _ours_, since we don't get events for destroyed resources and need to
>> rely on the server throwing errors when we name a no-longer-valid
>> drawable. But if the resource is one that this client created, we can be
>> reasonably sure that it will be explicitly destroyed by the same client
>> - and if not, the client is likely to exit anyway, so the memory leak
>> doesn't matter.
>>
>> So, bump the refcnt if the XID of the drawable indicates that it's one
>> of ours. This is, admittedly, a hack. The proper solution would involve
>> rather more surgery to the MakeCurrent path than I can type quickly, let
>> alone test promptly against a wide enough range of servers and DRIs to
>> have any confidence in. I'll work on the real solution, but in the
>> meantime this is effectively not a memory leak for any real scenario,
>> and fixes a real bug.
>>
>> Signed-off-by: Adam Jackson <a...@redhat.com>
>> Cc: Michel Dänzer <michel.daen...@amd.com>
>> Cc: Mike Lothian <m...@fireburn.co.uk>
>> Cc: Mario Kleiner <mario.kleiner...@gmail.com>
>> Cc: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106351
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106372
>> ---
>>  src/glx/dri_common.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
>> index ab5d6c5bc0..d42ca71124 100644
>> --- a/src/glx/dri_common.c
>> +++ b/src/glx/dri_common.c
>> @@ -411,7 +411,8 @@ driInferDrawableConfig(struct glx_screen *psc,
>> GLXDrawable draw)
>>  _X_HIDDEN __GLXDRIdrawable *
>>  driFetchDrawable(struct glx_context *gc, GLXDrawable glxDrawable)
>>  {
>> -   struct glx_display *const priv = __glXInitialize(gc->psc->dpy);
>> +   Display *dpy = gc->psc->dpy;
>> +   struct glx_display *const priv = __glXInitialize(dpy);
>> __GLXDRIdrawable *pdraw;
>> struct glx_screen *psc;
>> struct glx_config *config = gc->config;
>> @@ -449,6 +450,8 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable
>> glxDrawable)
>>return NULL;
>> }
>> pdraw->refcount = 1;
>> +   if ((glxDrawable & dpy->resource_mask) == dpy->resource_base)
>> +  pdraw->refcount ++;
>>
>> return pdraw;
>>  }
>> --
>> 2.17.0
>>
>>
> Hi
>
> This doesn't fix the freezes in Plasmashell
>
> Both of Mario's patches improved things
>
> Regards
>
> Mike
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] glx/dri: Take an extra reference on our own GLX drawables

[Mike Lothian]

On Tue, 8 May 2018 at 20:47 Adam Jackson <a...@redhat.com> wrote:

> dri*_bind_context, when switching current drawables, will drop the
> reference on the old one; since that refcount has probably now gone to
> zero that means we lose all the state we applied to that drawable
> before, like when swaps are expected to complete.
>
> Dropping this reference might make some sense for drawables that aren't
> _ours_, since we don't get events for destroyed resources and need to
> rely on the server throwing errors when we name a no-longer-valid
> drawable. But if the resource is one that this client created, we can be
> reasonably sure that it will be explicitly destroyed by the same client
> - and if not, the client is likely to exit anyway, so the memory leak
> doesn't matter.
>
> So, bump the refcnt if the XID of the drawable indicates that it's one
> of ours. This is, admittedly, a hack. The proper solution would involve
> rather more surgery to the MakeCurrent path than I can type quickly, let
> alone test promptly against a wide enough range of servers and DRIs to
> have any confidence in. I'll work on the real solution, but in the
> meantime this is effectively not a memory leak for any real scenario,
> and fixes a real bug.
>
> Signed-off-by: Adam Jackson <a...@redhat.com>
> Cc: Michel Dänzer <michel.daen...@amd.com>
> Cc: Mike Lothian <m...@fireburn.co.uk>
> Cc: Mario Kleiner <mario.kleiner...@gmail.com>
> Cc: Tobias Klausmann <tobias.johannes.klausm...@mni.thm.de>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106351
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106372
> ---
>  src/glx/dri_common.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/glx/dri_common.c b/src/glx/dri_common.c
> index ab5d6c5bc0..d42ca71124 100644
> --- a/src/glx/dri_common.c
> +++ b/src/glx/dri_common.c
> @@ -411,7 +411,8 @@ driInferDrawableConfig(struct glx_screen *psc,
> GLXDrawable draw)
>  _X_HIDDEN __GLXDRIdrawable *
>  driFetchDrawable(struct glx_context *gc, GLXDrawable glxDrawable)
>  {
> -   struct glx_display *const priv = __glXInitialize(gc->psc->dpy);
> +   Display *dpy = gc->psc->dpy;
> +   struct glx_display *const priv = __glXInitialize(dpy);
> __GLXDRIdrawable *pdraw;
> struct glx_screen *psc;
> struct glx_config *config = gc->config;
> @@ -449,6 +450,8 @@ driFetchDrawable(struct glx_context *gc, GLXDrawable
> glxDrawable)
>return NULL;
> }
> pdraw->refcount = 1;
> +   if ((glxDrawable & dpy->resource_mask) == dpy->resource_base)
> +  pdraw->refcount ++;
>
> return pdraw;
>  }
> --
> 2.17.0
>
>
Hi

This doesn't fix the freezes in Plasmashell

Both of Mario's patches improved things

Regards

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

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

Thank you for the clarification.

On Sat, 5 May 2018 at 14:31 Daniel Stone <dan...@fooishbar.org> wrote:

> On 5 May 2018 at 10:15, Mike Lothian <m...@fireburn.co.uk> wrote:
> > Out of interest can you try running the vulkan smoketest, I'm seeing
> this:
> >
> > smoketest
> > terminate called after throwing an instance of 'std::runtime_error'
> >  what():  VkResult -101004 returned
> > Aborted (core dumped)
>
> VK_ERROR_OUT_OF_DATE_KHR is returned from vkQueuePresentKHR when the
> application _must_ recreate the swapchain it uses for rendering.
> Usually this happens due to the window resizing (which the window
> manager can do), which Vulkan apps _must_ handle themselves. The
> smoketest chooses to handle this error by crashing.
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

Which is:

VK_ERROR_OUT_OF_DATE_KHR = -101004,


On Sat, 5 May 2018 at 10:15 Mike Lothian <m...@fireburn.co.uk> wrote:

> Out of interest can you try running the vulkan smoketest, I'm seeing this:
>
> smoketest
> terminate called after throwing an instance of 'std::runtime_error'
>  what():  VkResult -101004 returned
> Aborted (core dumped)
>
> On Sat, 5 May 2018 at 05:25 Mario Kleiner <mario.kleiner...@gmail.com>
> wrote:
>
>> On Sat, May 5, 2018 at 4:08 AM, Mike Lothian <m...@fireburn.co.uk> wrote:
>> > I definately saw the steam bug with patch 1 but not with plasmashell,
>> > I started seeing it with patch 2 but it seemed to fix itself
>> >
>>
>> I had two hangs of kwin_x11 within the last 6 hours when alt-tabbing
>> between windows, where it got stuck in the
>> loader_dri3_swapbuffer_barrier() from patch 1/2. Not sure how that is
>> possible, or if the stacktrace was misleading, because i had to VT
>> switch to a text console to attach the debugger and this might be just
>> a side effect of that. But if it is true, then patch 1/2 would not be
>> it. Also 1/2 has a potential performance impact, whereas 2/2 doesn't.
>> However 2/2 would also need more work, as i can think of more complex
>> scenarios where it would filter the wrong events, although not in the
>> case of plasmashell or steam. Probably we'd need to sacrifice a few
>> sbc bits in the Present events serial field to transport a unique tag
>> for each incarnation of the loader_dri3_drawable, like a mini-hash of
>> the draw->eid. Ugly ugly...
>>
>> -mario
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

Out of interest can you try running the vulkan smoketest, I'm seeing this:

smoketest
terminate called after throwing an instance of 'std::runtime_error'
 what():  VkResult -101004 returned
Aborted (core dumped)

On Sat, 5 May 2018 at 05:25 Mario Kleiner <mario.kleiner...@gmail.com>
wrote:

> On Sat, May 5, 2018 at 4:08 AM, Mike Lothian <m...@fireburn.co.uk> wrote:
> > I definately saw the steam bug with patch 1 but not with plasmashell,
> > I started seeing it with patch 2 but it seemed to fix itself
> >
>
> I had two hangs of kwin_x11 within the last 6 hours when alt-tabbing
> between windows, where it got stuck in the
> loader_dri3_swapbuffer_barrier() from patch 1/2. Not sure how that is
> possible, or if the stacktrace was misleading, because i had to VT
> switch to a text console to attach the debugger and this might be just
> a side effect of that. But if it is true, then patch 1/2 would not be
> it. Also 1/2 has a potential performance impact, whereas 2/2 doesn't.
> However 2/2 would also need more work, as i can think of more complex
> scenarios where it would filter the wrong events, although not in the
> case of plasmashell or steam. Probably we'd need to sacrifice a few
> sbc bits in the Present events serial field to transport a unique tag
> for each incarnation of the loader_dri3_drawable, like a mini-hash of
> the draw->eid. Ugly ugly...
>
> -mario
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

 src/loader/loader_dri3_helper.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
index 23729f7ecb..2b2a8d21d8 100644
--- a/src/loader/loader_dri3_helper.c
+++ b/src/loader/loader_dri3_helper.c
@@ -26,6 +26,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 
 #include 
@@ -234,6 +235,10 @@ loader_dri3_drawable_fini(struct
loader_dri3_drawable *draw)
 {
int i;

+   printf("FINI: wxh = %d x %d, drawable %d eid %d recv_sbc %lu,
send_sbc %lu PENDING %lu\n",
+  draw->width, draw->height, draw->drawable, draw->eid,
draw->recv_sbc, draw->send_sbc,
+  draw->send_sbc - draw->recv_sbc);
+
draw->ext->core->destroyDrawable(draw->dri_drawable);

for (i = 0; i < ARRAY_SIZE(draw->buffers); i++) {
@@ -370,6 +375,15 @@ dri3_handle_present_event(struct
loader_dri3_drawable *draw,
* checking for wrap.
*/
   if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
+ /* Filter out orphan events sent for a previous incarnation
of draw. */
+ if (!(draw->send_sbc & 0xLL) &&
+ ce->serial > draw->send_sbc) {
+printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
+   draw->width, draw->height, draw->drawable, ce->serial,
+   draw->send_sbc);
+break;
+ }
+
  draw->recv_sbc = (draw->send_sbc & 0xLL) | ce->serial;
  if (draw->recv_sbc > draw->send_sbc)
 draw->recv_sbc -= 0x1;
@@ -415,6 +429,15 @@ dri3_handle_present_event(struct
loader_dri3_drawable *draw,
   xcb_present_idle_notify_event_t *ie = (void *) ge;
   int b;

+  /* Filter out orphan events sent for a previous incarnation of draw. */
+  if (!(draw->send_sbc & 0xLL) &&
+  ie->serial > draw->send_sbc) {
+ printf("ORPHAN-I: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
+draw->width, draw->height, draw->drawable, ie->serial,
+draw->send_sbc);
+ break;
+  }
+
   for (b = 0; b < ARRAY_SIZE(draw->buffers); b++) {
  struct loader_dri3_buffer *buf = draw->buffers[b];

@@ -1432,6 +1455,8 @@ dri3_update_drawable(__DRIdrawable *driDrawable,
  xcb_unregister_for_special_event(draw->conn, draw->special_event);
  draw->special_event = NULL;
   }
+
+  printf("INIT: wxh = %d x %d, drawable %d eid %d\n",
draw->width, draw->height, draw->drawable, draw->eid);
}
dri3_flush_present_events(draw);
mtx_unlock(>mtx);
-- 
2.17.0

On 4 May 2018 at 17:54, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
> On Fri, May 4, 2018 at 6:45 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
>> Hi
>>
>> The first hunk doesn't apply, the other 3 gives this with GCC 8.1
>>
>
> Oops, the perils of applying debug patches on top of debug patches...
>
> Can you add a...
>
> #include 
>
> at the top of the file, e.g, after '#include 
>
>  #include 
>  #include 
>  #include 
> -
> +#include 
>  #include 
>  #include 
>  #include 
>
> Then it should compile, albeit with some format warnings, but those
> shouldn't affect the outcome.
> -mario
>
>>
>> ../mesa-/src/loader/loader_dri3_helper.c: In function
>> ‘dri3_handle_present_event’:
>> ../mesa-/src/loader/loader_dri3_helper.c:376:13: error: implicit
>> declaration of function ‘printf’
>> [-Werror=implicit-function-declaration]
>>  printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc 
>> %lu\n",
>>  ^~
>> ../mesa-/src/loader/loader_dri3_helper.c:376:13: warning:
>> incompatible implicit declaration of built-in function ‘printf’
>> ../mesa-/src/loader/loader_dri3_helper.c:376:13: note: include
>> ‘’ or provide a declaration of ‘printf’
>> ../mesa-/src/loader/loader_dri3_helper.c:39:1:
>> +#include 
>>
>> ../mesa-/src/loader/loader_dri3_helper.c:376:13:
>>  printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc 
>> %lu\n",
>>  ^~
>> ../mesa-/src/loader/loader_dri3_helper.c:376:75: warning: format
>> ‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has
>> type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
>>  printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc 
>> %lu\n",
>>  ~~^
>>  

Re: [Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

Hi

Yes I've not seen any freezes with Plasmashell, so a big improvement

Had issues with patch 2

Cheers

Mike

On 4 May 2018 at 17:36, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
> On Fri, May 4, 2018 at 6:31 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
>> Hi
>>
>> I'm still seeing the freeze in the Steam client with this patch
>>
>> Just about to test the other one
>>
>
> Thanks for testing. So the plasmashell hang is gone, right?
> Maybe the steam issue is a different bug. With *only* patch 2/2
> applied, seing ORPHAN printouts would hint at a similar problem,
> absence of them would probably mean something else.
>
> -mario
>
>> Mike
>>
>> On 4 May 2018 at 17:17, Mike Lothian <m...@fireburn.co.uk> wrote:
>>> Hi Mario
>>>
>>> Again thanks for looking into this issue :D
>>>
>>> Tested-by: Mike Lothian <m...@fireburn.co.uk>
>>>
>>> I'll give the other patch a whirl now
>>>
>>> Cheers
>>>
>>> Mike
>>>
>>> On 4 May 2018 at 14:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
>>>> Before destroying the loader_dri3_drawable, make sure all pending
>>>> swaps for it have completed. This guides against the following scenario,
>>>> which happens, e.g., with KDE Plasma-5's plasmashell (which uses
>>>> QT-5's QtGui/QtQuick for rendering), when it repaints multiple
>>>> UI elements, each represented by its own Window/GLXDrawable, using
>>>> one common GLXContext for all GLXDrawable's:
>>>>
>>>> 1. glXMakeCurrent(dpy, drawable1, context);
>>>> 2. glXXX render to drawable1
>>>> 3. glXSwapBuffers(dpy, drawable1); #1
>>>> 4. glXMakeCurrent(dpy, drawable2, context);
>>>> 5. glXXX render to drawable2
>>>> 6. glXSwapBuffers(dpy, drawable2);
>>>> // While the swap #1 is still pending for drawable1:
>>>> 7. glXMakeCurrent(dpy, drawable1, context);
>>>> 8. glXXX render to drawable1
>>>> 9. glXSwapBuffers(dpy, drawable1);
>>>>
>>>> Binding a different drawable2 to the same context via glXMakeCurrent
>>>> will cause its previous drawable1 to be released (cfe. dri3_bind_context
>>>> -> driReleaseDrawables), which in turn calls loader_dri3_drawable_fini().
>>>> This unselects for Present notify event delivery on the associated
>>>> X-Window and loses all dri3 related state. If drawable1 is selected for
>>>> the context again [7], a new incarnation of loader_dri3_drawable is
>>>> created in dri3_bind_context->driFetchDrawable->dri3_create_drawable->
>>>> loader_dri3_drawable_init(), which again selects for Present notify
>>>> event delivery for the underlying X-Window, but the new incarnation lost
>>>> all state wrt. to previous rendering and swaps. The server now delivers
>>>> PresentPixmapIdle and PresentPixmapComplete events from the completed
>>>> previous swapbuffers call #1 [3] to the new loader_dri3_drawable, which
>>>> doesn't expect those. One problem is that the new incarnation has a
>>>> draw->send_sbc == 0, but now receives PresentPixmapComplete events with
>>>> sbc's > 0, therefore updating draw->recv_sbc to > 0 in
>>>> dri3_handle_present_event(). The draw->recv_sbc > draw_send_sbc is
>>>> misinterpreted as sbc wraparound, triggers recv_sbc wraparound handling
>>>> and ends up with a very large draw->recv_sbc. During the next swapbuffers
>>>> call [9], the totally wrong recv_sbc is used for calculating the target_msc
>>>> for the PresentPixmap request, leading to a target_msc billions of vblanks
>>>> in the future, leading to a swap that never completes and thereby frozen UI
>>>> and hang of the client.
>>>>
>>>> Make sure that a loader_dri3_drawable can only be destroyed after all
>>>> its pending swaps have completed, to prevent misdelivery of PresentNotify
>>>> events to the right X-Window, but the wrong incarnation of the associated
>>>> loader_dri3_drawable.
>>>>
>>>> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
>>>> Cc: xorg-de...@lists.x.org
>>>> Cc: dan...@fooishbar.org
>>>> Cc: eero.t.tammi...@intel.com
>>>> Cc: m...@fireburn.co.uk
>>>> ---
>>>>  src/loader/loader_dri3_helper.c | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/src/loader/loader_dri3_helper.c 
>>>> b/src/loader/loader_dri3_helper.c
>>>> index 6bb11c4..7bd79af 100644
>>>> --- a/src/loader/loader_dri3_helper.c
>>>> +++ b/src/loader/loader_dri3_helper.c
>>>> @@ -234,6 +234,9 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable 
>>>> *draw)
>>>>  {
>>>> int i;
>>>>
>>>> +   if (draw->special_event)
>>>> +  loader_dri3_swapbuffer_barrier(draw);
>>>> +
>>>> draw->ext->core->destroyDrawable(draw->dri_drawable);
>>>>
>>>> for (i = 0; i < ARRAY_SIZE(draw->buffers); i++) {
>>>> --
>>>> 2.7.4
>>>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] loader_dri3: Variant 2: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

Hi

The first hunk doesn't apply, the other 3 gives this with GCC 8.1


../mesa-/src/loader/loader_dri3_helper.c: In function
‘dri3_handle_present_event’:
../mesa-/src/loader/loader_dri3_helper.c:376:13: error: implicit
declaration of function ‘printf’
[-Werror=implicit-function-declaration]
 printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
 ^~
../mesa-/src/loader/loader_dri3_helper.c:376:13: warning:
incompatible implicit declaration of built-in function ‘printf’
../mesa-/src/loader/loader_dri3_helper.c:376:13: note: include
‘’ or provide a declaration of ‘printf’
../mesa-/src/loader/loader_dri3_helper.c:39:1:
+#include 

../mesa-/src/loader/loader_dri3_helper.c:376:13:
 printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
 ^~
../mesa-/src/loader/loader_dri3_helper.c:376:75: warning: format
‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has
type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
 printf("ORPHAN-C: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
 ~~^
 %llu
../mesa-/src/loader/loader_dri3_helper.c:378:20:
draw->send_sbc);
~~
../mesa-/src/loader/loader_dri3_helper.c:430:10: warning:
incompatible implicit declaration of built-in function ‘printf’
  printf("ORPHAN-I: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
  ^~
../mesa-/src/loader/loader_dri3_helper.c:430:10: note: include
‘’ or provide a declaration of ‘printf’
../mesa-/src/loader/loader_dri3_helper.c:430:72: warning: format
‘%lu’ expects argument of type ‘long unsigned int’, but argument 6 has
type ‘uint64_t’ {aka ‘long long unsigned int’} [-Wformat=]
  printf("ORPHAN-I: %d x %d, drawable %d: recv %u vs send_sbc %lu\n",
  ~~^
  %llu
../mesa-/src/loader/loader_dri3_helper.c:432:17:
 draw->send_sbc);
 ~~
../mesa-/src/loader/loader_dri3_helper.c: In function
‘dri3_update_drawable’:
../mesa-/src/loader/loader_dri3_helper.c:1454:7: warning:
incompatible implicit declaration of built-in function ‘printf’
   printf("INIT: wxh = %d x %d, drawable %d eid %d\n",
draw->width, draw->height, draw->drawable, draw->eid);
   ^~
../mesa-/src/loader/loader_dri3_helper.c:1454:7: note: include
‘’ or provide a declaration of ‘printf’
cc1: some warnings being treated as errors

Cheers

Mike

On 4 May 2018 at 14:45, Mario Kleiner  wrote:
> See previous patch in series for explanation of the problem.
>
> This method avoids a blocking loader_dri3_swapbuffer_barrier() call
> whenever a GL contexts drawables are changed via glXMakeCurrent et al.
>
> Instead it filters out the "orphaned" PresentNotify events from
> previous incarnations of the loader_dri3_drawable. This should deal
> correctly with PixmapInvalidate, PixmapPresentCompleteNotify and
> MscCompleteNotify events, but i don't know a way to filter out
> WindowConfigureNotify events, or if it even matters to filter them.
>
> This PoC one is only meaningful if the first patch is omitted, and
> shows the spurious "ORPHAN" printouts which would hang KDE plasmashell
> if not filtered out.
>
> Test from a terminal: killall plasmashell; plasmashell
> Wiggly the mouse around, click etc. on the KDE taskbar, K-Menu,
> system tray icons, trigger volume/brightness feedback widgets
> to provoke the occassional ORPHAN event.
>
> Signed-off-by: Mario Kleiner 
> Cc: xorg-de...@lists.x.org
> Cc: dan...@fooishbar.org
> Cc: eero.t.tammi...@intel.com
> Cc: m...@fireburn.co.uk
> ---
>  src/loader/loader_dri3_helper.c | 24 
>  1 file changed, 24 insertions(+)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
> index 7bd79af..123a996 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -234,6 +234,10 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable 
> *draw)
>  {
> int i;
>
> +   printf("FINI: wxh = %d x %d, drawable %d eid %d recv_sbc %lu, send_sbc 
> %lu PENDING %lu\n",
> +  draw->width, draw->height, draw->drawable, draw->eid, 
> draw->recv_sbc, draw->send_sbc,
> +  draw->send_sbc - draw->recv_sbc);
> +
> if (draw->special_event)
>loader_dri3_swapbuffer_barrier(draw);
>
> @@ -373,6 +377,15 @@ dri3_handle_present_event(struct loader_dri3_drawable 
> *draw,
> * checking for wrap.
> */
>if (ce->kind == XCB_PRESENT_COMPLETE_KIND_PIXMAP) {
> + /* Filter out orphan events sent for a previous incarnation of 
> 

Re: [Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

Hi

I'm still seeing the freeze in the Steam client with this patch

Just about to test the other one

Mike

On 4 May 2018 at 17:17, Mike Lothian <m...@fireburn.co.uk> wrote:
> Hi Mario
>
> Again thanks for looking into this issue :D
>
> Tested-by: Mike Lothian <m...@fireburn.co.uk>
>
> I'll give the other patch a whirl now
>
> Cheers
>
> Mike
>
> On 4 May 2018 at 14:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
>> Before destroying the loader_dri3_drawable, make sure all pending
>> swaps for it have completed. This guides against the following scenario,
>> which happens, e.g., with KDE Plasma-5's plasmashell (which uses
>> QT-5's QtGui/QtQuick for rendering), when it repaints multiple
>> UI elements, each represented by its own Window/GLXDrawable, using
>> one common GLXContext for all GLXDrawable's:
>>
>> 1. glXMakeCurrent(dpy, drawable1, context);
>> 2. glXXX render to drawable1
>> 3. glXSwapBuffers(dpy, drawable1); #1
>> 4. glXMakeCurrent(dpy, drawable2, context);
>> 5. glXXX render to drawable2
>> 6. glXSwapBuffers(dpy, drawable2);
>> // While the swap #1 is still pending for drawable1:
>> 7. glXMakeCurrent(dpy, drawable1, context);
>> 8. glXXX render to drawable1
>> 9. glXSwapBuffers(dpy, drawable1);
>>
>> Binding a different drawable2 to the same context via glXMakeCurrent
>> will cause its previous drawable1 to be released (cfe. dri3_bind_context
>> -> driReleaseDrawables), which in turn calls loader_dri3_drawable_fini().
>> This unselects for Present notify event delivery on the associated
>> X-Window and loses all dri3 related state. If drawable1 is selected for
>> the context again [7], a new incarnation of loader_dri3_drawable is
>> created in dri3_bind_context->driFetchDrawable->dri3_create_drawable->
>> loader_dri3_drawable_init(), which again selects for Present notify
>> event delivery for the underlying X-Window, but the new incarnation lost
>> all state wrt. to previous rendering and swaps. The server now delivers
>> PresentPixmapIdle and PresentPixmapComplete events from the completed
>> previous swapbuffers call #1 [3] to the new loader_dri3_drawable, which
>> doesn't expect those. One problem is that the new incarnation has a
>> draw->send_sbc == 0, but now receives PresentPixmapComplete events with
>> sbc's > 0, therefore updating draw->recv_sbc to > 0 in
>> dri3_handle_present_event(). The draw->recv_sbc > draw_send_sbc is
>> misinterpreted as sbc wraparound, triggers recv_sbc wraparound handling
>> and ends up with a very large draw->recv_sbc. During the next swapbuffers
>> call [9], the totally wrong recv_sbc is used for calculating the target_msc
>> for the PresentPixmap request, leading to a target_msc billions of vblanks
>> in the future, leading to a swap that never completes and thereby frozen UI
>> and hang of the client.
>>
>> Make sure that a loader_dri3_drawable can only be destroyed after all
>> its pending swaps have completed, to prevent misdelivery of PresentNotify
>> events to the right X-Window, but the wrong incarnation of the associated
>> loader_dri3_drawable.
>>
>> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
>> Cc: xorg-de...@lists.x.org
>> Cc: dan...@fooishbar.org
>> Cc: eero.t.tammi...@intel.com
>> Cc: m...@fireburn.co.uk
>> ---
>>  src/loader/loader_dri3_helper.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/src/loader/loader_dri3_helper.c 
>> b/src/loader/loader_dri3_helper.c
>> index 6bb11c4..7bd79af 100644
>> --- a/src/loader/loader_dri3_helper.c
>> +++ b/src/loader/loader_dri3_helper.c
>> @@ -234,6 +234,9 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable 
>> *draw)
>>  {
>> int i;
>>
>> +   if (draw->special_event)
>> +  loader_dri3_swapbuffer_barrier(draw);
>> +
>> draw->ext->core->destroyDrawable(draw->dri_drawable);
>>
>> for (i = 0; i < ARRAY_SIZE(draw->buffers); i++) {
>> --
>> 2.7.4
>>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Mike Lothian]

Hi Mario

Again thanks for looking into this issue :D

Tested-by: Mike Lothian <m...@fireburn.co.uk>

I'll give the other patch a whirl now

Cheers

Mike

On 4 May 2018 at 14:45, Mario Kleiner <mario.kleiner...@gmail.com> wrote:
> Before destroying the loader_dri3_drawable, make sure all pending
> swaps for it have completed. This guides against the following scenario,
> which happens, e.g., with KDE Plasma-5's plasmashell (which uses
> QT-5's QtGui/QtQuick for rendering), when it repaints multiple
> UI elements, each represented by its own Window/GLXDrawable, using
> one common GLXContext for all GLXDrawable's:
>
> 1. glXMakeCurrent(dpy, drawable1, context);
> 2. glXXX render to drawable1
> 3. glXSwapBuffers(dpy, drawable1); #1
> 4. glXMakeCurrent(dpy, drawable2, context);
> 5. glXXX render to drawable2
> 6. glXSwapBuffers(dpy, drawable2);
> // While the swap #1 is still pending for drawable1:
> 7. glXMakeCurrent(dpy, drawable1, context);
> 8. glXXX render to drawable1
> 9. glXSwapBuffers(dpy, drawable1);
>
> Binding a different drawable2 to the same context via glXMakeCurrent
> will cause its previous drawable1 to be released (cfe. dri3_bind_context
> -> driReleaseDrawables), which in turn calls loader_dri3_drawable_fini().
> This unselects for Present notify event delivery on the associated
> X-Window and loses all dri3 related state. If drawable1 is selected for
> the context again [7], a new incarnation of loader_dri3_drawable is
> created in dri3_bind_context->driFetchDrawable->dri3_create_drawable->
> loader_dri3_drawable_init(), which again selects for Present notify
> event delivery for the underlying X-Window, but the new incarnation lost
> all state wrt. to previous rendering and swaps. The server now delivers
> PresentPixmapIdle and PresentPixmapComplete events from the completed
> previous swapbuffers call #1 [3] to the new loader_dri3_drawable, which
> doesn't expect those. One problem is that the new incarnation has a
> draw->send_sbc == 0, but now receives PresentPixmapComplete events with
> sbc's > 0, therefore updating draw->recv_sbc to > 0 in
> dri3_handle_present_event(). The draw->recv_sbc > draw_send_sbc is
> misinterpreted as sbc wraparound, triggers recv_sbc wraparound handling
> and ends up with a very large draw->recv_sbc. During the next swapbuffers
> call [9], the totally wrong recv_sbc is used for calculating the target_msc
> for the PresentPixmap request, leading to a target_msc billions of vblanks
> in the future, leading to a swap that never completes and thereby frozen UI
> and hang of the client.
>
> Make sure that a loader_dri3_drawable can only be destroyed after all
> its pending swaps have completed, to prevent misdelivery of PresentNotify
> events to the right X-Window, but the wrong incarnation of the associated
> loader_dri3_drawable.
>
> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
> Cc: xorg-de...@lists.x.org
> Cc: dan...@fooishbar.org
> Cc: eero.t.tammi...@intel.com
> Cc: m...@fireburn.co.uk
> ---
>  src/loader/loader_dri3_helper.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
> index 6bb11c4..7bd79af 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -234,6 +234,9 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable 
> *draw)
>  {
> int i;
>
> +   if (draw->special_event)
> +  loader_dri3_swapbuffer_barrier(draw);
> +
> draw->ext->core->destroyDrawable(draw->dri_drawable);
>
> for (i = 0; i < ARRAY_SIZE(draw->buffers); i++) {
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] meson: Fix with_intel_vk and with_amd_vk variables

[Mike Lothian]

Can you also add radeon to the amd one? That works on autotools

On Wed, 25 Apr 2018 at 02:16 Jordan Justen 
wrote:

> Fixes: 5608d0a2cee "meson: use array type options"
> Cc: Dylan Baker 
> Signed-off-by: Jordan Justen 
> ---
>  meson.build | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 52a1075823f..c0e5c94d794 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -213,8 +213,8 @@ if _vulkan_drivers.contains('auto')
>endif
>  endif
>  if _vulkan_drivers != ['']
> -  with_intel_vk = _drivers.contains('intel')
> -  with_amd_vk = _drivers.contains('amd')
> +  with_intel_vk = _vulkan_drivers.contains('intel')
> +  with_amd_vk = _vulkan_drivers.contains('amd')
>with_any_vk = true
>  endif
>
> --
> 2.16.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

[Mesa-dev] [PATCH] meson: Build st_tests_common with gtest

[Mike Lothian]

Fixes: 34cb4d0ebc1 ("meson: build tests for gallium mesa state tracker")

Signed-off-by: Mike Lothian <m...@fireburn.co.uk>
---
 src/mesa/state_tracker/tests/meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/state_tracker/tests/meson.build 
b/src/mesa/state_tracker/tests/meson.build
index f62039ef1e..0f84513209 100644
--- a/src/mesa/state_tracker/tests/meson.build
+++ b/src/mesa/state_tracker/tests/meson.build
@@ -22,7 +22,7 @@ libmesa_st_test_common = static_library(
   'mesa_st_test_common',
   ['st_tests_common.cpp', ir_expression_operation_h],
   include_directories : inc_common,
-  dependencies : dep_thread,
+  dependencies : [dep_thread, idep_gtest],
 )
 
 test(
-- 
2.17.0

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

Re: [Mesa-dev] [PATCH v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Mike Lothian]

Are you able to push this for me on my behalf?

On Wed, 4 Apr 2018 at 15:04 Kyriazis, George <george.kyria...@intel.com>
wrote:

> Thank you!
>
> Reviewed-By: George Kyriazis <george.kyria...@intel.com>
>
> On Apr 4, 2018, at 3:22 AM, Mike Lothian <m...@fireburn.co.uk> wrote:
>
> Include llvm/Transforms/Utils.h with the newest LLVM 7
>
> v2: Include with " " rather than < > (Vinson Lee)
>
> v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)
>
> Signed-of-by: Mike Lothian <m...@fireburn.co.uk>
> Tested-by: Vinson Lee <v...@freedesktop.org>
> ---
> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> index 031bced8a0..19f68c2bb6 100644
> --- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> +++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
> @@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
> #include "llvm/Support/DynamicLibrary.h"
> #include "llvm/Transforms/IPO.h"
> #include "llvm/Transforms/Scalar.h"
> +#if LLVM_VERSION_MAJOR >= 7
> +#include "llvm/Transforms/Utils.h"
> +#endif
> #include "llvm/Support/Host.h"
> #include "llvm/Support/DynamicLibrary.h"
>
> --
> 2.17.0
>
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH v3 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm/Transforms/Utils.h with the newest LLVM 7

v2: Include with " " rather than < > (Vinson Lee)

v3: Use LLVM_VERSION_MAJOR rather than HAVE_LLVM (George Kyriazis)

Signed-of-by: Mike Lothian <m...@fireburn.co.uk>
Tested-by: Vinson Lee <v...@freedesktop.org>
---
 src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 031bced8a0..19f68c2bb6 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/Scalar.h"
+#if LLVM_VERSION_MAJOR >= 7
+#include "llvm/Transforms/Utils.h"
+#endif
 #include "llvm/Support/Host.h"
 #include "llvm/Support/DynamicLibrary.h"
 
-- 
2.17.0

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

[Mesa-dev] [PATCH v2 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm/Transforms/Utils.h with the newest LLVM 7

v2: Include with " " rather than < >

Signed-of-by: Mike Lothian <m...@fireburn.co.uk>
Tested-by: Vinson Lee <v...@freedesktop.org>
---
 src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 031bced8a0..512fe8fc1f 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/Scalar.h"
+#if HAVE_LLVM >= 0x0700
+#include "llvm/Transforms/Utils.h"
+#endif
 #include "llvm/Support/Host.h"
 #include "llvm/Support/DynamicLibrary.h"
 
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

Thanks for pointing that out

I've sent a 4th patch, I've never compiled swr before, would you mind
testing to see if it fixes things for you, it's using the llvm include
rather than the llvm-c include

On Sun, 1 Apr 2018 at 06:15 Vinson Lee <v...@freedesktop.org> wrote:

> On Sat, Mar 31, 2018 at 5:08 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
> > On 1 April 2018 at 00:03, Vinson Lee <v...@freedesktop.org> wrote:
> >>
> >> A similar change is needed in
> >> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp.
> >>
> >> Vinson
> >
> > Hi
> >
> > I'm not convinced that it does
> >
> > Utils.h defines two functions LLVMAddLowerSwitchPass &
> > LLVMAddPromoteMemoryToRegisterPass. Whilst jit_pch.hpp does use
> > Scalar.h, it doesn't use either of the two functions in Utils.h so it
> > doesn't need to be included
> >
> > Cheers
> >
> > Mike
>
> I see this build errors with llvm 7.0.0svn. These errors are fixed if
> Utils.h is added to the list of includes.
>
>   CXX  rasterizer/jitter/libmesaswr_la-blend_jit.lo
> rasterizer/jitter/blend_jit.cpp:796:20: error: use of undeclared
> identifier 'createBreakCriticalEdgesPass'
> passes.add(createBreakCriticalEdgesPass());
>^
> rasterizer/jitter/blend_jit.cpp:799:20: error: use of undeclared
> identifier 'createPromoteMemoryToRegisterPass'
> passes.add(createPromoteMemoryToRegisterPass());
>^
> rasterizer/jitter/blend_jit.cpp:803:20: error: use of undeclared
> identifier 'createInstructionSimplifierPass'; did you mean
>   'createInstructionCombiningPass'?
> passes.add(createInstructionSimplifierPass());
>^~~
>createInstructionCombiningPass
>
> Vinson
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 4/4] swr: Fix include for createPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm/Transforms/Utils.h with the newest LLVM 7

Signed-of-by: Mike Lothian <m...@fireburn.co.uk>
---
 src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp 
b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
index 031bced8a0..d726d4844e 100644
--- a/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
+++ b/src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp
@@ -67,6 +67,9 @@ using PassManager = llvm::legacy::PassManager;
 #include "llvm/Support/DynamicLibrary.h"
 #include "llvm/Transforms/IPO.h"
 #include "llvm/Transforms/Scalar.h"
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 #include "llvm/Support/Host.h"
 #include "llvm/Support/DynamicLibrary.h"
 
-- 
2.16.3

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

[Mesa-dev] [PATCH 3/3] gallivm: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm-c/Transforms/Utils.h with the newest LLVM 7

Signed-of-by: Mike Lothian <m...@fireburn.co.uk>
Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
Tested-by: Dieter Nützel <die...@nuetzel-hh.de>
---
 src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 6ddc509a81..dae9d01552 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -40,6 +40,9 @@
 
 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 #include 
 
 
-- 
2.16.3

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

[Mesa-dev] [PATCH 2/3] radeonsi: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm-c/Transforms/Utils.h with the newest LLVM 7

Signed-of-by: Mike Lothian <m...@fireburn.co.uk>
Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
Tested-by: Dieter Nützel <die...@nuetzel-hh.de>
---
 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 79fdebe838..622fd26950 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -40,6 +40,9 @@
 #include 
 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 
 enum si_llvm_calling_convention {
RADEON_LLVM_AMDGPU_VS = 87,
-- 
2.16.3

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

[Mesa-dev] [PATCH 1/3] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm-c/Transforms/Utils.h with the newest LLVM 7

Signed-of-by: Mike Lothian <m...@fireburn.co.uk>
Reviewed-by: Samuel Pitoiset <samuel.pitoi...@gmail.com>
Tested-by: Dieter Nützel <die...@nuetzel-hh.de>
---
 src/amd/vulkan/radv_nir_to_llvm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index c6b4e8b532..2f0864da46 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -32,6 +32,9 @@
 #include 
 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 
 #include "sid.h"
 #include "gfx9d.h"
-- 
2.16.3

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

[Mesa-dev] [PATCH 0/3] Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

Hi

I've split this into three patches, one for each area affected

I think I've got the right prefixes now

I've also removed the fixes line and included the testing and reviewed
by tags

Hope that's OK and again if you're happy with this please can you commit
as I don't have git rights

Thanks

Mike

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

Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

On 1 April 2018 at 00:03, Vinson Lee  wrote:
>
> A similar change is needed in
> src/gallium/drivers/swr/rasterizer/jitter/jit_pch.hpp.
>
> Vinson

Hi

I'm not convinced that it does

Utils.h defines two functions LLVMAddLowerSwitchPass &
LLVMAddPromoteMemoryToRegisterPass. Whilst jit_pch.hpp does use
Scalar.h, it doesn't use either of the two functions in Utils.h so it
doesn't need to be included

Cheers

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

Re: [Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

On Sat, 31 Mar 2018 at 00:54 Dylan Baker <dy...@pnwbakers.com> wrote:
>
> Quoting Mike Lothian (2018-03-29 17:49:30)
> >
> >
> > On Fri, 30 Mar 2018, 01:42 Dylan Baker, <dy...@pnwbakers.com> wrote:
> >
> > Quoting Mike Lothian (2018-03-29 16:56:28)
> > > Include llvm-c/Transforms/Utils.h with the newest LLVM 7
> > >
> > > Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
> >
> > I have no comment on the patch itself.
> >
> > JFYI, this tag ("Fixes") has specific meaning in mesa and should only 
> > refer
> > to
> > mesa commits (we have scripts for stable releases that parse that
> > information).
> >
> > Dylan
> >
> >
> > Ah sorry about that
>
> No worries, these are mesa specific so a lot people don't know what they're 
> for.
>
> Dylan


Hi

Would you like me to make a v2 with another prefix and with the fixes
line removed? Or would you prefer I split it into 3 patches with the
correct prefix for each one?

Equally if you're happy as is could someone commit this to master? I
don't have git commit rights

Thanks

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

Re: [Mesa-dev] [radv] compilation error with 'latest' LLVM (#4e45b963bcd)

[Mike Lothian]

I've submitted a patch for this, it was a change in the llvm-c includes

On Fri, 30 Mar 2018 at 08:43 Dieter Nützel  wrote:

> make[4]: Verzeichnis „/opt/mesa/src/amd/vulkan“ wird betreten
>CC   radv_nir_to_llvm.lo
> radv_nir_to_llvm.c: In function ‘ac_llvm_finalize_module’:
> radv_nir_to_llvm.c:2874:2: error: implicit declaration of function
> ‘LLVMAddPromoteMemoryToRegisterPass’; did you mean
> ‘LLVMAddDemoteMemoryToRegisterPass’?
> [-Werror=implicit-function-declaration]
>LLVMAddPromoteMemoryToRegisterPass(passmgr);
>^~
>LLVMAddDemoteMemoryToRegisterPass
> cc1: some warnings being treated as errors
> make[4]: *** [Makefile:983: radv_nir_to_llvm.lo] Fehler 1
>
> Thanks and
> Happy Easter!
>
> Dieter
> ___
> 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] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

On Fri, 30 Mar 2018, 01:42 Dylan Baker, <dy...@pnwbakers.com> wrote:

> Quoting Mike Lothian (2018-03-29 16:56:28)
> > Include llvm-c/Transforms/Utils.h with the newest LLVM 7
> >
> > Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
>
> I have no comment on the patch itself.
>
> JFYI, this tag ("Fixes") has specific meaning in mesa and should only
> refer to
> mesa commits (we have scripts for stable releases that parse that
> information).
>
> Dylan
>

Ah sorry about that

I also think ac/nir only covers the first file and not the other two, which
are gallivm and radeonsi respectively I think

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

[Mesa-dev] [PATCH] ac/nir: Fix include for LLVMAddPromoteMemoryToRegisterPass

[Mike Lothian]

Include llvm-c/Transforms/Utils.h with the newest LLVM 7

Fixes: 2dd4f35c7fc llvm-c: Split Utils out of Scalar.h
Signed-of-by: Mike Lothian <m...@fireburn.co.uk>

---

I don't have git commit rights

If you're happy with this patch please can you commit it

Cheers

Mike
---
 src/amd/vulkan/radv_nir_to_llvm.c   | 3 +++
 src/gallium/auxiliary/gallivm/lp_bld_init.c | 3 +++
 src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c | 3 +++
 3 files changed, 9 insertions(+)

diff --git a/src/amd/vulkan/radv_nir_to_llvm.c 
b/src/amd/vulkan/radv_nir_to_llvm.c
index c6b4e8b532..2f0864da46 100644
--- a/src/amd/vulkan/radv_nir_to_llvm.c
+++ b/src/amd/vulkan/radv_nir_to_llvm.c
@@ -32,6 +32,9 @@
 #include 
 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 
 #include "sid.h"
 #include "gfx9d.h"
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c 
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 6ddc509a81..dae9d01552 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -40,6 +40,9 @@
 
 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 #include 
 
 
diff --git a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c 
b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
index 79fdebe838..622fd26950 100644
--- a/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
+++ b/src/gallium/drivers/radeonsi/si_shader_tgsi_setup.c
@@ -40,6 +40,9 @@
 #include 
 #include 
 #include 
+#if HAVE_LLVM >= 0x0700
+#include 
+#endif
 
 enum si_llvm_calling_convention {
RADEON_LLVM_AMDGPU_VS = 87,
-- 
2.16.3

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

Re: [Mesa-dev] [PATCH 2/2] configure.ac: require libdrm_amdgpu 2.4.91

[Mike Lothian]

Did you mean to remove the blacklist you added in the previous patch?

On Wed, 14 Mar 2018 at 01:03 Marek Olšák  wrote:

> From: Marek Olšák 
>
> Since 2.4.90 might not work, just ask for the next version.
> ---
>  configure.ac | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index e29ce68..8ec5b26 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -67,21 +67,21 @@ OPENCL_VERSION=1
>  AC_SUBST([OPENCL_VERSION])
>
>  # The idea is that libdrm is distributed as one cohesive package, even
>  # though it is composed of multiple libraries. However some drivers
>  # may have different version requirements than others. This list
>  # codifies which drivers need which version of libdrm. Any libdrm
>  # version dependencies in non-driver-specific code should be reflected
>  # in the first entry.
>  LIBDRM_REQUIRED=2.4.75
>  LIBDRM_RADEON_REQUIRED=2.4.71
> -LIBDRM_AMDGPU_REQUIRED=2.4.90
> +LIBDRM_AMDGPU_REQUIRED=2.4.91
>  LIBDRM_INTEL_REQUIRED=2.4.75
>  LIBDRM_NVVIEUX_REQUIRED=2.4.66
>  LIBDRM_NOUVEAU_REQUIRED=2.4.66
>  LIBDRM_FREEDRENO_REQUIRED=2.4.91
>  LIBDRM_ETNAVIV_REQUIRED=2.4.82
>
>  dnl Versions for external dependencies
>  DRI2PROTO_REQUIRED=2.8
>  GLPROTO_REQUIRED=1.4.14
>  LIBOMXIL_BELLAGIO_REQUIRED=0.0
> @@ -2601,27 +2601,20 @@ if test -n "$with_gallium_drivers"; then
>  radeon_llvm_check $LLVM_REQUIRED_R600 "r600"
>
>  llvm_add_component "asmparser" "r600"
>  llvm_add_component "bitreader" "r600"
>  fi
>  ;;
>  xradeonsi)
>  HAVE_GALLIUM_RADEONSI=yes
>  PKG_CHECK_MODULES([RADEON], [libdrm >=
> $LIBDRM_RADEON_REQUIRED libdrm_radeon >= $LIBDRM_RADEON_REQUIRED])
>  PKG_CHECK_MODULES([AMDGPU], [libdrm >=
> $LIBDRM_AMDGPU_REQUIRED libdrm_amdgpu >= $LIBDRM_AMDGPU_REQUIRED])
> -
> -# Blacklist libdrm_amdgpu 2.4.90 because it breaks older
> radeonsi
> -libdrm_version=`pkg-config libdrm_amdgpu --modversion`
> -if test "x$libdrm_version" = x2.4.90; then
> -AC_MSG_ERROR([radeonsi can't use libdrm 2.4.90 due to a
> compatibility issue. Use a newer or older version.])
> -fi
> -
>  require_libdrm "radeonsi"
>  radeon_llvm_check $LLVM_REQUIRED_RADEONSI "radeonsi"
>  if test "x$enable_egl" = xyes; then
>  require_basic_egl "radeonsi"
>  fi
>  ;;
>  xnouveau)
>  HAVE_GALLIUM_NOUVEAU=yes
>  PKG_CHECK_MODULES([NOUVEAU], [libdrm >=
> $LIBDRM_NOUVEAU_REQUIRED libdrm_nouveau >= $LIBDRM_NOUVEAU_REQUIRED])
>  require_libdrm "nouveau"
> --
> 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] Few issues with Meson

[Mike Lothian]

Hi Dylan

Do you have the link to patch on patchwork? I'll give it a go

I'm using meson 0.45 however the cross-file requires more than just
defining llvm-config, everything else is normally picked up from what
portage is setting in the build environment - though strangely not if clang
is used - I'll look into that sometime

Regards

Mike

On Fri, 9 Mar 2018 at 16:37 Dylan Baker <dy...@pnwbakers.com> wrote:

> Quoting Mike Lothian (2018-03-06 05:07:34)
> > Hi
> >
> > When compiling wine I also noticed that the d3d.pc files didn't have
> moduledir
> > set, so wine couldn't find it
> >
> > configure: error: pkg-config couldn't find Gallium Nine module
>
> I've sent a patch for this.
>
> >
> > Regards
> >
> > Mike
> >
> > On Tue, 6 Mar 2018 at 02:17 Mike Lothian <m...@fireburn.co.uk> wrote:
> >
> > Hi
> >
> > I've been trying to get a Gentoo ebuild ready for meson
> >
> > I've had to fudge the llvm-config for cross compiling a 32bit mesa on
> > a 64bit machine
>
> If you're using a new enough meson (0.45) you can specify the llvm-config
> you
> want to use in the cross file.
>
> >
> > I notice that -Dvulkan-drivers= doesn't accept intel,radeon like
> > autotools used to, it also seems as long as one value is correct the
> > other is ignored
>
> we're using amd instead of radeon. After 18.0 branches I want to bump the
> meson
> requirement so we can use meson's list argument type, which will check for
> such
> problems.
>
> >
> > Also -Dva-libs-path= doesn't play well with absolute paths, or rather
> > install_megadrivers.py is doing something strange - normally gentoo
> > installs everything to a temporary image path then puts those files
> > into the live system. It seems install_megadrivers.py doesn't do this
> > and installs directly to the live system - I worked around it by
> > dropping the /usr
>
> There's a patch from someone in FreeBSD that might fix this (the way we do
> symlinking in install_megadrivers is wrong).
>
> Sorry it took me so long to find this email, notmuch applied some odd tags
> to
> it.
>
> Dylan
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Few issues with Meson

[Mike Lothian]

Hi

When compiling wine I also noticed that the d3d.pc files didn't have
moduledir set, so wine couldn't find it

configure: error: pkg-config couldn't find Gallium Nine module

Regards

Mike

On Tue, 6 Mar 2018 at 02:17 Mike Lothian <m...@fireburn.co.uk> wrote:

> Hi
>
> I've been trying to get a Gentoo ebuild ready for meson
>
> I've had to fudge the llvm-config for cross compiling a 32bit mesa on
> a 64bit machine
>
> I notice that -Dvulkan-drivers= doesn't accept intel,radeon like
> autotools used to, it also seems as long as one value is correct the
> other is ignored
>
> Also -Dva-libs-path= doesn't play well with absolute paths, or rather
> install_megadrivers.py is doing something strange - normally gentoo
> installs everything to a temporary image path then puts those files
> into the live system. It seems install_megadrivers.py doesn't do this
> and installs directly to the live system - I worked around it by
> dropping the /usr
>
> The inital ebuild is in the FireBurn overlay
> (
> https://github.com/FireBurn/Overlay/blob/master/media-libs/mesa/mesa-.ebuild
> )
>
> Regards
>
> Mike
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Few issues with Meson

[Mike Lothian]

Hi

I've been trying to get a Gentoo ebuild ready for meson

I've had to fudge the llvm-config for cross compiling a 32bit mesa on
a 64bit machine

I notice that -Dvulkan-drivers= doesn't accept intel,radeon like
autotools used to, it also seems as long as one value is correct the
other is ignored

Also -Dva-libs-path= doesn't play well with absolute paths, or rather
install_megadrivers.py is doing something strange - normally gentoo
installs everything to a temporary image path then puts those files
into the live system. It seems install_megadrivers.py doesn't do this
and installs directly to the live system - I worked around it by
dropping the /usr

The inital ebuild is in the FireBurn overlay
(https://github.com/FireBurn/Overlay/blob/master/media-libs/mesa/mesa-.ebuild)

Regards

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

Re: [Mesa-dev] [PATCH] disk cache: Link with -latomic if necessary

[Mike Lothian]

Hi

Sorry to be a pain again

I've just tested this with clang and the 32bit build still fails without
-latomic

libtool: link: /bin/true glsl/.libs/libstandalone.a
libtool: link: rm -fr glsl/.libs/libstandalone.lax
glsl/.libs/libstandalone.lax
libtool: link: ( cd "glsl/.libs" && rm -f "libstandalone.la" && ln -s "../
libstandalone.la" "libstandalone.la" )
/bin/sh ../../libtool  --tag=CXX   --mode=link clang++ -m32
-fvisibility=hidden -Werror=pointer-arith -Werror=vla -O3 -march=native
-pipe -flto=thin -Wall -fno-math-errno -fno-trapping-math
-Qunused-arguments   -O3 -march=native -pipe -flto=thin -o glsl_
compiler glsl/main.o glsl/libstandalone.la
libtool: link: clang++ -m32 -fvisibility=hidden -Werror=pointer-arith
-Werror=vla -O3 -march=native -pipe -flto=thin -Wall -fno-math-errno
-fno-trapping-math -Qunused-arguments -O3 -march=native -pipe -flto=thin -o
glsl_compiler glsl/main.o  glsl/.libs/l
ibstandalone.a -lz -lpthread -pthread
/var/tmp/portage/media-libs/mesa-/temp/lto-llvm-4efaa5.o:disk_cache.c:function
disk_cache_remove: error: undefined reference to '__atomic_fetch_add_8'
clang-7.0: error: linker command failed with exit code 1 (use -v to see
invocation)
make[4]: *** [Makefile:2364: glsl_compiler] Error 1
make[4]: Leaving directory
'/var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_32.x86/src/compiler'

make[3]: *** [Makefile:1793: all] Error 2
make[3]: Leaving directory
'/var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_32.x86/src/compiler'

make[2]: *** [Makefile:875: all-recursive] Error 1
make[2]: Leaving directory
'/var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_32.x86/src'
make[1]: *** [Makefile:660: all] Error 2
make[1]: Leaving directory
'/var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_32.x86/src'
make: *** [Makefile:668: all-recursive] Error 1
* ERROR: media-libs/mesa-::gentoo failed (compile phase):
*   emake failed
*
* If you need support, post the output of `emerge --info
'=media-libs/mesa-::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=media-libs/mesa-::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/media-libs/mesa-/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/media-libs/mesa-/temp/environment'.
* Working directory:
'/var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_32.x86'
* S: '/var/tmp/portage/media-libs/mesa-/work/mesa-'

If I pass -latomic in with the LDFLAGS it builds fine

On Tue, 27 Feb 2018 at 20:22 Matt Turner  wrote:

> On Tue, Feb 27, 2018 at 2:26 AM, Thierry Reding
>  wrote:
> > On Mon, Feb 26, 2018 at 11:14:05AM -0800, Matt Turner wrote:
> >> On Fri, Feb 23, 2018 at 5:18 AM, Thierry Reding
> >>  wrote:
> >> > From: Thierry Reding 
> >> >
> >> > The disk cache implementation uses 64-bit atomic operations. For some
> >> > architectures, such as 32-bit ARM, GCC will not be able to translate
> >> > these operations into lock-free instructions and will instead rely on
> >>
> >> Here, and in the comment in meson.build, I think you mean "atomic"
> >> rather than "lock-free" instructions? It's at least confusing, since
> >> on x86 atomic instructions have a "lock" prefix.
> >
> > This uses the terminology used by the GCC documentation, see:
> >
> > https://gcc.gnu.org/wiki/Atomic/GCCMM
> >
> > I think the GCC terms merely mean that you don't need any explicit
> > locking for these operations to be atomic.
> >
> > How about this instead:
> >
> > "... operations into atomic, lock-free instructions..."
> >
> > ?
>
> Ah, I see. Thanks, that works for me.
> ___
> 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] disk cache: Link with -latomic if necessary

[Mike Lothian]

On Fri, 23 Feb 2018 at 13:18 Thierry Reding 
wrote:

> From: Thierry Reding 
>
> The disk cache implementation uses 64-bit atomic operations. For some
> architectures, such as 32-bit ARM, GCC will not be able to translate
> these operations into lock-free instructions and will instead rely on
> the external atomics library to provide these operations.
>
> Check at configuration time whether or not linking against libatomic
> is necessary and if so, create a dependency that can be used while
> linking the mesautil library.
>
> This is the meson equivalent of 2ef7f23820a6 ("configure: check if
> -latomic is needed for __atomic_*").
>
> Signed-off-by: Thierry Reding 
> ---
>  meson.build  | 15 +++
>  src/util/meson.build |  2 +-
>  2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index 121341a950c4..7c6f40573421 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -800,6 +800,21 @@ endif
>  if cc.compiles('int main() { int n; return __atomic_load_n(,
> __ATOMIC_ACQUIRE); }',
> name : 'GCC atomic builtins')
>pre_args += '-DUSE_GCC_ATOMIC_BUILTINS'
> +
> +  # Not all atomic calls can be turned into lock-free instructions, in
> which
> +  # GCC will make calls into the libatomic library. Check whether we need
> to
> +  # link with -latomic.
> +  #
> +  # This can happen for 64-bit atomic operations on 32-bit architectures
> such
> +  # as ARM.
> +  if not cc.links('''#include 
> + int main() {
> +   uint64_t n;
> +   return (int)__atomic_load_n(, __ATOMIC_ACQUIRE);
> + }''',
> +  name : 'GCC atomic builtins required -latomic')
> +dep_atomic = cc.find_library('atomic')
> +  endif
>  endif
>  if not cc.links('''#include 
> uint64_t v;
> diff --git a/src/util/meson.build b/src/util/meson.build
> index b23dba3a9851..eece1cefef6a 100644
> --- a/src/util/meson.build
> +++ b/src/util/meson.build
> @@ -102,7 +102,7 @@ libmesa_util = static_library(
>'mesa_util',
>[files_mesa_util, format_srgb],
>include_directories : inc_common,
> -  dependencies : [dep_zlib, dep_clock, dep_thread],
> +  dependencies : [dep_zlib, dep_clock, dep_thread, dep_atomic],
>c_args : [c_msvc_compat_args, c_vis_args],
>build_by_default : false
>  )
> --
> 2.16.2
>
>
Hi

I had this issue when building a 32bit Mesa on x86-64 when using Clang,
64bit was fine.

Will this work for Clang too and if so can a similar change be made for
autotools?

I'm waiting for a change to Meson that'll allow me to specify a 32bit
llvm-config to test this on Meson with 32bit

Thanks

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

Re: [Mesa-dev] [PATCH 2/2] glxinfo/wglinfo: print list of 4.3 shading language versions

[Mike Lothian]

The OCD side of me says it doesn't look right :P The lazy side of me says
it's fine

Either way it doesn't make much difference, it's only exposed with the
extended output anyway

On Fri, 23 Feb 2018 at 16:32 Brian Paul <bri...@vmware.com> wrote:

> On 02/23/2018 03:06 AM, Mike Lothian wrote:
> > This still looks wrong, there's now two 4.3 sections:
>
> Yeah, but I guess I don't see it as a big deal.  Fixing it would involve
> a bit of a hack.  While processing the big list of queries, I'd have to
> check for extension=="4.3" and call a function to query/print the GLSL
> versions.
>
> What do you think?
>
> -Brian
>
>
>
> >
> >4.3:
> >  GL_MAX_ELEMENT_INDEX = 2147483647
> >  GL_MAX_COMPUTE_UNIFORM_BLOCKS = 14
> >  GL_MAX_COMPUTE_TEXTURE_IMAGE_UNITS = 32
> >  GL_MAX_COMPUTE_IMAGE_UNIFORMS = 32
> >  GL_MAX_COMPUTE_SHARED_MEMORY_SIZE = 65536
> >  GL_MAX_COMPUTE_UNIFORM_COMPONENTS = 16384
> >  GL_MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS = 16
> >  GL_MAX_COMPUTE_ATOMIC_COUNTERS = 4096
> >  GL_MAX_COMBINED_COMPUTE_UNIFORM_COMPONENTS = 245760
> >  GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS = 1792
> >  GL_MAX_DEBUG_MESSAGE_LENGTH = 4096
> >  GL_MAX_DEBUG_LOGGED_MESSAGES = 10
> >  GL_MAX_DEBUG_GROUP_STACK_DEPTH = 64
> >  GL_MAX_LABEL_LENGTH = 256
> >  GL_MAX_UNIFORM_LOCATIONS = 98304
> >  GL_MAX_FRAMEBUFFER_WIDTH = 16384
> >  GL_MAX_FRAMEBUFFER_HEIGHT = 16384
> >  GL_MAX_FRAMEBUFFER_LAYERS = 2048
> >  GL_MAX_FRAMEBUFFER_SAMPLES = 16
> >  GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS = 12
> >  GL_MAX_GEOMETRY_SHADER_STORAGE_BLOCKS = 12
> >  GL_MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS = 12
> >  GL_MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS = 12
> >  GL_MAX_FRAGMENT_SHADER_STORAGE_BLOCKS = 12
> >  GL_MAX_COMPUTE_SHADER_STORAGE_BLOCKS = 12
> >  GL_MAX_COMBINED_SHADER_STORAGE_BLOCKS = 72
> >  GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS = 72
> >  GL_MAX_SHADER_STORAGE_BLOCK_SIZE = 134217728
> >  GL_MAX_COMBINED_SHADER_OUTPUT_RESOURCES = 200
> >  GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET = 2047
> >  GL_MAX_VERTEX_ATTRIB_BINDINGS = 16
> >4.4:
> >  GL_MAX_VERTEX_ATTRIB_STRIDE = 2048
> >4.5:
> >  GL_MAX_CULL_DISTANCES = 8
> >  GL_MAX_COMBINED_CLIP_AND_CULL_DISTANCES = 8
> >GL_ARB_transform_feedback3:
> >  GL_MAX_TRANSFORM_FEEDBACK_BUFFERS = 4
> >  GL_MAX_VERTEX_STREAMS = 4
> >4.3:
> >  GL_NUM_SHADING_LANGUAGE_VERSIONS = 16
> >450
> >440
> >430
> >420
> >410
> >400
> >330
> >150
> >140
> >130
> >120
> >
> >320 es
> >310 es
> >300 es
> >100
> >
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] glxinfo/wglinfo: print list of 4.3 shading language versions

[Mike Lothian]

This still looks wrong, there's now two 4.3 sections:

  4.3:
GL_MAX_ELEMENT_INDEX = 2147483647
GL_MAX_COMPUTE_UNIFORM_BLOCKS = 14
GL_MAX_COMPUTE_TEXTURE_IMAGE_UNITS = 32
GL_MAX_COMPUTE_IMAGE_UNIFORMS = 32
GL_MAX_COMPUTE_SHARED_MEMORY_SIZE = 65536
GL_MAX_COMPUTE_UNIFORM_COMPONENTS = 16384
GL_MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS = 16
GL_MAX_COMPUTE_ATOMIC_COUNTERS = 4096
GL_MAX_COMBINED_COMPUTE_UNIFORM_COMPONENTS = 245760
GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS = 1792
GL_MAX_DEBUG_MESSAGE_LENGTH = 4096
GL_MAX_DEBUG_LOGGED_MESSAGES = 10
GL_MAX_DEBUG_GROUP_STACK_DEPTH = 64
GL_MAX_LABEL_LENGTH = 256
GL_MAX_UNIFORM_LOCATIONS = 98304
GL_MAX_FRAMEBUFFER_WIDTH = 16384
GL_MAX_FRAMEBUFFER_HEIGHT = 16384
GL_MAX_FRAMEBUFFER_LAYERS = 2048
GL_MAX_FRAMEBUFFER_SAMPLES = 16
GL_MAX_VERTEX_SHADER_STORAGE_BLOCKS = 12
GL_MAX_GEOMETRY_SHADER_STORAGE_BLOCKS = 12
GL_MAX_TESS_CONTROL_SHADER_STORAGE_BLOCKS = 12
GL_MAX_TESS_EVALUATION_SHADER_STORAGE_BLOCKS = 12
GL_MAX_FRAGMENT_SHADER_STORAGE_BLOCKS = 12
GL_MAX_COMPUTE_SHADER_STORAGE_BLOCKS = 12
GL_MAX_COMBINED_SHADER_STORAGE_BLOCKS = 72
GL_MAX_SHADER_STORAGE_BUFFER_BINDINGS = 72
GL_MAX_SHADER_STORAGE_BLOCK_SIZE = 134217728
GL_MAX_COMBINED_SHADER_OUTPUT_RESOURCES = 200
GL_MAX_VERTEX_ATTRIB_RELATIVE_OFFSET = 2047
GL_MAX_VERTEX_ATTRIB_BINDINGS = 16
  4.4:
GL_MAX_VERTEX_ATTRIB_STRIDE = 2048
  4.5:
GL_MAX_CULL_DISTANCES = 8
GL_MAX_COMBINED_CLIP_AND_CULL_DISTANCES = 8
  GL_ARB_transform_feedback3:
GL_MAX_TRANSFORM_FEEDBACK_BUFFERS = 4
GL_MAX_VERTEX_STREAMS = 4
  4.3:
GL_NUM_SHADING_LANGUAGE_VERSIONS = 16
  450
  440
  430
  420
  410
  400
  330
  150
  140
  130
  120

  320 es
  310 es
  300 es
  100
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH 2/2] glxinfo/wglinfo: print list of 4.3 shading language versions

[Mike Lothian]

It also seems to have an off by one error

On Wed, 21 Feb 2018 at 16:41 Mike Lothian <m...@fireburn.co.uk> wrote:

> This doesn't show as default and seems to be tucked away
> under GL_ARB_transform_feedback3
>
>   GL_ARB_transform_feedback3:
> GL_MAX_TRANSFORM_FEEDBACK_BUFFERS = 4
> GL_MAX_VERTEX_STREAMS = 4
> GL_NUM_SHADING_LANGUAGE_VERSIONS = 16
> 450
> 440
> 430
> 420
> 410
> 400
> 330
> 150
> 140
> 130
> 120
>
> 320 es
> 310 es
> 300 es
> 100
>
>
> On Wed, 21 Feb 2018 at 16:13 Brian Paul <bri...@vmware.com> wrote:
>
>> ---
>>  src/xdemos/glinfo_common.c | 13 +
>>  1 file changed, 13 insertions(+)
>>
>> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
>> index 0411891..c36cff1 100644
>> --- a/src/xdemos/glinfo_common.c
>> +++ b/src/xdemos/glinfo_common.c
>> @@ -794,6 +794,19 @@ print_limits(const char *extensions, const char
>> *oglstring, int version,
>>}
>>free(formats);
>> }
>> +
>> +#if defined(GL_VERSION_4_3)
>> +   if (version >= 43) {
>> +  GLint i, n = 0;
>> +  glGetIntegerv(GL_NUM_SHADING_LANGUAGE_VERSIONS, );
>> +  printf("GL_NUM_SHADING_LANGUAGE_VERSIONS = %d\n", n);
>> +  for (i = 0; i < n; i++) {
>> + printf("%s\n", (const char *)
>> +extfuncs->GetStringi(GL_SHADING_LANGUAGE_VERSION, i));
>> +  }
>> +   }
>> +#endif
>> +
>>  #if defined(GL_ARB_vertex_program)
>> if (extension_supported("GL_ARB_vertex_program", extensions)) {
>>print_program_limits(GL_VERTEX_PROGRAM_ARB, extfuncs);
>> --
>> 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 2/2] glxinfo/wglinfo: print list of 4.3 shading language versions

[Mike Lothian]

This doesn't show as default and seems to be tucked away
under GL_ARB_transform_feedback3

  GL_ARB_transform_feedback3:
GL_MAX_TRANSFORM_FEEDBACK_BUFFERS = 4
GL_MAX_VERTEX_STREAMS = 4
GL_NUM_SHADING_LANGUAGE_VERSIONS = 16
450
440
430
420
410
400
330
150
140
130
120

320 es
310 es
300 es
100


On Wed, 21 Feb 2018 at 16:13 Brian Paul  wrote:

> ---
>  src/xdemos/glinfo_common.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/src/xdemos/glinfo_common.c b/src/xdemos/glinfo_common.c
> index 0411891..c36cff1 100644
> --- a/src/xdemos/glinfo_common.c
> +++ b/src/xdemos/glinfo_common.c
> @@ -794,6 +794,19 @@ print_limits(const char *extensions, const char
> *oglstring, int version,
>}
>free(formats);
> }
> +
> +#if defined(GL_VERSION_4_3)
> +   if (version >= 43) {
> +  GLint i, n = 0;
> +  glGetIntegerv(GL_NUM_SHADING_LANGUAGE_VERSIONS, );
> +  printf("GL_NUM_SHADING_LANGUAGE_VERSIONS = %d\n", n);
> +  for (i = 0; i < n; i++) {
> + printf("%s\n", (const char *)
> +extfuncs->GetStringi(GL_SHADING_LANGUAGE_VERSION, i));
> +  }
> +   }
> +#endif
> +
>  #if defined(GL_ARB_vertex_program)
> if (extension_supported("GL_ARB_vertex_program", extensions)) {
>print_program_limits(GL_VERTEX_PROGRAM_ARB, extfuncs);
> --
> 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 0/6] OpenGL 3.1 + ARB_compatibility and related stuff (v2)

[Mike Lothian]

On 15 February 2018 at 00:11, Marek Olšák <mar...@gmail.com> wrote:
> Hi,
>
> This is the second version of GL 3.1 compatibility support patches.
> There is also ARB_enhanced_layouts for the compatibility context and
> other related changes.
>
> Please review.
>
> Thanks,
> Marek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev

So I've done my best to test this. These are the diffs between the
glxinfo reports before and after on radeonsi and i965


fireburn@axion ~ $ diff -u glxinfo.amdgpu.core glxinfo.amdgpu.compat
--- glxinfo.amdgpu.core 2018-02-15 01:05:48.081778762 +
+++ glxinfo.amdgpu.compat   2018-02-15 01:39:04.727660602 +
@@ -105,7 +105,7 @@
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
-Max compat profile version: 3.0
+Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
Memory info (GL_ATI_meminfo):
@@ -121,7 +121,7 @@
Currently available dedicated video memory: 4089 MB
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon R9 M295X (TONGA / DRM 3.25.0 /
4.15.0-rc8-agd5f+, LLVM 7.0.0)
-OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-0cd37f9178)
+OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-c6694793e1)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
@@ -325,8 +325,8 @@
GL_S3_s3tc


-OpenGL version string: 3.0 Mesa 18.1.0-devel (git-0cd37f9178)
-OpenGL shading language version string: 1.30
+OpenGL version string: 3.1 Mesa 18.1.0-devel (git-c6694793e1)
+OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
GL_AMD_conservative_depth
@@ -350,6 +350,7 @@
GL_ARB_clear_texture
GL_ARB_clip_control
GL_ARB_color_buffer_float
+GL_ARB_compatibility
GL_ARB_compressed_texture_pixel_storage
GL_ARB_compute_shader
GL_ARB_compute_variable_group_size
@@ -367,6 +368,7 @@
GL_ARB_draw_buffers_blend
GL_ARB_draw_elements_base_vertex
GL_ARB_draw_instanced
+GL_ARB_enhanced_layouts
GL_ARB_explicit_attrib_location
GL_ARB_explicit_uniform_location
GL_ARB_fragment_coord_conventions
@@ -588,7 +590,7 @@
GL_SUN_multi_draw_arrays


-OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
(git-0cd37f9178)
+OpenGL ES profile version string: OpenGL ES 3.1 Mesa 18.1.0-devel
(git-c6694793e1)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:
GL_ANGLE_texture_compression_dxt3
fireburn@axion ~ $ diff -u glxinfo.intel.core glxinfo.intel.compat
--- glxinfo.intel.core  2018-02-15 01:05:53.581770479 +
+++ glxinfo.intel.compat2018-02-15 01:38:54.077684665 +
@@ -111,7 +111,7 @@
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)
-OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-0cd37f9178)
+OpenGL core profile version string: 4.5 (Core Profile) Mesa
18.1.0-devel (git-c6694793e1)
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
@@ -309,8 +309,8 @@
GL_S3_s3tc


-OpenGL version string: 3.0 Mesa 18.1.0-devel (git-0cd37f9178)
-OpenGL shading language version string: 1.30
+OpenGL version string: 3.0 Mesa 18.1.0-devel (git-c6694793e1)
+OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL extensions:
GL_3DFX_texture_compression_FXT1
@@ -557,7 +557,7 @@
GL_SUN_multi_draw_arrays


-OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.1.0-devel
(git-0cd37f9178)
+OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.1.0-devel
(git-c6694793e1)
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
GL_ANDROID_extension_pack_es31a

I'm not aware of anything that uses OpenGL 3.1 Compat or the
ARB_compatability extension, but if you know of anything I'll test it
directly

Should i965 show the extra extensions or a higher compat version as
well as the bump to the GLSL version?

My games continue to work after this change is applied

Tested-by: Mike Lothian <m...@fireburn.co.uk>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Initial release of AMD Open Source Driver for Vulkan

[Mike Lothian]

Hi

No I'm not using ICC however that section prevents you using Clang, it
basically says if not GCC then assumes Intel's compiler

Cheers

Mike

On Fri, 22 Dec 2017, 3:04 pm Mao, David, <david@amd.com> wrote:

> Hi Lothian,
> Thanks for testing out out driver!
> Officially we recommend you to stick to GCC5 for now, however, we do have
> a fix for the constexpr issue mentioned below that just didn’t make it to
> this first release.
> According to your diff, are you using ICC?
> Could you let us know the compiler version as well as your distro?
>
> Thanks.
> Best Regards,
> David
>
>
> On Dec 22, 2017, at 9:48 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
>
> Congratulations on getting this out the door
>
> It didn't compile for me without these changes:
>
> In pal:
>
> diff --git a/src/util/math.cpp b/src/util/math.cpp
> index 46e9ede..3af4259 100644
> --- a/src/util/math.cpp
> +++ b/src/util/math.cpp
> @@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
> NBitFloatInfo& info);
>  static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);
>
>  // Initialize the descriptors for various N-bit floating point
> representations:
> -static constexpr NBitFloatInfo Float16Info =
> +static NBitFloatInfo Float16Info =
>  {
>  16,   // numBits
>  10,   //
> numFracBits
> @@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
>  (23 - 10),//
> fracBitsDiff
>  };
>
> -static constexpr NBitFloatInfo Float11Info =
> +static NBitFloatInfo Float11Info =
>  {
>  11,   // numBits
>  6,//
> numFracBits
> @@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
>  23 - 6,   //
> fracBitsDiff
>  };
>
> -static constexpr NBitFloatInfo Float10Info =
> +static NBitFloatInfo Float10Info =
>  {
>  10,   // numBits
>  5,//
> numFracBits
>
> In xgl:
>
> diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
> index 4e4d669..5006184 100644
> --- a/icd/CMakeLists.txt
> +++ b/icd/CMakeLists.txt
> @@ -503,16 +503,16 @@ if (UNIX)
>
>  target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)
>
> -if(NOT ICD_USE_GCC)
> -message(WARNING "Intel ICC untested in CMake.")
> -target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> -endif()
> +#if(NOT ICD_USE_GCC)
> +#message(WARNING "Intel ICC untested in CMake.")
> +#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
> +#endif()
>
>  if(CMAKE_BUILD_TYPE_RELEASE)
>  if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
>  execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
>  if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
> VERSION_EQUAL 5.3)
> -target_link_libraries(xgl PRIVATE -flto=4
> -fuse-linker-plugin -Wno-odr)
> +target_link_libraries(xgl PRIVATE -Wno-odr)
>  message(WARNING "LTO enabled for Linking")
>  endif()
>  endif()
> @@ -530,17 +530,17 @@ if (UNIX)
>
>  # CMAKE-TODO: What is whole-archive used for?
>  #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
> -Wl,--no-whole-archive)
> -if(CMAKE_BUILD_TYPE_RELEASE)
> -execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
> OUTPUT_VARIABLE GCC_VERSION)
> -if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
> 5.3)
> -target_link_libraries(xgl PRIVATE -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
> -target_link_libraries(xgl PUBLIC -Wl,--whole-archive
> ${PROJECT_BINARY_DIR

Re: [Mesa-dev] Initial release of AMD Open Source Driver for Vulkan

[Mike Lothian]

Congratulations on getting this out the door

It didn't compile for me without these changes:

In pal:

diff --git a/src/util/math.cpp b/src/util/math.cpp
index 46e9ede..3af4259 100644
--- a/src/util/math.cpp
+++ b/src/util/math.cpp
@@ -54,7 +54,7 @@ static uint32 Float32ToFloatN(float f, const
NBitFloatInfo& info);
 static float FloatNToFloat32(uint32 fBits, const NBitFloatInfo& info);

 // Initialize the descriptors for various N-bit floating point
representations:
-static constexpr NBitFloatInfo Float16Info =
+static NBitFloatInfo Float16Info =
 {
 16,   // numBits
 10,   //
numFracBits
@@ -72,7 +72,7 @@ static constexpr NBitFloatInfo Float16Info =
 (23 - 10),//
fracBitsDiff
 };

-static constexpr NBitFloatInfo Float11Info =
+static NBitFloatInfo Float11Info =
 {
 11,   // numBits
 6,//
numFracBits
@@ -90,7 +90,7 @@ static constexpr NBitFloatInfo Float11Info =
 23 - 6,   //
fracBitsDiff
 };

-static constexpr NBitFloatInfo Float10Info =
+static NBitFloatInfo Float10Info =
 {
 10,   // numBits
 5,//
numFracBits

In xgl:

diff --git a/icd/CMakeLists.txt b/icd/CMakeLists.txt
index 4e4d669..5006184 100644
--- a/icd/CMakeLists.txt
+++ b/icd/CMakeLists.txt
@@ -503,16 +503,16 @@ if (UNIX)

 target_link_libraries(xgl PRIVATE c stdc++ ${CMAKE_DL_LIBS} pthread)

-if(NOT ICD_USE_GCC)
-message(WARNING "Intel ICC untested in CMake.")
-target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
-endif()
+#if(NOT ICD_USE_GCC)
+#message(WARNING "Intel ICC untested in CMake.")
+#target_link_libraries(xgl PRIVATE -fabi-version=0 -static-intel)
+#endif()

 if(CMAKE_BUILD_TYPE_RELEASE)
 if("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
 execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
 if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION
VERSION_EQUAL 5.3)
-target_link_libraries(xgl PRIVATE -flto=4
-fuse-linker-plugin -Wno-odr)
+target_link_libraries(xgl PRIVATE -Wno-odr)
 message(WARNING "LTO enabled for Linking")
 endif()
 endif()
@@ -530,17 +530,17 @@ if (UNIX)

 # CMAKE-TODO: What is whole-archive used for?
 #target_link_libraries(xgl -Wl,--whole-archive ${ICD_LIBS}
-Wl,--no-whole-archive)
-if(CMAKE_BUILD_TYPE_RELEASE)
-execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
-if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
-target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
-target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
-endif()
-endif()
+#if(CMAKE_BUILD_TYPE_RELEASE)
+#execute_process(COMMAND ${CMAKE_C_COMPILER} -dumpversion
OUTPUT_VARIABLE GCC_VERSION)
+#if (GCC_VERSION VERSION_GREATER 5.3 OR GCC_VERSION VERSION_EQUAL
5.3)
+#target_link_libraries(xgl PRIVATE -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/src/libpal.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/metrohash/libmetrohash.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/gpuopen/libgpuopen.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/vam/libvam.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/addrlib/libaddrlib.a -Wl,--no-whole-archive)
+#target_link_libraries(xgl PUBLIC -Wl,--whole-archive
${PROJECT_BINARY_DIR}/pal/jemalloc/libjemalloc.a -Wl,--no-whole-archive)
+#endif()
+#endif()

 #${ICD_TARGET}.so${SO_VERSION_NUMBER} : ${filter-out -Wl%,$(LLLIBS})


diff --git a/icd/api/llpc/util/llpcDebug.cpp

Re: [Mesa-dev] Gallium ARB_get_program_binary support

[Mike Lothian]

Game works fine, not sure if it's using the extension or not

On Mon, 11 Dec 2017 at 23:21 Mike Lothian <m...@fireburn.co.uk> wrote:

> I'll check that when I'm next home
>
> On Mon, 11 Dec 2017 at 21:19 Timothy Arceri <tarc...@itsqueeze.com> wrote:
>
>> On 12/12/17 08:13, Mike Lothian wrote:
>> > Tested with Dead Island, Dirt Rally and Serious Sam BFG (which I believe
>> > uses this extension)
>> >
>> > Do you know any other games that use this?
>>
>> I believe Dying Light uses it also.
>>
>>
>> >
>> > On Mon, 11 Dec 2017 at 02:17 Dieter Nützel <die...@nuetzel-hh.de
>> > <mailto:die...@nuetzel-hh.de>> wrote:
>> >
>> > For the V2 series:
>> >
>> > Tested-by: Dieter Nützel <die...@nuetzel-hh.de
>> > <mailto:die...@nuetzel-hh.de>>
>> > and
>> > Acked-by: Dieter Nützel <die...@nuetzel-hh.de
>> > <mailto:die...@nuetzel-hh.de>>
>> > if this is worth from my side.
>> >
>> > on RX580 8GB
>> >
>> > with DiRT Rally, UH, UV, Blender 2.79, smoketest, F1 2017 (Vulkan),
>> > glmark2 (parallel with
>> > OpenCL (/opt/opencl-example>./run_tests.sh))
>> >
>> > Dieter
>> >
>> > Am 10.12.2017 23:06, schrieb Timothy Arceri:
>> >  > On 10/12/17 17:56, Dieter Nützel wrote:
>> >  >> First BAD commit is patch [PATCH 2/5].
>> >  >> https://patchwork.freedesktop.org/patch/192329/
>> >  >
>> >  >
>> >  > Thanks! I've sent a V2 of that patch, I've also confirmed DiRT
>> Rally
>> >  > no longer segfaults at start-up.
>> >  >
>> >  >> With it I get this in dmesg:
>> >  >>
>> >  >> [34581.836122] OGL_Dispatch_33[4887]: segfault at 0 ip
>> >  >> 9ebeafda sp a95580d4 error 4 in
>> >  >> libc-2.26.so <http://libc-2.26.so>[7f6afcaf7000+1b1000]
>> >  >> [34706.224082] perf: interrupt took too long (5089 > 4913),
>> lowering
>> >  >> kernel.perf_event_max_sample_rate to 39250
>> >  >> [34918.80] OGL_Dispatch_33[19897]: segfault at 0 ip
>> >  >> d9adbd7a sp e6e1b769 error 4 in
>> >  >> libc-2.26.so <http://libc-2.26.so>[7f2fc4777000+1b1000]
>> >  >> [35148.576818] OGL_Dispatch_33[2934]: segfault at 0 ip
>> >  >> 78a41511 sp 1f147296 error 4 in
>> >  >> libc-2.26.so <http://libc-2.26.so>[7ff11fa23000+1b1000]
>> >  >> [35172.410621] OGL_Dispatch_33[3371]: segfault at 0 ip
>> >  >> ef37ae37 sp 99ce37ab error 4 in
>> >  >> libc-2.26.so <http://libc-2.26.so>[7f0af78ff000+1b1000]
>> >  >> [35383.940291] OGL_Dispatch_33[18591]: segfault at 0 ip
>> >  >> 813f92d2 sp 7c9305e7 error 4 in
>> >  >> libc-2.26.so <http://libc-2.26.so>[7fee87426000+1b1000]
>> >  >>
>> >  >> It's in the morning, now.
>> >  >> Here in 'OLD' Germany, near Hamburg.
>> >  >> Good night! ;-)
>> >  >>
>> >  >> Dieter
>> >  >>
>> >  >> Am 10.12.2017 05:15, schrieb Timothy Arceri:
>> >  >>> Hi, as always thanks for testing :)
>> >  >>>
>> >  >>> Are you able to find out which patch causes the crash? I'm
>> > curious if
>> >  >>> its the ARB_get_program_binary support or if I break the
>> regular
>> >  >>> cache
>> >  >>> when re-factoring.
>> >  >>>
>> >  >>> Thanks,
>> >  >>> Tim
>> >  >>>
>> >  >>> On 09/12/17 15:58, Dieter Nützel wrote:
>> >  >>>> Hello Tim,
>> >  >>>>
>> >  >>>> first time ever, that I got a real regression with your GREAT
>> > work.
>> >  >>>> ;-)
>> >  >>>>
>> >  >>>> DiRT Rally sig fault (SIGSEGV(11) with this series.
>> >  >>>> (see attachment)
>> >  >>>>
>> >  >>>> Bad cache hit re-read?
>> >  >>>> Remo

Re: [Mesa-dev] Gallium ARB_get_program_binary support

[Mike Lothian]

I'll check that when I'm next home

On Mon, 11 Dec 2017 at 21:19 Timothy Arceri <tarc...@itsqueeze.com> wrote:

> On 12/12/17 08:13, Mike Lothian wrote:
> > Tested with Dead Island, Dirt Rally and Serious Sam BFG (which I believe
> > uses this extension)
> >
> > Do you know any other games that use this?
>
> I believe Dying Light uses it also.
>
>
> >
> > On Mon, 11 Dec 2017 at 02:17 Dieter Nützel <die...@nuetzel-hh.de
> > <mailto:die...@nuetzel-hh.de>> wrote:
> >
> > For the V2 series:
> >
> > Tested-by: Dieter Nützel <die...@nuetzel-hh.de
> > <mailto:die...@nuetzel-hh.de>>
> > and
> > Acked-by: Dieter Nützel <die...@nuetzel-hh.de
> > <mailto:die...@nuetzel-hh.de>>
> > if this is worth from my side.
> >
> > on RX580 8GB
> >
> > with DiRT Rally, UH, UV, Blender 2.79, smoketest, F1 2017 (Vulkan),
> > glmark2 (parallel with
> > OpenCL (/opt/opencl-example>./run_tests.sh))
> >
> > Dieter
> >
> > Am 10.12.2017 23:06, schrieb Timothy Arceri:
> >  > On 10/12/17 17:56, Dieter Nützel wrote:
> >  >> First BAD commit is patch [PATCH 2/5].
> >  >> https://patchwork.freedesktop.org/patch/192329/
> >  >
> >  >
> >  > Thanks! I've sent a V2 of that patch, I've also confirmed DiRT
> Rally
> >  > no longer segfaults at start-up.
> >  >
> >  >> With it I get this in dmesg:
> >  >>
> >  >> [34581.836122] OGL_Dispatch_33[4887]: segfault at 0 ip
> >  >> 9ebeafda sp a95580d4 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7f6afcaf7000+1b1000]
> >  >> [34706.224082] perf: interrupt took too long (5089 > 4913),
> lowering
> >  >> kernel.perf_event_max_sample_rate to 39250
> >  >> [34918.80] OGL_Dispatch_33[19897]: segfault at 0 ip
> >  >> d9adbd7a sp e6e1b769 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7f2fc4777000+1b1000]
> >  >> [35148.576818] OGL_Dispatch_33[2934]: segfault at 0 ip
> >  >> 78a41511 sp 1f147296 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7ff11fa23000+1b1000]
> >  >> [35172.410621] OGL_Dispatch_33[3371]: segfault at 0 ip
> >  >> ef37ae37 sp 99ce37ab error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7f0af78ff000+1b1000]
> >  >> [35383.940291] OGL_Dispatch_33[18591]: segfault at 0 ip
> >  >> 813f92d2 sp 7c9305e7 error 4 in
> >  >> libc-2.26.so <http://libc-2.26.so>[7fee87426000+1b1000]
> >  >>
> >  >> It's in the morning, now.
> >  >> Here in 'OLD' Germany, near Hamburg.
> >  >> Good night! ;-)
> >  >>
> >  >> Dieter
> >  >>
> >  >> Am 10.12.2017 05:15, schrieb Timothy Arceri:
> >  >>> Hi, as always thanks for testing :)
> >  >>>
> >  >>> Are you able to find out which patch causes the crash? I'm
> > curious if
> >  >>> its the ARB_get_program_binary support or if I break the regular
> >  >>> cache
> >  >>> when re-factoring.
> >  >>>
> >  >>> Thanks,
> >  >>> Tim
> >  >>>
> >  >>> On 09/12/17 15:58, Dieter Nützel wrote:
> >  >>>> Hello Tim,
> >  >>>>
> >  >>>> first time ever, that I got a real regression with your GREAT
> > work.
> >  >>>> ;-)
> >  >>>>
> >  >>>> DiRT Rally sig fault (SIGSEGV(11) with this series.
> >  >>>> (see attachment)
> >  >>>>
> >  >>>> Bad cache hit re-read?
> >  >>>> Removing .cache/mesa_shader_cache do not help.
> >  >>>> Searching for the rigth Feral (Steam?) cache dir. - Alex/James?
> >  >>>>
> >  >>>> Then I'll have to find which of the five did it.
> >  >>>>
> >  >>>>  From the log I got this:
> >  >>>> [1209/054156:ERROR:sandbox_linux.cc(325)] InitializeSandbox()
> > called
> >  >>>> with multiple threads in process gpu-process
&g

Re: [Mesa-dev] Gallium ARB_get_program_binary support

[Mike Lothian]

Tested with Dead Island, Dirt Rally and Serious Sam BFG (which I believe
uses this extension)

Do you know any other games that use this?

On Mon, 11 Dec 2017 at 02:17 Dieter Nützel  wrote:

> For the V2 series:
>
> Tested-by: Dieter Nützel 
> and
> Acked-by: Dieter Nützel 
> if this is worth from my side.
>
> on RX580 8GB
>
> with DiRT Rally, UH, UV, Blender 2.79, smoketest, F1 2017 (Vulkan),
> glmark2 (parallel with
> OpenCL (/opt/opencl-example>./run_tests.sh))
>
> Dieter
>
> Am 10.12.2017 23:06, schrieb Timothy Arceri:
> > On 10/12/17 17:56, Dieter Nützel wrote:
> >> First BAD commit is patch [PATCH 2/5].
> >> https://patchwork.freedesktop.org/patch/192329/
> >
> >
> > Thanks! I've sent a V2 of that patch, I've also confirmed DiRT Rally
> > no longer segfaults at start-up.
> >
> >> With it I get this in dmesg:
> >>
> >> [34581.836122] OGL_Dispatch_33[4887]: segfault at 0 ip
> >> 9ebeafda sp a95580d4 error 4 in
> >> libc-2.26.so[7f6afcaf7000+1b1000]
> >> [34706.224082] perf: interrupt took too long (5089 > 4913), lowering
> >> kernel.perf_event_max_sample_rate to 39250
> >> [34918.80] OGL_Dispatch_33[19897]: segfault at 0 ip
> >> d9adbd7a sp e6e1b769 error 4 in
> >> libc-2.26.so[7f2fc4777000+1b1000]
> >> [35148.576818] OGL_Dispatch_33[2934]: segfault at 0 ip
> >> 78a41511 sp 1f147296 error 4 in
> >> libc-2.26.so[7ff11fa23000+1b1000]
> >> [35172.410621] OGL_Dispatch_33[3371]: segfault at 0 ip
> >> ef37ae37 sp 99ce37ab error 4 in
> >> libc-2.26.so[7f0af78ff000+1b1000]
> >> [35383.940291] OGL_Dispatch_33[18591]: segfault at 0 ip
> >> 813f92d2 sp 7c9305e7 error 4 in
> >> libc-2.26.so[7fee87426000+1b1000]
> >>
> >> It's in the morning, now.
> >> Here in 'OLD' Germany, near Hamburg.
> >> Good night! ;-)
> >>
> >> Dieter
> >>
> >> Am 10.12.2017 05:15, schrieb Timothy Arceri:
> >>> Hi, as always thanks for testing :)
> >>>
> >>> Are you able to find out which patch causes the crash? I'm curious if
> >>> its the ARB_get_program_binary support or if I break the regular
> >>> cache
> >>> when re-factoring.
> >>>
> >>> Thanks,
> >>> Tim
> >>>
> >>> On 09/12/17 15:58, Dieter Nützel wrote:
>  Hello Tim,
> 
>  first time ever, that I got a real regression with your GREAT work.
>  ;-)
> 
>  DiRT Rally sig fault (SIGSEGV(11) with this series.
>  (see attachment)
> 
>  Bad cache hit re-read?
>  Removing .cache/mesa_shader_cache do not help.
>  Searching for the rigth Feral (Steam?) cache dir. - Alex/James?
> 
>  Then I'll have to find which of the five did it.
> 
>   From the log I got this:
>  [1209/054156:ERROR:sandbox_linux.cc(325)] InitializeSandbox() called
>  with multiple threads in process gpu-process
>  [1209/054157:INFO:CONSOLE(0)] "The specified value '!' does not
>  conform to the required format.  The format is '#rrggbb' where rr,
>  gg, bb are two-digit hexadecimal numbers.", source:
> 
> file://localhost/home1/alexander/My%20Games/Steam/steamapps/common/DiRT%20Rally/share/FeralUI/PGOW/Core/feralUI.html
>  (0)
>  Installing breakpad exception handler for
>  appid(steam)/version(1509425745)
>  [1209/054158:INFO:CONSOLE(0)] "Synchronous XMLHttpRequest on the
>  main thread is deprecated because of its detrimental effects to the
>  end user's experience. For more help, check
>  http://xhr.spec.whatwg.org/.;, source:  (0)
>  [1209/054208:WARNING:x11_util.cc(1490)] X error received: serial
>  4814, error_code 3 (BadWindow (invalid Window parameter)),
>  request_code 4, minor_code 0 (X_DestroyWindow)
>  SDL2 initialised [built against 2.0.5, running with 2.0.5]
>  DirtRally: dumped to
>  "/home/alexander/.local/share/feral-interactive/DiRT
>  Rally/crashes/2363a778-c194-621f-0f837dfb-191070fd.dmp"
> 
>  Cheers,
>  Dieter
> 
>  Am 08.12.2017 10:57, schrieb Timothy Arceri:
> > Core support in now in master so this is just a resend of the
> > gallium
> > patches.
> >
> > Resolves crash in Dead Island:
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85564
> >
> > Branch available here:
> >
> > https://github.com/tarceri/Mesa.git gallium-program-binary
> >
> > ___
> > 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] Gallium ARB_get_program_binary support

[Mike Lothian]

I can confirm these sort the crash on Dead Island and I can confirm I'm
also seeing the segfault with Dirt Rally

On Fri, 8 Dec 2017 at 09:58 Timothy Arceri  wrote:

> Core support in now in master so this is just a resend of the gallium
> patches.
>
> Resolves crash in Dead Island:
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85564
>
> Branch available here:
>
> https://github.com/tarceri/Mesa.git gallium-program-binary
>
> ___
> 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] V3 i965/Gallium ARB_get_program_binary support

[Mike Lothian]

I can confirm this fixes the Dead Island crash, which makes this the first
time I've been able to play the game since purchasing it :D

The patches doesn't apply cleanly to master so I used the following fixup
https://github.com/FireBurn/mesa/tree/gallium-program-binary

If you're happy with that feel free to add my Tested-by

On Tue, 5 Dec 2017 at 05:03 Timothy Arceri  wrote:

> Ping! The outstanding patches for review are:
>
> 4, 12, 22, 23
>
> Gallium specific patches:
>
> 17-21
>
> The following have a v1 r-b Nicolai but have changed since:
>
> 13, 14, 15
>
> Branch available here:
>
> https://github.com/tarceri/Mesa.git gallium-program-binary
>
> On 29/11/17 12:24, Timothy Arceri wrote:
> > V3:
> > This is basically the V2 that Jordan sent with feedback addressed,
> > gallium support added, some minor functional changes such as only
> > storing the default uniforms to either disk or program binary cache
> > (rather than fixing them up later) and some refactoring to allow
> > greater code sharing between gallium and i965.
> >
> > This series adds i965/gallium support for ARB_get_program_binary
> > with greater than 0 supported formats. Today we support this extension,
> > but advertise support for 0 formats. This series allows i965/gallium
> > to advertise support for 1 format.
> >
> > This series defines a common Mesa format for ARB_get_program_binary,
> > along with helper functions to read and write the format. The binary
> > saved can only be reloaded on the exact same Mesa build using the
> > exact same hardware.
> >
> > The i965/gallium implementation saves out a serialized nir/tgsi
> > represenation of the program. For i965 we can later add support for
> > saving the gen binary program as well. (We will still need the nir
> > program for state based recompiles.)
> >
> > This implementation passes piglit, deqp and glcts functions. It also
> > works with (and fixes a crash in) Dead Island with makes use of the
> > extension.
> >
> > ___
> > 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 3/3] RFC: vulkan/wsi: Rework the way prime support works

[Mike Lothian]

Will this allow us to select between iGPU and dGPU like we can with OpenGL?
Or is it just going to force radv like before?

On Thu, 16 Nov 2017 at 10:09 Grazvydas Ignotas  wrote:

> On Thu, Nov 16, 2017 at 12:33 AM, Dave Airlie  wrote:
> > On 15 November 2017 at 04:40, Jason Ekstrand 
> wrote:
> >> This commit significantly reworks the way prime support works and lets
> >> us pull it even further into radv.  The old mechanism required the
> >> specific WSI layer to be aware of the linear shadow copy that has to be
> >> done in order for prime to work.  In the new paradigm, we better define
> >> what bits of wsi_image go to the client and what bits go off to the
> >> window system.  It's then the job of the driver to allocate two separate
> >> images and stash whatever intermediates it needs in driver_private.
> >> There are a few advantages to this method:
> >>
> >>  1) It separates supporting prime from the driver decision as to whether
> >> it's better to render directly into the window-system-compatible
> >> image or if it's better to blit.
> >>
> >>  2) Because of this separation, it's now possible for a driver to use a
> >> different scheme for WSI image presentation where it hooks the
> >> vkCmdPipelineBarrier that transitions the image to
> >> VK_IMAGE_LAYOUT_PRESENT_SRC_KHR and does the blit there.
> >>
> >>  3) It lets us pull more of the details into radv and, in my opinion,
> >> actually makes the radv code more straightforward.
> >
> > For the record, PRIME is not radv specific, stop trying to make it so,
> > anv should support display to other GPUs.
>
> Yes it would be great if that worked, would make radv vs anv testing
> so much easier as I much prefer my display to be on dGPU.
>
> Gražvydas
> ___
> 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/16] RadeonSI micro-optimizations

[Mike Lothian]

Hi

Have you ran any benchmarks against these?

Cheers

Mike

On Fri, 13 Oct 2017 at 13:04 Marek Olšák  wrote:

> Hi,
>
> This series:
> - switches IB placement to GTT WC
> - uses SPI_SHADER_USER_DATA_COMMON on GFX9
> - combines setting of 2 per-stage descriptor pointers into 1 SET_SH_REG
> packet
> - if there is only 1 constant buffer and 0 shader and atomic buffers,
>   the constant buffer pointer is directly set into
> SI_SGPR_CONST_AND_SHADER_-
>   BUFFERS, skipping a descriptor upload and shader load
>
> Please review.
>
> Thanks!
>
> 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] Vulkan extensions

[Mike Lothian]

Maybe you could use the hardware feature list and have an extra option of
unsupported, for the hardware that cannot do that feature and not include
that in the percentages

On Fri, 15 Sep 2017, 12:19 am Bas Nieuwenhuizen 
wrote:

> On Fri, Sep 15, 2017 at 1:18 AM, Dave Airlie  wrote:
> > On 15 September 2017 at 09:12, Jordan Justen 
> wrote:
> >> On 2017-09-14 15:36:10, Romain Failliot wrote:
> >>> Le 14 sept. 2017 6:11 PM, "Bas Nieuwenhuizen" 
> a
> >>> écrit :
> >>>
> >>> > For vulkan, because 1.0 is the initial version, there are no
> >>> > extensions to implement to get to that version, so having an
> >>> > extensions list would be nonsensical.
> >>>
> >>> I don't think it is nonsensical, say the nouveau devs starts to work
> on a
> >>> Vulkan 1.0 driver and they'd like to show their progress in
> features.txt. I
> >>> think it would be interesting for them to have the list of extensions
> to
> >>> implement to be Vulkan 1.0 compliant, so they could flag which
> extensions
> >>> are done, in progress or not started.
> >>
> >> That would be fine, except I don't think the 1.0 features are bucketed
> >> into a set of 'extensions'. Right? I thought 1.0 was the baseline, and
> >> extensions were built upon that.
> >>
> >
> > I think Romain missed Bas's point. There is no extension list to get to
> 1.0.
> > 1.0 is step one. The closest thing is probably the device features list,
> > and even that you don't expect any device to fill all of it, so what
> 100% is
> > differs for every device.
>
> Also you can implement 0% of the feature list and still be vulkan 1.0
> compliant ;)
>
> - Bas
> >
> > Dave.
> ___
> 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 mesa] mesa/st: remove unwanted backup file

[Mike Lothian]

LOL didn't even spot this sorry

It might be a good idea to pop *.orig and *.rej into the gitignore file

On Wed, 30 Aug 2017 at 14:17 Emil Velikov  wrote:

> On 30 August 2017 at 14:11, Eric Engestrom  wrote:
> > Fixes: 0ac78dc92582a59d4319 "util: move string_to_uint_map to glsl"
> > Cc: Emil Velikov 
> > Signed-off-by: Eric Engestrom 
> Reviewed-by: Emil Velikov 
>
> /me puts on a brown paper bag
>
> -Emil
> ___
> 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] util: move string_to_uint_map to glsl

[Mike Lothian]

Feel free to add my tested by for this

Thanks for the fix

On Sat, 26 Aug 2017 at 17:35 Jason Ekstrand  wrote:

> Reviewed-by: Jason Ekstrand 
>
> On Fri, Aug 25, 2017 at 7:10 PM, Jason Ekstrand 
> wrote:
>
>> Ack.  Not a review though.
>>
>>
>>
>> On August 25, 2017 6:38:46 PM Emil Velikov 
>> wrote:
>>
>> From: Emil Velikov 
>>>
>>> The functionality is used by glsl and mesa. With the latter already
>>> depending on the former.
>>>
>>> With this in place the src/util/ static library libmesautil.la no longer
>>> has a C++ dependency. Thus objects which use it (like libEGL) don't need
>>> the C++ link.
>>>
>>> Cc: Jason Ekstrand 
>>> Suggested-by: Jason Ekstrand 
>>> Cc: "17.2" 
>>> Fixes: 02cc35937277 ("egl/wayland: Use linux-dmabuf interface for
>>> buffers")
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851
>>> Signed-off-by: Emil Velikov 
>>> ---
>>>  src/compiler/Makefile.sources | 4 +++-
>>>  src/compiler/glsl/link_uniform_initializers.cpp   | 2 +-
>>>  src/compiler/glsl/link_uniforms.cpp   | 2 +-
>>>  src/compiler/glsl/linker.cpp  | 2 +-
>>>  src/compiler/glsl/shader_cache.cpp| 2 +-
>>>  src/compiler/glsl/standalone.cpp  | 2 +-
>>>  src/{util => compiler/glsl}/string_to_uint_map.cpp| 0
>>>  src/{util => compiler/glsl}/string_to_uint_map.h  | 0
>>>  src/compiler/glsl/tests/set_uniform_initializer_tests.cpp | 2 +-
>>>  src/mesa/main/shader_query.cpp| 2 +-
>>>  src/mesa/main/shaderobj.c | 2 +-
>>>  src/mesa/program/ir_to_mesa.cpp   | 2 +-
>>>  src/mesa/state_tracker/st_glsl_to_nir.cpp | 2 +-
>>>  src/util/Makefile.sources | 2 --
>>>  14 files changed, 13 insertions(+), 13 deletions(-)
>>>  rename src/{util => compiler/glsl}/string_to_uint_map.cpp (100%)
>>>  rename src/{util => compiler/glsl}/string_to_uint_map.h (100%)
>>>
>>> diff --git a/src/compiler/Makefile.sources
>>> b/src/compiler/Makefile.sources
>>> index 6e08dfb8448..a8309a1c592 100644
>>> --- a/src/compiler/Makefile.sources
>>> +++ b/src/compiler/Makefile.sources
>>> @@ -140,7 +140,9 @@ LIBGLSL_FILES = \
>>> glsl/program.h \
>>> glsl/propagate_invariance.cpp \
>>> glsl/s_expression.cpp \
>>> -   glsl/s_expression.h
>>> +   glsl/s_expression.h \
>>> +   glsl/string_to_uint_map.cpp \
>>> +   glsl/string_to_uint_map.h
>>>
>>>  LIBGLSL_SHADER_CACHE_FILES = \
>>> glsl/shader_cache.cpp \
>>> diff --git a/src/compiler/glsl/link_uniform_initializers.cpp
>>> b/src/compiler/glsl/link_uniform_initializers.cpp
>>> index e7f9c9d8ac0..84a38793f64 100644
>>> --- a/src/compiler/glsl/link_uniform_initializers.cpp
>>> +++ b/src/compiler/glsl/link_uniform_initializers.cpp
>>> @@ -25,7 +25,7 @@
>>>  #include "ir.h"
>>>  #include "linker.h"
>>>  #include "ir_uniform.h"
>>> -#include "util/string_to_uint_map.h"
>>> +#include "string_to_uint_map.h"
>>>
>>>  /* These functions are put in a "private" namespace instead of being
>>> marked
>>>   * static so that the unit tests can access them.  See
>>> diff --git a/src/compiler/glsl/link_uniforms.cpp
>>> b/src/compiler/glsl/link_uniforms.cpp
>>> index 1b87c5860b6..99b171d7881 100644
>>> --- a/src/compiler/glsl/link_uniforms.cpp
>>> +++ b/src/compiler/glsl/link_uniforms.cpp
>>> @@ -27,7 +27,7 @@
>>>  #include "ir_uniform.h"
>>>  #include "glsl_symbol_table.h"
>>>  #include "program.h"
>>> -#include "util/string_to_uint_map.h"
>>> +#include "string_to_uint_map.h"
>>>  #include "ir_array_refcount.h"
>>>
>>>  /**
>>> diff --git a/src/compiler/glsl/linker.cpp b/src/compiler/glsl/linker.cpp
>>> index b4784c51199..90c1084c50f 100644
>>> --- a/src/compiler/glsl/linker.cpp
>>> +++ b/src/compiler/glsl/linker.cpp
>>> @@ -75,7 +75,7 @@
>>>  #include "program/program.h"
>>>  #include "util/mesa-sha1.h"
>>>  #include "util/set.h"
>>> -#include "util/string_to_uint_map.h"
>>> +#include "string_to_uint_map.h"
>>>  #include "linker.h"
>>>  #include "link_varyings.h"
>>>  #include "ir_optimization.h"
>>> diff --git a/src/compiler/glsl/shader_cache.cpp
>>> b/src/compiler/glsl/shader_cache.cpp
>>> index cc4d24482d9..887b8954c51 100644
>>> --- a/src/compiler/glsl/shader_cache.cpp
>>> +++ b/src/compiler/glsl/shader_cache.cpp
>>> @@ -59,7 +59,7 @@
>>>  #include "program.h"
>>>  #include "shader_cache.h"
>>>  #include "util/mesa-sha1.h"
>>> -#include "util/string_to_uint_map.h"
>>> +#include "string_to_uint_map.h"
>>>
>>>  extern "C" {
>>>  #include "main/enums.h"
>>> diff --git a/src/compiler/glsl/standalone.cpp
>>> b/src/compiler/glsl/standalone.cpp
>>> index 

Re: [Mesa-dev] threaded opengl

[Mike Lothian]

I think you also need to provide info on how much of a speed up it provides
because some games are slower with glthread

On Mon, 24 Jul 2017 at 01:33 siyia  wrote:

> sorry executable is "mb_warband_linux" start.sh or mb_warband.sh are
> local scripts to start the game so:
>
> 
>
> ___
> 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] egl/wayland: Fix linking libEGL_common.la

[Mike Lothian]

If I try and compile mesa with clang (even using ld.bfd) I get these errors:

libtool: link: clang++ -m32 -fvisibility=hidden -Werror=pointer-arith
-Werror=vla -O2 -march=native -pipe -Wall -fno-math-errno
-fno-trapping-math -Qunused-arguments -O2 -march=native -pipe -fuse-ld=bfd
-o glsl_compiler glsl/main.o  glsl/.libs/libstandal
one.a -lz -lpthread -pthread
glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function
`disk_cache_remove':
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/util/disk_cache.c:(.text+0x752):
undefined reference to `__atomic_fetch_add_8'
glsl/.libs/libstandalone.a(libmesautil_la-disk_cache.o): In function
`cache_put':
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/util/disk_cache.c:(.text+0xa76):
undefined reference to `__atomic_fetch_add_8'
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/util/disk_cache.c:(.text+0xe40):
undefined reference to `__atomic_fetch_add_8'


On Mon, 24 Jul 2017 at 00:03 Mike Lothian <m...@fireburn.co.uk> wrote:

> This is only an issue when using ld.gold, ld.bfd works fine which is
> probably why no one else has seen it. It only started being a problem when
> the dmabuff stuff landed and the makefiles were cleaned up
>
> I tried playing around with the dummy.cpp but I couldn't get it to trigger
> the c++ compiler
>
> On Fri, 21 Jul 2017 at 13:27 Emil Velikov <emil.l.veli...@gmail.com>
> wrote:
>
>> On 20 July 2017 at 21:25, Mike Lothian <m...@fireburn.co.uk> wrote:
>> > Because libmesautil.la includes string_to_uint_map.o, -lstdc++ is
>> > required for linking to succeed
>> >
>> It's a bit suspicious why not many others are seeing this issue.
>> Suspecting the GCC version/build flags has something to do here.
>>
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851
>> >
>> > Signed-off-by: Mike Lothian <m...@fireburn.co.uk>
>> > ---
>> >  src/egl/Makefile.am | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
>> > index 7c1a4929b8..830ed52b86 100644
>> > --- a/src/egl/Makefile.am
>> > +++ b/src/egl/Makefile.am
>> > @@ -83,7 +83,7 @@ AM_CFLAGS += $(WAYLAND_CFLAGS)
>> >  libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
>> >  libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
>> >  libEGL_common_la_LIBADD += $(top_builddir)/src/egl/wayland/wayland-drm/
>> libwayland-drm.la
>> > -libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
>> > +libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
>> -lstdc++
>>
>> As mentioned by Ken - ideally we won't be pulling C++ into libEGL. Can
>> you give try converting string_to_uint_map to C?
>> Alternatively use the dummy.cpp suggestion from Matt. We already have
>> some examples in the codebase.
>>
>> Thanks
>> Emil
>>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] egl/wayland: Fix linking libEGL_common.la

[Mike Lothian]

This is only an issue when using ld.gold, ld.bfd works fine which is
probably why no one else has seen it. It only started being a problem when
the dmabuff stuff landed and the makefiles were cleaned up

I tried playing around with the dummy.cpp but I couldn't get it to trigger
the c++ compiler

On Fri, 21 Jul 2017 at 13:27 Emil Velikov <emil.l.veli...@gmail.com> wrote:

> On 20 July 2017 at 21:25, Mike Lothian <m...@fireburn.co.uk> wrote:
> > Because libmesautil.la includes string_to_uint_map.o, -lstdc++ is
> > required for linking to succeed
> >
> It's a bit suspicious why not many others are seeing this issue.
> Suspecting the GCC version/build flags has something to do here.
>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851
> >
> > Signed-off-by: Mike Lothian <m...@fireburn.co.uk>
> > ---
> >  src/egl/Makefile.am | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> > index 7c1a4929b8..830ed52b86 100644
> > --- a/src/egl/Makefile.am
> > +++ b/src/egl/Makefile.am
> > @@ -83,7 +83,7 @@ AM_CFLAGS += $(WAYLAND_CFLAGS)
> >  libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
> >  libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
> >  libEGL_common_la_LIBADD += $(top_builddir)/src/egl/wayland/wayland-drm/
> libwayland-drm.la
> > -libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
> > +libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
> -lstdc++
>
> As mentioned by Ken - ideally we won't be pulling C++ into libEGL. Can
> you give try converting string_to_uint_map to C?
> Alternatively use the dummy.cpp suggestion from Matt. We already have
> some examples in the codebase.
>
> Thanks
> Emil
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] egl/wayland: Fix linking libEGL_common.la

[Mike Lothian]

Because libmesautil.la includes string_to_uint_map.o, -lstdc++ is
required for linking to succeed

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101851

Signed-off-by: Mike Lothian <m...@fireburn.co.uk>
---
 src/egl/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
index 7c1a4929b8..830ed52b86 100644
--- a/src/egl/Makefile.am
+++ b/src/egl/Makefile.am
@@ -83,7 +83,7 @@ AM_CFLAGS += $(WAYLAND_CFLAGS)
 libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
 libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
 libEGL_common_la_LIBADD += 
$(top_builddir)/src/egl/wayland/wayland-drm/libwayland-drm.la
-libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la
+libEGL_common_la_LIBADD += $(top_builddir)/src/util/libmesautil.la -lstdc++
 dri2_backend_FILES += drivers/dri2/platform_wayland.c  \
drivers/dri2/linux-dmabuf-unstable-v1-protocol.c
 endif
-- 
2.13.3

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

Re: [Mesa-dev] [PATCH v3 8/8] egl/wayland: Use linux-dmabuf interface for buffers

[Mike Lothian]

Hi

I'm currently getting a build failure with this patch in an out of tree
build

Making all in egl
make[3]: Entering directory
'/var/tmp/portage/media-libs/mesa-/work/mesa--abi_x86_32.x86/src/egl'

/usr/bin/wayland-scanner code <
/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> drivers/dri2/linux-dmabuf-unstable-v1-protocol.c
/usr/bin/wayland-scanner client-header <
/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h
/usr/bin/python2.7
 
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/gen_egl_dispatch.py
source \
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/eglFunctionList.py
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl.xml
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl_other.xml
> g_egldispatchstubs.c
/usr/bin/python2.7
 
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/gen_egl_dispatch.py
header \
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/eglFunctionList.py
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl.xml
\
   
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/egl/generate/egl_other.xml
> g_egldispatchstubs.h
/bin/sh: drivers/dri2/linux-dmabuf-unstable-v1-protocol.c: No such file or
directory
make[3]: *** [Makefile:1609:
drivers/dri2/linux-dmabuf-unstable-v1-protocol.c] Error 1
make[3]: *** Waiting for unfinished jobs
/bin/sh: drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h: No such
file or directory
make[3]: *** [Makefile:1613:
drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h] Error 1

I've checked and
/usr/share/wayland-protocols/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
does exist on my system

Cheers

Mike

On Fri, 14 Jul 2017 at 14:36 Daniel Stone  wrote:

> When available, use the zwp_linux_dambuf_v1 interface to create buffers,
> which allows multiple planes and buffer modifiers to be used.
>
> Reviewed-by: Emil Velikov 
> Signed-off-by: Daniel Stone 
> ---
>  configure.ac|   5 +-
>  src/egl/Makefile.am |  23 +++-
>  src/egl/drivers/dri2/.gitignore |   2 +
>  src/egl/drivers/dri2/egl_dri2.c |   7 ++
>  src/egl/drivers/dri2/egl_dri2.h |  10 ++
>  src/egl/drivers/dri2/platform_wayland.c | 195
> +---
>  6 files changed, 221 insertions(+), 21 deletions(-)
>  create mode 100644 src/egl/drivers/dri2/.gitignore
>
> diff --git a/configure.ac b/configure.ac
> index 46fcd8f3fe..c5803e0f6e 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -88,6 +88,7 @@ LIBOMXIL_BELLAGIO_REQUIRED=0.0
>  LIBVA_REQUIRED=0.38.0
>  VDPAU_REQUIRED=1.1
>  WAYLAND_REQUIRED=1.11
> +WAYLAND_PROTOCOLS_REQUIRED=1.8
>  XCB_REQUIRED=1.9.3
>  XCBDRI2_REQUIRED=1.8
>  XCBGLX_REQUIRED=1.8.1
> @@ -1686,7 +1687,9 @@ for plat in $platforms; do
> case "$plat" in
> wayland)
>
> -   PKG_CHECK_MODULES([WAYLAND], [wayland-client >=
> $WAYLAND_REQUIRED wayland-server >= $WAYLAND_REQUIRED])
> +   PKG_CHECK_MODULES([WAYLAND], [wayland-client >=
> $WAYLAND_REQUIRED wayland-server >= $WAYLAND_REQUIRED wayland-protocols >=
> $WAYLAND_PROTOCOLS_REQUIRED])
> +ac_wayland_protocols_pkgdatadir=`$PKG_CONFIG
> --variable=pkgdatadir wayland-protocols`
> +AC_SUBST(WAYLAND_PROTOCOLS_DATADIR,
> $ac_wayland_protocols_pkgdatadir)
>
> if test "x$WAYLAND_SCANNER" = "x:"; then
> AC_MSG_ERROR([wayland-scanner is needed to compile
> the wayland platform])
> diff --git a/src/egl/Makefile.am b/src/egl/Makefile.am
> index 81090387b5..19295de3ed 100644
> --- a/src/egl/Makefile.am
> +++ b/src/egl/Makefile.am
> @@ -21,6 +21,8 @@
>
>  include Makefile.sources
>
> +BUILT_SOURCES =
> +
>  AM_CFLAGS = \
> -I$(top_srcdir)/include \
> -I$(top_srcdir)/src/egl/main \
> @@ -61,11 +63,27 @@ endif
>  endif
>
>  if HAVE_PLATFORM_WAYLAND
> +WL_DMABUF_XML =
> $(WAYLAND_PROTOCOLS_DATADIR)/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
> +
> +drivers/dri2/linux-dmabuf-unstable-v1-protocol.c: $(WL_DMABUF_XML)
> +   $(MKDIR_GEN)
> +   $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@
> +
> +drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h: $(WL_DMABUF_XML)
> +   $(MKDIR_GEN)
> +   $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@
> +
> +BUILT_SOURCES += \
> +   drivers/dri2/linux-dmabuf-unstable-v1-protocol.c \
> +   drivers/dri2/linux-dmabuf-unstable-v1-client-protocol.h
> +
>  AM_CFLAGS += $(WAYLAND_CFLAGS)
>  libEGL_common_la_LIBADD += $(WAYLAND_LIBS)
>  libEGL_common_la_LIBADD += $(LIBDRM_LIBS)
>  libEGL_common_la_LIBADD += $(top_builddir)/src/egl/wayland/wayland-drm/
> 

Re: [Mesa-dev] configure fails to find llvm since recent llvm commit.

[Mike Lothian]

Hi

I'm not seeing this issue on Gentoo. My llvm-config --version shows
"5.0.0git-79da0992d18"

I'm attaching the patch we use

Regards

Mike

On Tue, 4 Jul 2017 at 10:10 Emil Velikov  wrote:

> On 3 July 2017 at 22:51, Andy Furniss  wrote:
> > Emil Velikov wrote:
> >>
> >> On 3 July 2017 at 16:31, Andy Furniss  wrote:
> >>>
> >>> Rafael Avila de Espindola wrote:
> 
> 
>  What check is configure doing?
> >>>
> >>>
> >>>
> >>> Not sure just a user.
> >>>
>  Is the llvm build a clean one? What is the value of
> LLVM_APPEND_VC_REV?
> >>>
> >>>
> >>>
> >>> It is a clean build.
> >>> A reply to the list advised to start using
> >>>
> >>> -DLLVM_APPEND_VC_REV=OFF
> >>>
> >>> With this it is OK.
> >>>
> >> Skimming through the LLVM it's not obvious what is the before/after
> >> output of `llvm-config --version'. Can anyone share some examples?
> >
> >
> > On current git head, well it was when I started the build from clean,
> > probably not by now :-)
> >
> > Without -DLLVM_APPEND_VC_REV=OFF the output is
> >
> > 5.0.0git-5a8feb7
> >
> > With it, it's
> >
> > 5.0.0svn
> >
> So the version is FOOgit-$SHA while the DSO uses, FOOsvn. At the same
> time at least 3.9.0/3.9.1 has broken llvm-config --libnames/libfiles,
> so we cannot rely on that.
> Doesn't seem like LLVM is giving us something robust to work with here.
>
> LLVM users/devs (Rafael), I would suggest up-streaming a patch which
> changes that toggle default value, for now.
> As LLVM does a few releases where it has a reliable way of determining
> the library name users can switch to it.
>
> How does this sound?
>
> Thanks
> Emil
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


0007-llvm-config-Clean-up-exported-values-update-for-shar.patch
Description: Binary data
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965/miptree: Move isl_surf_get_(hiz|mcs)_surf out of the assert

[Mike Lothian]

On Thu, 22 Jun 2017 at 00:12 Matt Turner <matts...@gmail.com> wrote:

> On Wed, Jun 21, 2017 at 3:50 PM, Mike Lothian <m...@fireburn.co.uk> wrote:
> > Do intel run mesa through any of their test boxes like they do with
> kernel
> > patches?
>
> Don't top quote.
>
> Yes, we have a CI system that we use extensively and has massively
> reduced the number of regressions we have. Immense thanks to Mark
> Janes for all of the work he's done on it.
>
> In this instance, the CI didn't catch it because it tests debug builds
> (as you'd expect), so the assert and the function it called were
> executed. In release builds, however, the assert and that necessary
> function call were removed.
>

Sorry, top posting is the default in Inbox and there doesn't appear to be
away to change it

I wasn't criticising, it's very rare that a serious bug creaps into master,
having said that it would have been nice to have a response on IRC when the
issue was pointed out

Least it's fixed now and I'm back to testing master again

Mike

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

Re: [Mesa-dev] [PATCH] i965/miptree: Move isl_surf_get_(hiz|mcs)_surf out of the assert

[Mike Lothian]

Do intel run mesa through any of their test boxes like they do with kernel
patches?

On Wed, 21 Jun 2017 at 19:23 Jason Ekstrand  wrote:

> On Wed, Jun 21, 2017 at 11:20 AM, Pohjolainen, Topi <
> topi.pohjolai...@gmail.com> wrote:
>
>> On Wed, Jun 21, 2017 at 11:16:39AM -0700, Jason Ekstrand wrote:
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101538
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101539
>>
>> I guess also:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=101535
>>
>> Thanks for the quick fix!!
>>
>
> No problem.  I've landed it now so peoples desktops can start working
> again.
>
>
>> Reviewed-by: Topi Pohjolainen 
>>
>> > Cc: Topi Pohjolainen 
>> > ---
>> >  src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 10 ++
>> >  1 file changed, 6 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > index abc7f98..3b7262f 100644
>> > --- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > +++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
>> > @@ -1672,8 +1672,9 @@ intel_miptree_alloc_mcs(struct brw_context *brw,
>> >  * calculate equivalent MCS surface against it.
>> >  */
>> > intel_miptree_get_isl_surf(brw, mt, _main_surf);
>> > -   assert(isl_surf_get_mcs_surf(>isl_dev, _main_surf,
>> > -_mcs_surf));
>> > +   MAYBE_UNUSED bool ok =
>> > +  isl_surf_get_mcs_surf(>isl_dev, _main_surf,
>> _mcs_surf);
>> > +   assert(ok);
>> >
>> > /* Buffer needs to be initialised requiring the buffer to be
>> immediately
>> >  * mapped to cpu space for writing. Therefore do not use the gpu
>> access
>> > @@ -1832,8 +1833,9 @@ intel_miptree_alloc_hiz(struct brw_context *brw,
>> > struct isl_surf temp_hiz_surf;
>> >
>> > intel_miptree_get_isl_surf(brw, mt, _main_surf);
>> > -   assert(isl_surf_get_hiz_surf(>isl_dev, _main_surf,
>> > -_hiz_surf));
>> > +   MAYBE_UNUSED bool ok =
>> > +  isl_surf_get_hiz_surf(>isl_dev, _main_surf,
>> _hiz_surf);
>> > +   assert(ok);
>> >
>> > const uint32_t alloc_flags = BO_ALLOC_FOR_RENDER;
>> > mt->hiz_buf = intel_alloc_aux_buffer(brw, "hiz-miptree",
>> > --
>> > 2.5.0.400.gff86faf
>> >
>> > ___
>> > 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 00/17] radv: Support for subgroup_vote and shader_ballot

[Mike Lothian]

I found some patches on the git mailing list but looks like none of them
have been merged

http://git.661346.n2.nabble.com/PATCH-send-mail-Add-option-to-sleep-between-sending-each-email-td6769476.html

On Mon, 12 Jun 2017 at 23:22 Connor Abbott  wrote:

> On Mon, Jun 12, 2017 at 2:30 AM, Nicolai Hähnle 
> wrote:
> > FYI, somehow your mails don't show up in a single thread for me. They're
> in
> > groups of 00-04, 05-09, 10-14, 15-17. Not sure what's up with that.
>
> For some reason, the server at Valve rate-limits sending email, so git
> send-email failed when I tried to send them all at once, and I had to
> send some manually. Is there some way to automatically sleep between
> sending emails out?
>
> >
> > On 10.06.2017 01:43, Connor Abbott wrote:
> >>
> >> From: Connor Abbott 
> >>
> >> This series adds all the bits to enable EXT_shader_subgroup_vote and
> >> EXT_shader_subgroup_ballot for radv. It's based on my previous series to
> >> fix some 64-bit bugs in radv and anv, since nothing would work without
> >> them.
> >>
> >> Patches 1-4 are a resend of my previous series to add ARB_shader_ballot
> >> and ARB_shader_group_vote support to NIR, with some changes suggested by
> >> Jason and minor bugfixes. Patches 5-8 add SPIRV-to-NIR support for the
> >> SPIR-V extensions. Finally, the rest of the patches move some of the
> >> existing logic for ARB_shader_ballot and ARB_shader_group_vote into ac
> >> when appropriate and turn on the extension for radv.
> >>
> >> One question I had was about how to handle the differences between
> >> SPIR-V and GL here. SPIR-V decided to make the things that return a
> >> bitmask of invocations return a uvec4, whereas in the GL extension they
> >> return a uint64_t. Right now, in NIR, we use the GL semantics, and we
> >> translate that in vtn. I'm open to changing that, though.
> >
> >
> > Pragmatically, I'd say stick with the GL semantics for now. We'd only
> ever
> > have to change that if somebody decides to build a GPU with 128-wide
> waves,
> > but given how having wider waves increasingly hurts with divergence, that
> > seems unlikely to happen.
> >
> >
> >> I wrote a few crucible tests to test the extension (mostly copied from
> >> the piglit ARB_shader_ballot and ARB_shader_group_vote coverage), which
> >> I'll send out shortly. One of the tests is crashing because of
> >> https://github.com/KhronosGroup/glslang/issues/930, but other than that
> >> it passes the tests.
> >
> >
> > Looks like an alternative GLSL-to-SPIRV compiler would really be nice to
> > have...
> >
> > I've sent comments on some of the patches, mostly the NIR attribute
> stuff.
> > Sorry I didn't notice that sooner.
> >
> > Cheers,
> > Nicolai
> >
> >
> >
> >> I also made sure I didn't regress piglit on
> >> radeonsi. It might be a good idea to run it on Intel's CI system,
> >> especially given patches 5 and 6.
> >>
> >> This series is also available at:
> >> git://people.freedesktop.org/~cwabbott0/mesa radv-shader-ballot
> >>
> >> Connor Abbott (17):
> >>nir: introduce new convergent and cross-thread attributes
> >>nir/gcm: use the new cross-thread attribute
> >>nir: take cross-thread operations into account into a few places
> >>nir: add ARB_shader_ballot and ARB_shader_group_vote instructions
> >>mesa: fix 64-bit issues with system_values_read
> >>compiler: add new system values for SPV_KHR_shader_ballot
> >>nir/lower_system_values: handle SPIR-V shader_ballot system values
> >>nir/spirv: add plumbing for KHR_shader_ballot and KHR_subgroup_vote
> >>ac: add i32_0 convenience member to ac_llvm_context
> >>radeonsi: move llvm_get_type_size() to ac
> >>radeonsi: move emit_optimization_barrier() to ac
> >>ac: add i64 type to ac_llvm_context
> >>radeonsi: move si_emit_ballot() to ac
> >>ac: add i32_1 convenience member to ac_llvm_context
> >>radeonsi: move the guts of ARB_shader_group_vote emission to ac
> >>ac: enable the AMDGPU asm parser
> >>radv/ac: enable EXT_shader_subgroup_ballot and
> >>  EXT_shader_subgroup_vote
> >>
> >>   src/amd/common/ac_llvm_build.c | 127
> >> +++
> >>   src/amd/common/ac_llvm_build.h |  18 
> >>   src/amd/common/ac_llvm_util.c  |   4 +
> >>   src/amd/common/ac_nir_to_llvm.c|  75 
> >>   src/amd/vulkan/radv_device.c   |   8 ++
> >>   src/amd/vulkan/radv_pipeline.c |   2 +
> >>   src/compiler/nir/nir.c |  28 ++
> >>   src/compiler/nir/nir.h |  80 +
> >>   src/compiler/nir/nir_instr_set.c   |  22 +
> >>   src/compiler/nir/nir_intrinsics.h  |  30 +++
> >>   src/compiler/nir/nir_lower_system_values.c |  38 
> >>   src/compiler/nir/nir_opt_gcm.c |  72 +--
> >>   src/compiler/nir/nir_opt_peephole_select.c |  11 

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Mike Lothian]

I'm quite sure on Gentoo lib points to lib64 and we have a lib32

On Mon, 22 May 2017 at 22:46 Rob Herring  wrote:

> On Mon, May 22, 2017 at 9:16 AM, Emil Velikov 
> wrote:
> > On 20 May 2017 at 01:16, Rob Herring  wrote:
> >> On Fri, May 19, 2017 at 12:57 PM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> >>> On 18 May 2017 at 23:01, Rob Herring  wrote:
>  On Thu, May 18, 2017 at 5:25 AM, Emil Velikov <
> emil.l.veli...@gmail.com> wrote:
> > On 18 May 2017 at 05:10, Chih-Wei Huang 
> wrote:
> >> 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>>
>  -Original Message-
>  From: Palli, Tapani
>  >
>  > It's just applied. Isn't it?
>  > Yesterday without this patch
>  > the color format is mismatch apparently.
> 
>  Yeah we do need this. TBH I don't quite understand why but will
> try to figure
>  it out. I remember we used to have a patch in Surfaceflinger at
> one point
>  because visual was hardcoded there and this might be related.
> 
>  // Tapani
> >>>
> >>> Sorry, that's for different issue, I mix it with RGB565 blending
> one.
> >>> This patch is required because some Android GLES test apps, like
> gl2_basic, need to create RGBA surface.
> >>
> >> Indeed it is.
> >>
> >> As Emil pointed out, the patch was merged before
> >> but reverted later since it broke desktop.
> >>
> >> So what's the current upstreaming plan?
> >>
> > No idea about a plan, but how you can fix it once and for all:
> >
> > Extend the loader extension(s) to have a get_caps() callback,
> > analogous to __DRIimageExtension::getCapabilities.
> > Then the DRI module will query [the loader] and advertise the
> > RGBX/RGBA visuals when possible.
> 
>  Could we do something compile time instead to enable just for Android?
>  Seems like a lot of complexity when the platform needing these pixel
>  formats doesn't need the backwards compatibility. Or maybe there are
>  other things needing this interface?
> 
> >>> Having a short/mid term ifdef ANDROID is perfectly fine.
> >>>
> >>> Can we address some of the existing ones before/alongside the newly
> added ones?
> >>> Afacit the nouveau bits are no longer applicable.
> >>
> >> Yeah. I don't explicitly warn for KK or less, but will add that and fix
> these.
> >>
> >>> While for the
> >>> gbm/egl 'use "gallium_dri.so"' one can either use your latest build
> >>> rework or MESA_LOADER_DRIVER_OVERRIDE.
> >>
> >> How does the build rework help? My only reservation with using an env
> >> var is generally Android things don't rely on them and it would break
> >> working systems. I'm not even completely certain I can set env vars
> >> globally. It would be nice if the build system could set defaults for
> >> env vars we could use.
> >>
> > IIRC with the rework you have the dri driver names are known as we
> > reach targets/dri/Android.mk
>
> Not really because we have things like freedreno -> msm and virgl ->
> virtio_gpu, but having a variable like TARGET_DRIVERS is simple
> enough.
>
> > Thus one can reuse them to create the separate drivers
> >   - be that one blob + {sym,hard}links as we do in autotools/scons, or
> >  - completely separate drivers like i965 and other classic drivers.
>
> Got it. Symlinks are really easy in master:
>
> LOCAL_MODULE_SYMLINKS := $(foreach d, $(GALLIUM_TARGET_DRIVERS),
> $(d)_dri.so)
>
> However, that only works in master. There is LOCAL_POST_INSTALL_CMD,
> but it doesn't support multilib, so we need something like this:
>
> LOCAL_POST_INSTALL_CMD := \
> $(foreach l, lib lib64, \
>  mkdir -p $(TARGET_OUT_SHARED_LIBRARIES)/$(l)/$(MESA_DRI_MODULE_REL_PATH);
> \
>  $(foreach d, $(GALLIUM_TARGET_DRIVERS), ln -sf gallium_dri.so
> $(TARGET_OUT)/$(l)/$(MESA_DRI_MODULE_REL_PATH)/$(d)_dri.so;) \
> )
>
> This will install broken links when we're not on a multilib build. A
> bit ugly, but should be harmless.
>
> Rob
> ___
> 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] [Bug 101088] `gallium: remove pipe_index_buffer and set_index_buffer` causes glitches and crash in gallium nine

[Mike Lothian]

This fixes WoW for me

Thanks

On Mon, 22 May 2017 at 00:18  wrote:

> *Comment # 4  on
> bug 101088  from Axel
> Davy  *
>
> Should be fixed 
> byhttps://lists.freedesktop.org/archives/mesa-dev/2017-May/156453.html
>
> Please confirm.
>
> --
> 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
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [PATCH] i965: Add RGBX8888 and RGBA8888 to EGL configure and reorder the list

[Mike Lothian]

Can you make sure whatever you do it's well tested

I shudder every time I see such requests as it nearly always seems to cause
breakage for me

On Thu, 18 May 2017 at 11:25 Emil Velikov  wrote:

> On 18 May 2017 at 05:10, Chih-Wei Huang  wrote:
> > 2017-05-18 12:01 GMT+08:00 Xu, Randy :
> >>
> >>> -Original Message-
> >>> From: Palli, Tapani
> >>> >
> >>> > It's just applied. Isn't it?
> >>> > Yesterday without this patch
> >>> > the color format is mismatch apparently.
> >>>
> >>> Yeah we do need this. TBH I don't quite understand why but will try to
> figure
> >>> it out. I remember we used to have a patch in Surfaceflinger at one
> point
> >>> because visual was hardcoded there and this might be related.
> >>>
> >>> // Tapani
> >>
> >> Sorry, that's for different issue, I mix it with RGB565 blending one.
> >> This patch is required because some Android GLES test apps, like
> gl2_basic, need to create RGBA surface.
> >
> > Indeed it is.
> >
> > As Emil pointed out, the patch was merged before
> > but reverted later since it broke desktop.
> >
> > So what's the current upstreaming plan?
> >
> No idea about a plan, but how you can fix it once and for all:
>
> Extend the loader extension(s) to have a get_caps() callback,
> analogous to __DRIimageExtension::getCapabilities.
> Then the DRI module will query [the loader] and advertise the
> RGBX/RGBA visuals when possible.
>
> -Emil
> ___
> 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/18] anv: Rework the allocation data structures

[Mike Lothian]

I'm seeing the following failure with GCC 7.1:

/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:
In function ‘anv_state_stream_alloc’:
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:930:28:
error: ‘struct anv_state_stream_block’ has no member named ‘_vg_ptr’
   VG_NOACCESS_WRITE(>_vg_ptr, NULL);
^
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:53:44:
note: in definition of macro ‘VG_NOACCESS_WRITE’
 #define VG_NOACCESS_WRITE(__ptr, __val) (*(__ptr) = (__val))
^
At top level:
/var/tmp/portage/media-libs/mesa-/work/mesa-/src/intel/vulkan/anv_allocator.c:1214:1:
warning: ‘anv_bo_cache_lookup’ defined but not used [-Wunused-function]
 anv_bo_cache_lookup(struct anv_bo_cache *cache, uint32_t gem_handle)
 ^~~


On Thu, 4 May 2017 at 09:09 Juan A. Suarez Romero 
wrote:

> On Tue, 2017-05-02 at 06:44 -0700, Jason Ekstrand wrote:
> > Juan,
> >
> > Were you planning to review the rest of the series?  Just wondering.
> >
>
> Sorry, it took a bit more to review the remaining patches.
>
> Now it is done.
>
>
> J.A.
>
> > --Jason
> >
> >
> > On April 26, 2017 7:35:29 AM Jason Ekstrand 
> wrote:
> >
> > > This absurdly long series does something fairly simple:  It pulls the
> > > block_pool into the state_pool and makes the state pool capable of
> > > allocating states larger than the block size.  Unfortunately, there
> was no
> > > good way to do it in less than 18 patches. :-(
> > >
> > > Cc: Juan A. Suarez Romero 
> > >
> > > Jason Ekstrand (18):
> > >   anv/allocator: Add no-valgrind versions of state_pool_alloc/free
> > >   anv/allocator: Return a null state for zero-size allocations
> > >   anv/allocator: Convert the state stream to pull from a state pool
> > >   anv: Get rid of a bunch of uses of size_t
> > >   anv/allocator: Remove the state_size field from fixed_size_state_pool
> > >   anv/allocator: Roll fixed_size_state_pool into state_pool
> > >   anv/allocator: Pull the userptr part of block_pool_grow into a helper
> > >   anv/allocator: Drop the block_size field from block_pool
> > >   anv/allocator: Add support for "back" allocations to state_pool
> > >   anv: Allocate binding table blocks through the state pool
> > >   anv/allocator: Get rid of the ability to free blocks
> > >   anv/allocator: Embed the block_pool in the state_pool
> > >   anv/allocator: Rework a comment
> > >   anv/allocator: Add the capability to allocate blocks of different
> > > sizes
> > >   anv/allocator: Add helpers for dealing with bucket sizes
> > >   anv/allocator: Support pushing multiple blocks onto a free list at
> > > once
> > >   anv/allocator: Allow state pools to allocate large states
> > >   anv: Drop the instruction pool block size
> > >
> > >  src/intel/vulkan/anv_allocator.c   | 589
> -
> > >  src/intel/vulkan/anv_batch_chain.c |  84 ++-
> > >  src/intel/vulkan/anv_blorp.c   |   4 +-
> > >  src/intel/vulkan/anv_cmd_buffer.c  |   8 +-
> > >  src/intel/vulkan/anv_descriptor_set.c  |   4 +-
> > >  src/intel/vulkan/anv_device.c  |  26 +-
> > >  src/intel/vulkan/anv_gem.c |   2 +-
> > >  src/intel/vulkan/anv_gem_stubs.c   |   2 +-
> > >  src/intel/vulkan/anv_private.h |  74 +--
> > >  src/intel/vulkan/gen8_cmd_buffer.c |   6 +-
> > >  src/intel/vulkan/genX_blorp_exec.c |   2 +-
> > >  src/intel/vulkan/genX_cmd_buffer.c |  15 +-
> > >  src/intel/vulkan/tests/block_pool_no_free.c|   8 +-
> > >  src/intel/vulkan/tests/state_pool.c|   5 +-
> > >  src/intel/vulkan/tests/state_pool_free_list_only.c |   5 +-
> > >  src/intel/vulkan/tests/state_pool_no_free.c|   5 +-
> > >  16 files changed, 461 insertions(+), 378 deletions(-)
> > >
> > > --
> > > 2.5.0.400.gff86faf
> > >
> >
> >
> >
> ___
> 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 17.1.0-rc3

[Mike Lothian]

Hi

I think this email is sent from a script so just wanted to point out:

not available -> now available

If it's just a bog standard typo in a manually written email - just ignore
me

Mike

On Mon, 1 May 2017 at 13:24 Emil Velikov  wrote:

> Hello all,
>
> The third release candidate for Mesa 17.1.0 is not available.
>
>
> Andres Gomez (2):
>   travis: replace Trusty-based LLVM toolchain apt-get with apt addon
>   travis: add the possibility of using the txc-dxtn library
>
> Emil Velikov (15):
>   travis: explicitly LD_LIBRARY_PATH the local libraries
>   travis: enable apt cache
>   travis: automatically manage ccache caching
>   travis: remove unused -dev packages
>   travis: rework "if test" blocks in the script section
>   travis: split out matrix from env
>   travis: add separate "scons" and "scons llvm" targets
>   travis: add "scons swr" to the build matrix
>   travis: add "make swr" to the build matrix
>   travis: split the make target to three separate ones
>   travis: model scons check target like the make one
>   travis: add Gallium state-tracker targets
>   travis: enable wayland support
>   travis: bump MAKEFLAGS to -j4
>   Update version to 17.1.0-rc3
>
> Francisco Jerez (2):
>   intel/fs: Use regs_written() in spilling cost heuristic for
> improved accuracy.
>   intel/fs: Take into account amount of data read in spilling cost
> heuristic.
>
> Ilia Mirkin (1):
>   gallium/targets: fix bool setting on BE architectures
>
> Jason Ekstrand (2):
>   anv: Don't place scratch buffers above the 32-bit boundary
>   anv/cmd_buffer: Use the device allocator for QueueSubmit
>
> Kenneth Graunke (1):
>   i965/vec4: Avoid reswizzling MACH instructions in
> opt_register_coalesce().
>
> Marek Olšák (7):
>   radeonsi/gfx9: fix texture buffer objects and image buffers with
> IDXEN==0
>   radeonsi/gfx9: fix most things wrong with shader images
>   radeonsi/gfx9: fix 1D array shader images
>   radeonsi/gfx9: add a workaround for viewing a slice of 3D as a 2D
> image
>   radeonsi/gfx9: set MAX_PRIMGRP_IN_WAVE in the correct register
>   radeonsi/gfx9: don't set deprecated field PARTIAL_ES_WAVE_ON
>   radeonsi: adjust ESGS ring buffer size computation on VI
>
> Nicolai Hähnle (1):
>   st/mesa: don't cast the incomplete framebufer to st_framebuffer
>
> Timothy Arceri (3):
>   disk_cache: reduce default cache size to 5% of filesystem
>   disk_cache: use block size rather than file size
>   util/disk_cache: remove percentage based max cache limit
>
> git tag: mesa-17.1.0-rc3
>
> https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.tar.gz
> MD5:  d84e7611ea97c74b6e5c0e8c957ca133  mesa-17.1.0-rc3.tar.gz
> SHA1: f5821fea3c614d643eb82880596936d0c9df34d7  mesa-17.1.0-rc3.tar.gz
> SHA256: 8d162d72b85457b6614865c6c1dab4670300c88904266580330bb1ce81d6023f
>  mesa-17.1.0-rc3.tar.gz
> SHA512:
> 704f20fd47672f1e4c9c7e822b7c6e575cbedddb3a813b3f1c27d02e1531a4ac7a28142c5ef0c98dbe6ccd1c3a8062f04fccb360eb82507d89c6d8dd8c33f433
>  mesa-17.1.0-rc3.tar.gz
> PGP:  https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.tar.gz.sig
>
> https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.tar.xz
> MD5:  0630035d846918e5b291b2a893d066b2  mesa-17.1.0-rc3.tar.xz
> SHA1: b8d9bcb63462167de9ee83f2093552fa49679c90  mesa-17.1.0-rc3.tar.xz
> SHA256: 52831657b7ac64b3dd4899f2f6d995c062fc77ac436017470daddfc1ebc0e85e
>  mesa-17.1.0-rc3.tar.xz
> SHA512:
> b5f5d2d517fb92fa1d31a44b88cf7c00fbe186747482c2286e97a352c016719c6454a79f777df6a8540997df464820cb1a8c2e3054a26517bb062b25e1a2d114
>  mesa-17.1.0-rc3.tar.xz
> PGP:  https://mesa.freedesktop.org/archive/mesa-17.1.0-rc3.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 0/4] Call for testing: Gallium set_index_buffer removal etc.

[Mike Lothian]

Hi

I've just tested this with Nine. It causes a weird white strobing effect -
I think there are other graphical glitches too but it's hard to tell

I was testing the blizzard app http://eu.battle.net/en/app/ the same also
happens when World of Warcraft is launched

This doesn't happen if I use CSMT rather than Nine

Cheers

Mike

On Sat, 29 Apr 2017 at 00:12 Marek Olšák  wrote:

> Hi,
>
> This series shrinks various gallium structures and removes
> set_index_buffer in order to decrease CPU overhead.
>
>
> PART 1: Performance results
>
> All testing below was done with radeonsi, and I used the drawoverhead
> microbenchmark from mesa/demos ported to piglit and using GL 3.0
> Compat and GL 3.2 Core (same GL states in both contexts).
>
> 1) Performance difference for the removal of set_index_buffer only:
>
>   Compat: DrawElements: 5.1 -> 5.3 million draws/second
>   Core:   DrawElements: 5.1 -> 5.5 million draws/second
>
> The result is better for the core profile where u_vbuf is disabled.
>
>
> 2) Performance difference with all 4 patches (Core profile only)
>
>DrawArrays: 8.3 -> 8.5 million draws/second
>DrawElements: 5.2 -> 5.8 million draws/second
>
>
> 3) Performance difference with threaded Gallium (Core profile only):
>
>DrawElements: 5.9 -> 7.1 million draws/second
>
> Threaded Gallium is still work in progress and might require
> a non-trivial amount of driver work.
>
>
> PART 2: Call for testing
>
> These drivers have been tested:
> - ddebug
> - llvmpipe
> - r300 (also with SWTCL)
> - r600
> - radeonsi
> - softpipe
> - trace
>
> These drivers need testing:
> - etnaviv
> - freedreno
> - nv30
> - nv50
> - nvc0
> - svga
> - swr
> - vc4
> - virgl
>
> The following state trackers might need testing:
> - nine
>
> You can get the patches by fetching:
>   git://people.freedesktop.org/~mareko/mesa gallium-cleanup
>
> I'd like to ask to you for testing drivers that I couldn't test.
> Please let me know when you're done testing and if things are good.
> After that, I'll push everything assuming the code review goes well.
> You can also ignore this if you don't mind fixing your driver in
> the master branch later.
>
> Thanks,
>
> 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] clover: Fix build against clang SVN >= r301442

[Mike Lothian]

Tested-and-reviewed-by: Mike Lothian <m...@fireburn.co.uk>

On Thu, 27 Apr 2017 at 04:33 Michel Dänzer <mic...@daenzer.net> wrote:

> From: Michel Dänzer <michel.daen...@amd.com>
>
> Hardcode the OpenCL InputKind in compat::set_lang_defaults.
>
> Signed-off-by: Michel Dänzer <michel.daen...@amd.com>
> ---
>  src/gallium/state_trackers/clover/llvm/compat.hpp | 10 ++
>  src/gallium/state_trackers/clover/llvm/invocation.cpp |  2 +-
>  2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/state_trackers/clover/llvm/compat.hpp
> b/src/gallium/state_trackers/clover/llvm/compat.hpp
> index cee51b9dd1..ee8c2a78e4 100644
> --- a/src/gallium/state_trackers/clover/llvm/compat.hpp
> +++ b/src/gallium/state_trackers/clover/llvm/compat.hpp
> @@ -76,14 +76,16 @@ namespace clover {
>
>   inline void
>   set_lang_defaults(clang::CompilerInvocation ,
> -   clang::LangOptions , clang::InputKind ik,
> +   clang::LangOptions ,
> const ::llvm::Triple ,
> clang::PreprocessorOptions ,
> clang::LangStandard::Kind std) {
> -#if HAVE_LLVM >= 0x0309
> -inv.setLangDefaults(lopts, ik, t, ppopts, std);
> +#if HAVE_LLVM >= 0x0500
> +inv.setLangDefaults(lopts, clang::InputKind::OpenCL, t,
> ppopts, std);
> +#elif HAVE_LLVM >= 0x0309
> +inv.setLangDefaults(lopts, clang::IK_OpenCL, t, ppopts, std);
>  #else
> -inv.setLangDefaults(lopts, ik, std);
> +inv.setLangDefaults(lopts, clang::IK_OpenCL, std);
>  #endif
>   }
>
> diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> index deebef5726..64c0ec4c23 100644
> --- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
> +++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
> @@ -126,7 +126,7 @@ namespace {
>c->getDiagnosticOpts().ShowCarets = false;
>
>compat::set_lang_defaults(c->getInvocation(), c->getLangOpts(),
> -clang::IK_OpenCL,
> ::llvm::Triple(target.triple),
> +::llvm::Triple(target.triple),
>  c->getPreprocessorOpts(),
>  clang::LangStandard::lang_opencl11);
>
> --
> 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 00/14] Better Travis-CI integration, take 2

[Mike Lothian]

Use a lower make j number and make sure you're not using LTO

On Fri, 21 Apr 2017, 2:33 pm Emil Velikov,  wrote:

> On 21 April 2017 at 13:25, Gustaw Smolarczyk  wrote:
> > 2017-04-21 14:08 GMT+02:00 Emil Velikov :
> >> Note: GCC 5/6 crashes with internal compiler error at seemingly random
> >> stages of the build. Unless any of the SWR devs sort it out, we might
> >> want to disable it for now.
> >>
> >> A sample report can be seen at
> >> https://travis-ci.org/evelikov/Mesa/builds/223590028
> >
> >
> > Hello,
> >
> > The ICEs look like an external factor is involved.
> >
> >> g++-5: internal compiler error: Killed (program cc1plus)
> >
> > Looks like someone killed the cc1plus process. Maybe too much memory
> > was used and kernel OOM killer was unleashed?
> >
> Perfectly possible, although I doubt it since
>  - SWR + Autotools has no issues
>  - building SCons + SWR alongside Chromium with two dozen tabs, barely
> reaches 2.5G while the instance should have 4GiB.
>
> In either case - if anyone has suggestions how to address this I'm all
> ears.
>
> -Emil
> ___
> 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