Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Hi Vinson,
ah sorry, CMAKE_INSTALL_PREFIX=~/code/llvm/build/result.
and you have to run make install.
Tobias
Am Samstag, 3. Dezember 2016, 23:54:37 CET schrieb Tobias Droste:
> Hi Vinson,
>
> are you sure you are using the correct one?
>
> I'm building llvm in ~/code/llvm.
> CMAKE_INSTALL_PREF
Hi Vinson,
are you sure you are using the correct one?
I'm building llvm in ~/code/llvm.
CMAKE_INSTALL_PREFIX is set to ~/code/llvm/build.
The final build results ends in ~/code/llvm/build/result (and not ~/code/llvm/
build)!
If you use ~/code/llvm/build/bin/llvm-config you get wrong values.
Yo
Seeing gtk+ application lockup when they query the buffer age of a surface.
Since we update the buffer age field only when creating buffers & swaping
them on the client side, there shouldn't be any need for requesting a new
back buffer if there is already one available.
Signed-off-by: Lionel Land
https://bugs.freedesktop.org/show_bug.cgi?id=84016
--- Comment #1 from Lionel Landwerlin ---
Just had the same lockup with Evolution :
Thread 1 "evolution" received signal SIGINT, Interrupt.
0x7f1535d4c56d in poll () at ../sysdeps/unix/syscall-template.S:84
84 in ../sysdeps/unix/syscall
Hi, Tobias.
/bin/llvm-config --includedir returns /include. I am
not setting the "--with-llvm-prefix" configure option.
Cheers,
Vinson
On Sat, Dec 3, 2016 at 1:46 PM, Tobias Droste wrote:
> Hi Vinson,
>
>
>
> why is LLVM_INCLUDEDIR not /include? How does this happen?
>
> Do you set "--with-llv
On Mon, Nov 28, 2016 at 5:19 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> This isn't fully what we want yet, but is a good step on the way.
>
> This allows the compiler to create the information structures
> for the state setting side, however the state setting still expects
> things to be pret
Hi Vinson,
why is LLVM_INCLUDEDIR not /include? How does this happen?
Do you set "--with-llvm-prefix=" when building mesa?
Tobias
Am Samstag, 3. Dezember 2016, 11:53:53 CET schrieb Vinson Lee:
> Hi, Tobias.
>
> I actually need this when using LLVM from a build tree and the header
> files are n
Hi, Tobias.
I actually need this when using LLVM from a build tree and the header
files are not found. LLVM_INCLUDEDIR is /include and the
header files are in /include.
Cheers,
Vinson
On Sat, Dec 3, 2016 at 4:55 AM, Tobias Droste wrote:
> Hi Vinson,
>
> this should not be needed and is obsolete
On 3 Dec 2016 4:40 pm, "Jason Ekstrand" wrote:
On Dec 3, 2016 8:27 AM, "Lionel Landwerlin" wrote:
That's on Haswell.
I'm not sure whether a 3d image with multiple layers makes sense, but
if it does, it should probably return different depth/layer pitch
values?
It does not. You can't have 3
On Dec 2, 2016 4:43 PM, "Jordan Justen" wrote:
On 2016-12-01 16:19:49, Jason Ekstrand wrote:
> On Wed, Nov 30, 2016 at 8:12 PM, Jordan Justen
> wrote:
>
> > +
> > + x_offset_sa = (uint32_t)*x0 * px_size_sa.w + info->tile_x_sa;
> > + y_offset_sa = (uint32_t)*y0 * px_size_sa.h + info->tile_y_s
On Dec 3, 2016 8:27 AM, "Lionel Landwerlin" wrote:
That's on Haswell.
I'm not sure whether a 3d image with multiple layers makes sense, but
if it does, it should probably return different depth/layer pitch
values?
It does not. You can't have 3D arrays. Haswell should probably return 0
for bot
That's on Haswell.
I'm not sure whether a 3d image with multiple layers makes sense, but
if it does, it should probably return different depth/layer pitch
values?
On Sat, 2016-12-03 at 08:22 -0800, Jason Ekstrand wrote:
> What hardware are you running on? Prior to sky lake, depth pitch
> makes so
What hardware are you running on? Prior to sky lake, depth pitch makes so
sense for us. On sky lake and above it should be exactly the same as array
pitch. One thing we should do is not report array pitch for 3D and maybe
report a depth pitch of zero on broadwell and earlier.
On Dec 3, 2016 7:5
From: Roland Scheidegger
Just like other similar compressed formats.
---
src/gallium/auxiliary/util/u_format.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/gallium/auxiliary/util/u_format.c
b/src/gallium/auxiliary/util/u_format.c
index 72dd60f..3d28190 100644
--- a/src/gallium/a
From: Roland Scheidegger
Note that we really want to _never_ reach the bottom of the function, which
resorts to AoS fetch.
Half floats can be handled just like other formats which fit into 32bit
vectors (so, only 1x16 and 2x16 formats, albeit with more channels things
are not THAT bad), with mini
From: Roland Scheidegger
By using a dst_type in the the gather interface, gather has some more
knowledge about how values should be fetched.
E.g. if this is a 3x32bit fetch and dst_type is 4x32bit vector gather
will no longer do a ZExt with a 96bit scalar value to 128bit, but
just fetch the 96bit
From: Roland Scheidegger
Trivial, this just resurrects the code which was there once upon a time
(the code can't lower instructions generated in the lowering pass there,
and even if it could it would probably be suboptimal).
This fixes piglit mesa_shader_integer_functions fs-ldexp.shader_test and
With a 3d image of 2x2x3, vkGetImageSubresourceLayout currently reports :
VkSubresourceLayout = { offset = 0,
size = 160,
rowPitch = 16,
arrayPitch = 96,
depthPitch = 96 }
depthPitch should be 32.
Sig
Hi Vinson,
this should not be needed and is obsolete as soon as this gets merged (Emil?):
https://lists.freedesktop.org/archives/mesa-dev/2016-November/135840.html
Did you actually need this or were you just seeing that the code is wrong?
Because LLVM >=3.1 has the header files and this code shou
20 matches
Mail list logo
