+Brian
I just want to make sure he doesn't miss the thread.
On Thu, May 24, 2018 at 5:27 PM, Laura Ekstrand
wrote:
> It's time to move the Mesa-3d.org website into the 21st century. We have
> chosen to move to Sphinx and resStructured text for a number of reasons:
> 1. Syntax highlighting
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.
https://bugs.freedesktop.org/show_bug.cgi?id=106696
--- Comment #7 from Dave Gilbert ---
(In reply to Nicolai Hähnle from comment #5)
> Yes, that is a known issue, but this particular bug report is not the way to
> cover it, so closing it again.
OK, fair enough - which one should I be
On Sat, Jun 2, 2018 at 12:07 PM, Jason Ekstrand wrote:
> All,
>
> This is for those of you who wish to have your personal mesa repo on gitlab.
> If you want to keep it on people.freedesktop.org and use cgit, you are more
> than welcome to continue doing so for the foreseeable future and you can
>
From: Bernd Kuhls
Fix musl build when svga gallium driver is enabled.
In file included from vmw_fence.c:34:0:
vmw_screen.h:100:4: error: unknown type name ‘dev_t’
dev_t device;
^
Downloaded from
http://git.alpinelinux.org/cgit/aports/plain/main/mesa/musl-fixes.patch
Signed-off-by:
All,
This is for those of you who wish to have your personal mesa repo on
gitlab. If you want to keep it on people.freedesktop.org and use cgit, you
are more than welcome to continue doing so for the foreseeable future and
you can ignore this e-mail. For those who want to use gitlab, read on...
All,
I just wanted to give a quick status update and planned timeline for the
GitLab move. In case you missed the original e-mail (and lively
discussion), you can find it here:
https://lists.freedesktop.org/archives/mesa-dev/2018-May/195634.html
If you have not yet set up your gitlab SSH keys,
https://bugs.freedesktop.org/show_bug.cgi?id=106784
Bug ID: 106784
Summary: 18.1.1 autotools build fail without mako
Product: Mesa
Version: 18.0
Hardware: Other
OS: All
Status: NEW
Severity: normal
Hey Mathias,
mathias.froehl...@gmx.net wrote on 02.06.2018 08:51:
> The below patch fixes a recently introduced failure of my VAO rework.
> I could finally reproduce the problem using the provided apitrace
> (thanks Kai for the hint with the lower left corner).
yw, thanks for looking into this!
Otherwise on pre-GFX9, if the constant layout allows both TESS_EVAL and
GEOMETRY shaders, but the PIPELINE has only GEOMETRY, it would return the
GEOMETRY shader for the TESS_EVAL shader.
This would cause the flush_constants code to emit the GEOMETRY constants
to the TESS_EVAL registers and then
On 02/06/18 04:34, Ian Romanick wrote:
On 05/31/2018 10:37 PM, Timothy Arceri wrote:
This pass detects potential loop terminators and moves intructions
from the non breaking branch after the if.
This enables both the new opt_if_simplification() pass and loop
unrolling to potentially progress
If you lookup the declartion of buffer_subdata and texture_subdata,
you'll see the parameters differ for these two methods, except for the
very first two.
Yet trace_context_transfer_unmap was emitting the same parameters for
both.
But you're right, I left this half done somehow - I forgot
Quoting mathias.froehl...@gmx.net (2018-05-17 07:38:27)
> From: Mathias Fröhlich
>
> The merge_inputs function handles that part that changes when the
> inputs change. The clear_buffers function triggers when we may need
> a new upload. Thus the merge_inputs can be limited to be once
> per
Quoting mathias.froehl...@gmx.net (2018-05-17 07:38:26)
> From: Mathias Fröhlich
>
> Avoid looping over all VARYING_SLOT_MAX urb_setup array
> entries from genX_upload_sbe. Prepare an array indirection
> to the active entries of urb_setup already in the compile
> step. On upload only walk the
Hi,
I know, that one of the third patch is intrusive, but I was finally running
out of ideas how to split the third patch into sensible smaller chunks.
So can somebody take a look?
Thanks!
best
Mathias
> From: Mathias Fröhlich
>
> Hi all,
>
> This change finally makes use of the
From: Mathias Fröhlich
Bail out with out of memory, when the required stride exceeds the
maximum possible stride as stored in Const.MaxVertexAttribStride.
Etnaviv can only handle less than the OpenGL standard mandated
minimum of 2048. For this one, at least give some 'resource
exhaustion error'
From: Mathias Fröhlich
Mention how this is supposed to work where the constant is declared.
Signed-off-by: Mathias Fröhlich
---
src/mesa/main/mtypes.h | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/mtypes.h b/src/mesa/main/mtypes.h
index
From: Mathias Fröhlich
Bail out with out of memory, when the required stride exceeds the
maximum possible stride as stored in Const.MaxVertexAttribStride.
Etnaviv can only handle less than the OpenGL standard mandated
minimum of 2048. For this one, at least give some 'resource
exhaustion error'
From: Mathias Fröhlich
Hi,
Turns out that the MaxVertexAttribStride constant value
is not set by all drivers as I expected to be set.
Expecially virgl may run on top of an OpenGL stack that
is too old to allow the query of GL_MAX_VERTEX_ATTRIB_STRIDE.
So, allow setting that
From: Mathias Fröhlich
Hi all,
The below patch fixes a recently introduced failure of my VAO rework.
I could finally reproduce the problem using the provided apitrace
(thanks Kai for the hint with the lower left corner).
The change is slightly different than what I put initially into the
20 matches
Mail list logo