On Saturday, October 1, 2016 9:46:45 PM PDT Marek Olšák wrote:
> Hi,
>
> I propose that we use versioning in the form of "year.quarter".
>
> 2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
> quarters of the year, respectively.
> 2018 would start with 18.0, then 18.1, 18.2, 18.3.
>
On Sep 26, 2016 3:00 AM, "Eric Engestrom" wrote:
>
> On Sun, Sep 25, 2016 at 10:49:29AM -0700, Jason Ekstrand wrote:
> > I hope you realize that this is the only truly useful change in the
series.
> > :-). Still, no reason why our silly little helpers shouldn't be correct.
>
> Yeah, I know :P
> I
Bump...
On Thu, Sep 15, 2016 at 9:33 PM, Dave Airlie wrote:
> On 16 September 2016 at 14:16, Jason Ekstrand
> wrote:
> > Previously, we were saving off the last nir_block in a vtn_block before
> > moving on so that we could find the nir_block again when it came time to
> > handle phi sources.
I don't think your fix with the symlinks is correct. You've just
worked-around one part of the problem (missing include directories)
leaving the total lack of detection of llvm alone. Now you lack the
HAVE_LLVM define that should be automatically created by the build
system if it recognizes llvm co
On 01.10.2016 21:46, Marek Olšák wrote:
Hi,
I propose that we use versioning in the form of "year.quarter".
2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
quarters of the year, respectively.
2018 would start with 18.0, then 18.1, 18.2, 18.3.
The motivation is that you can ea
I could get behind that. The only other thing that makes sense to me would
be to drop minor versoning all together and just have an incrementing
integer (with patch releases for stable, of course). The year.quarter
scheme is fine with me too.
On Sat, Oct 1, 2016 at 12:46 PM, Marek Olšák wrote:
Hi,
I propose that we use versioning in the form of "year.quarter".
2017 would start with 17.0, then 17.1, 17.2, 17.3 for following
quarters of the year, respectively.
2018 would start with 18.0, then 18.1, 18.2, 18.3.
The motivation is that you can easily tell when a specific Mesa
version was r
On Sunday 27 September 2015 11:15:14 Serge Martin wrote:
> add clGetExtensionFunctionAddressForPlatform (CL 1.2)
ping (one year reminder :p )
> ---
> src/gallium/state_trackers/clover/api/dispatch.cpp | 2 +-
> src/gallium/state_trackers/clover/api/dispatch.hpp | 4
> src/gallium/state_tr
CL_PROGRAM_BINARY_TYPE have been added to clGetProgramBuildInfo in CL1.2
---
src/gallium/state_trackers/clover/api/program.cpp | 5 +
src/gallium/state_trackers/clover/core/module.cpp | 1 +
src/gallium/state_trackers/clover/core/module.hpp | 5 +
src/gallium/
---
src/gallium/state_trackers/clover/api/device.cpp | 23 +++
src/gallium/state_trackers/clover/core/device.cpp | 10 ++
src/gallium/state_trackers/clover/core/device.hpp | 2 ++
3 files changed, 35 insertions(+)
diff --git a/src/gallium/state_trackers/clover/api/de
Updated serie, please review.
Serge Martin (2):
clover: add CL_PROGRAM_BINARY_TYPE support (CL1.2)
clover: add missing clGetDeviceInfo CL1.2 queries
src/gallium/state_trackers/clover/api/device.cpp | 23 ++
src/gallium/state_trackers/clover/api/program.cpp | 5 +
I have found out that the llvm-3.9 installation directory in Ubuntu is
not as you said and ended up creating symlinks to it:
```
sudo ln -s /usr/include/llvm-3.9/llvm/ /usr/include/llvm
sudo ln -s /usr/include/llvm-c-3.9/llvm-c/ /usr/include/llvm-c
```
Now I seem to be getting a different error:
Hi,
Do you have LLVM development packages installed? It seems configure
can't find llvm-config and the header that can't be found is in the
standard include path, at least for archlinux (i.e.
/usr/include/llvm-c/TargetMachine.h). radv needs LLVM 3.9 development
packages or newer.
The issue Gustaw
Rb
On Sep 30, 2016 6:45 PM, "Timothy Arceri"
wrote:
> ---
> src/compiler/glsl/blob.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/compiler/glsl/blob.h b/src/compiler/glsl/blob.h
> index ec903ec..0765bf3 100644
> --- a/src/compiler/glsl/blob.h
> +++ b/src/compiler/glsl/blob.h
>
---
src/gallium/state_trackers/clover/api/kernel.cpp | 47 --
src/gallium/state_trackers/clover/core/kernel.cpp | 6 +++
src/gallium/state_trackers/clover/core/kernel.hpp | 1 +
src/gallium/state_trackers/clover/core/module.hpp | 19 +--
.../state_trackers/clover/llvm/co
Hello,
I might not be an expert, but it seems that the build system failed to
locate radeon_llvm_check function. I heard somewhere on this list that
there is currently a problem with it being used before it's defined. I
think you will need to modify configure.ac and move it from line 2323
to, e.g.
Hello,
I decided to try out the work-in-progress AMD driver with Vulkan
support: https://github.com/airlied/mesa/tree/semi-interesting
But when I try to compile the source, it fails -- see the log:
http://pastebin.com/1nCQYCEF
Is this a common problem with the official mesa3d repo aswell, or i
Am 01.10.2016 um 00:06 schrieb Marek Olšák:
On Fri, Sep 30, 2016 at 11:23 PM, Dave Airlie wrote:
On 1 October 2016 at 06:11, Marek Olšák wrote:
On Fri, Sep 30, 2016 at 4:42 PM, Ilia Mirkin wrote:
So is this getting pushed, or should I push my "don't build vdpau for
nouveau" patch?
Please w
18 matches
Mail list logo
