On Thu, Jan 26, 2017 at 01:50:42PM +1100, Timothy Arceri wrote:
> jip should always be negative here as its the result of
> do instruction - while instruction.
> ---
> src/mesa/drivers/dri/i965/brw_eu_emit.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_eu
On Thu, Jan 26, 2017 at 01:50:41PM +1100, Timothy Arceri wrote:
> We are casting from a signed 32bit int to an unsigned 16bit int
> so shift 15 bits rather than 16.
> ---
> src/mesa/drivers/dri/i965/brw_inst.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/d
Reviewed-by: Roland Scheidegger
Am 28.01.2017 um 23:08 schrieb Bas Nieuwenhuizen:
> Since LLVM revision 293359 DumpModule gets only implemented when
> either a debug build or LLVM_ENABLE_DUMP is set.
>
> This patch adds a direct replacement for the function for radv and
> radeonsi, However, as I
Since LLVM revision 293359 DumpModule gets only implemented when
either a debug build or LLVM_ENABLE_DUMP is set.
This patch adds a direct replacement for the function for radv and
radeonsi, However, as I don't know a good place to put common LLVM
code for all three I inlined the implementation fo
You're right. Saw that it wasn't in 3.3 and just kept using the
DumpModule in the versions where it was possible to avoid unforeseen
regressions in old LLVM versions . You're right about radeonsi+radv only
supporting 3.6+, and as it is availabe from 3.4 that saves having both
variants. I'll change
Maybe should use the new version for older llvm versions too? I think it
would work back to around llvm 3.4 or 3.5. Meaning you don't need a
ifdef for the radeon drivers.
Or ist there any disadvantage of this versus the older method?
Roland
Am 28.01.2017 um 17:40 schrieb Bas Nieuwenhuizen:
> Sinc
Am Samstag, 28. Januar 2017, 16:09:29 CET schrieb Marek Olšák:
> On Sat, Jan 28, 2017 at 3:31 PM, Ilia Mirkin wrote:
> > Can you explain why it's a desirable goal to be able to build radv without
> > --enable-gallium-llvm? Perhaps it's obvious, but I'm not seeing it.
> >
> > On Jan 28, 2017 8:57
This is what was allowed from the beginning, this just unbreaks the build.
I had a different solution for this, but this was shut down by Jose.
See:
https://lists.freedesktop.org/archives/mesa-dev/2017-January/141263.html
and
https://bugs.freedesktop.org/show_bug.cgi?id=99010
Am Samstag, 28. Ja
On 17-01-25 21:05:15, Topi Pohjolainen Topi Pohjolainen wrote:
On Wed, Jan 25, 2017 at 09:01:56PM +0200, Pohjolainen, Topi wrote:
On Mon, Jan 23, 2017 at 10:21:40PM -0800, Ben Widawsky wrote:
> Previously our aux buffers (MCS, and HiZ) never had an offset because
> they were in their own buffer
https://bugs.freedesktop.org/show_bug.cgi?id=93760
--- Comment #8 from Nayan Deshmukh ---
(In reply to Christian König from comment #7)
> Take a look at vlVaHandleSliceParameterBufferMPEG12 and the assert.
>
> We probably just need to handle the case of multiple buffers here and in
> handleVASli
Since LLVM revision 293359 DumpModule gets only implemented when
either a debug build or LLVM_ENABLE_DUMP is set.
This patch adds a direct replacement for the function for radv and
radeonsi, However, as I don't know a good place to put common LLVM
code for all three I inlined the implementation fo
Am 27.01.2017 um 20:44 schrieb Mark Thompson:
On 27/01/17 14:27, Christian König wrote:
Am 27.01.2017 um 13:51 schrieb Mark Thompson:
On 26/01/17 16:59, Christian König wrote:
[SNIP]
(For that matter, is there a list somewhere of the set of formats/layouts and
what they are used for?)
Well ta
On Sat, Jan 28, 2017 at 3:31 PM, Ilia Mirkin wrote:
> Can you explain why it's a desirable goal to be able to build radv without
> --enable-gallium-llvm? Perhaps it's obvious, but I'm not seeing it.
>
> On Jan 28, 2017 8:57 AM, "Tobias Droste" wrote:
>
> This is a reworked series of the previous
Can you explain why it's a desirable goal to be able to build radv without
--enable-gallium-llvm? Perhaps it's obvious, but I'm not seeing it.
On Jan 28, 2017 8:57 AM, "Tobias Droste" wrote:
This is a reworked series of the previous LLVM related changes to
configure.ac that were reverted due to
Only define HAVE_LLVM if --enable-gallium-llvm is provided.
If radv is built add HAVE_LLVM_RADV define with the same value
as HAVE_LLVM.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99010
Signed-off-by: Tobias Droste
---
configure.ac | 3 ++-
src/amd/common/ac_ll
Ignore that, wrong version...
Am Samstag, 28. Januar 2017, 14:56:59 CET schrieb Tobias Droste:
> Only define HAVE_LLVM if --enable-gallium-llvm is provided.
> If radv is built add HAVE_LLVM_RADV define with the same value
> as HAVE_LLVM.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=
Only define HAVE_LLVM if --enable-gallium-llvm is provided.
If radv is built add HAVE_LLVM_RADV define with the same value
as HAVE_LLVM.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99010
Signed-off-by: Tobias Droste
---
configure.ac | 3 ++-
src/amd/common/ac_ll
This is actually not needed because the version is checked later.
Line 2403:
if test "x$enable_gallium_llvm" == "xyes"; then
llvm_require_version $LLVM_REQUIRED_GALLIUM "gallium"
llvm_add_default_components "gallium"
USE_LLVM_GALLIUM=yes
DEFINES="${DEFINES} -DHAVE_LLVM=0x0$LLVM_VE
This renames llvm_check_version_for to llvm_require_version and let it
set a variable to mark that LLVM will be used.
Use this to make a usefull configure output and to only check if the
libs are found in LLVM if it is actually used.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99010
S
This is a reworked series of the previous LLVM related changes to
configure.ac that were reverted due to breaking scons.
This takes a different approach to the previous series and adds an
extra define for LLVM version checks if RADV is build.
This allows to build RADV with "--disable-gallium-llv
This renames MESA_LLVM to FOUND_LLVM and updates the config.log report
to say if LLVM is found or not, to make clear that this does not mean
that it is used.
There are no MESA_LLVM users so drop the AC_SUBST.
v2 [Emil]
- Polish test: -a over && test, = over ==, unquiote xyes
- other ?
Signed-o
21 matches
Mail list logo