https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #14 from Grimdoll ---
Ok, thanks, now I installed it and:
grimdoll@grimdoll-Aspire-5740:~ > locate libtxc_dxtn.so | xargs file
/usr/lib/x86_64-linux-gnu/libtxc_dxtn.so: symbolic link to
`/etc/alternatives/libtxc-dxtn-x86_64-linux-gnu'
Reviewed-by: Matt Turner
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
On Wed, Feb 4, 2015 at 11:27 PM, Ilia Mirkin wrote:
> diff --git a/src/mesa/program/prog_parameter.c
> b/src/mesa/program/prog_parameter.c
> index 0ef4641..e1bbc00 100644
> --- a/src/mesa/program/prog_parameter.c
> +++ b/src/mesa/program/prog_parameter.c
> @@ -111,7 +111,13 @@ _mesa_add_parameter
On Wed, Feb 4, 2015 at 11:27 PM, Ilia Mirkin wrote:
> From: Dave Airlie
>
> This is a helper to return if a type is based on a double.
>
> v2: GLboolean->bool (Ian)
>
> Reviewed-by: Ian Romanick
> Signed-off-by: Dave Airlie
> ---
> src/mesa/program/prog_parameter.h | 22 ++
On Wed, Feb 4, 2015 at 11:27 PM, Ilia Mirkin wrote:
> From: Dave Airlie
>
> This just adds a placeholder for the GLSL_TYPE_DOUBLE.
>
> This causes a lot of warnings about unchecked type in
> switch statements - fix them later.
This isn't used until patch 7. Why don't you just squash it into 7?
_
On Thu, Feb 5, 2015 at 1:31 AM, Kenneth Graunke
wrote:
> On Wednesday, February 04, 2015 01:52:57 PM Carl Worth wrote:
> > From: Kristian Høgsberg
> >
> > This code provides for an on-disk cache of objects. Objects are stored
> > and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-b
On Wed, Feb 4, 2015 at 11:27 PM, Ilia Mirkin wrote:
> +void GLAPIENTRY
> +_mesa_UniformMatrix3dv(GLint location, GLsizei count, GLboolean transpose,
> + const GLdouble * value)
Sloppy whitespace. Align it with the ( on the previous line. Also *
goes with the argument name
Oh, and you can find this branch at
https://github.com/imirkin/mesa.git fp64-2
https://github.com/imirkin/mesa/commits/fp64-2
This includes the gallium, st/mesa, and nvc0 patches as well.
On Thu, Feb 5, 2015 at 2:27 AM, Ilia Mirkin wrote:
> These patches have been around for over 6 months with
From: Tapani Pälli
Patch fixes Piglit test:
arb_gpu_shader_fp64/preprocessor/fs-output-double.frag
and adds additional validation for shader outputs.
Signed-off-by: Tapani Pälli
Signed-off-by: Dave Airlie
---
src/glsl/ast_to_hir.cpp | 47 +++
1
From: Dave Airlie
v2: add define bit (Tapani Pälli)
Patch makes following Piglit tests pass:
arb_gpu_shader_fp64/preprocessor/define.vert
arb_gpu_shader_fp64/preprocessor/define.frag
Reviewed-by: Ian Romanick
Signed-off-by: Dave Airlie
---
src/glsl/glcpp/glcpp-parse.y| 3 +++
s
From: Dave Airlie
This adds the guts of the fp64 implementation to the GLSL compiler.
- builtin double types
- double constant support
- lexer parsing for double types (lf, LF)
- enforcing flat on double fs inputs
- double operations (d2f,f2d, pack/unpack, frexp - in 2 parts)
- ir builder bits.
From: Dave Airlie
We want to restrict some lowering passes to floats only,
and enable other for doubles.
Signed-off-by: Dave Airlie
---
src/glsl/lower_instructions.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_ins
From: Dave Airlie
This implements the bulk of the builtin functions for fp64 support.
Signed-off-by: Dave Airlie
---
src/glsl/builtin_functions.cpp | 751 +++--
1 file changed, 492 insertions(+), 259 deletions(-)
diff --git a/src/glsl/builtin_functions.cpp
From: Dave Airlie
This adds support for the new uniform interfaces
from ARB_gpu_shader_fp64.
v2:
support ARB_separate_shader_objects ProgramUniform*d* (Ian)
don't allow boolean uniforms to be updated (issue 15) (Ian)
v3: fix size_mul
v4: Teach uniform update to take into account double precisio
From: Dave Airlie
This lowers double dot product and lrp to fma.
Signed-off-by: Dave Airlie
---
src/glsl/lower_instructions.cpp | 83 +
1 file changed, 83 insertions(+)
diff --git a/src/glsl/lower_instructions.cpp b/src/glsl/lower_instructions.cpp
index
From: Dave Airlie
These lowering passes are optional for the backend to request, currently
the TGSI softpipe backend most likely the r600g backend would want to use
these passes as is. They aim to hit the gallium opcodes from the standard
rounding/truncation functions.
v2: also lower floor in mo
Signed-off-by: Ilia Mirkin
---
src/glsl/ir_optimization.h | 1 +
src/glsl/lower_instructions.cpp | 279 +++-
2 files changed, 279 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index 9f91e2f..7eb861a 10
These patches have been around for over 6 months with little
change. The "glsl: add double support" patch is a bit large and
includes many of Tapani and Topi's follow-on fix patches. There's
probably still bugs in there, but at this point, I think it makes
sense to push them soon to avoid bitrot.
From: Dave Airlie
This just adds the entries to extensions.c and mtypes.h
v2: use core profile only (Ian)
Signed-off-by: Dave Airlie
---
src/mesa/main/extensions.c | 1 +
src/mesa/main/mtypes.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/src/mesa/main/extensions.c b/src/mesa/mai
From: Dave Airlie
This is a helper to return if a type is based on a double.
v2: GLboolean->bool (Ian)
Reviewed-by: Ian Romanick
Signed-off-by: Dave Airlie
---
src/mesa/program/prog_parameter.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/mesa/program/prog_
From: Dave Airlie
This just adds a placeholder for the GLSL_TYPE_DOUBLE.
This causes a lot of warnings about unchecked type in
switch statements - fix them later.
Signed-off-by: Dave Airlie
---
src/glsl/glsl_types.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/glsl/glsl_types.h b/s
From: Dave Airlie
Just add the xml file covering this extension,
and dummy interface files in mesa, and fix up
sanity tests.
v2:
Enable ProgramUniform*d* from ARB_separate_shader_objects (Ian)
use 40 instead of 43 for dispatch_sanity.cpp (Chris)
uncomment PU sanity tests.
Signed-off-by: Dave Ai
On 05.02.2015 13:54, Ilia Mirkin wrote:
> On Wed, Feb 4, 2015 at 11:45 PM, Michel Dänzer wrote:
>> On 05.02.2015 12:48, Ilia Mirkin wrote:
>>> Is there a benchmark that demonstrates this? I'd like to test it out
>>> with nouveau.
>>
>> Mesa demos src/tests/streaming_rect on Kaveri (radeonsi):
>>
>
Hi;
On 02/04/2015 11:52 PM, Carl Worth wrote:
From: Kristian Høgsberg
This code provides for an on-disk cache of objects. Objects are stored
and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-byte
sequences, (intended to be SHA-1 hashes of something identifying for
the content).
On Wed, Feb 4, 2015 at 11:45 PM, Michel Dänzer wrote:
> On 05.02.2015 12:48, Ilia Mirkin wrote:
>> Is there a benchmark that demonstrates this? I'd like to test it out
>> with nouveau.
>
> Mesa demos src/tests/streaming_rect on Kaveri (radeonsi):
>
> Unpatched: 42 frames in 1.023 seconds = 41.05
On 05.02.2015 12:48, Ilia Mirkin wrote:
> Is there a benchmark that demonstrates this? I'd like to test it out
> with nouveau.
Mesa demos src/tests/streaming_rect on Kaveri (radeonsi):
Unpatched: 42 frames in 1.023 seconds = 41.056 FPS
Patched: 615 frames in 1.000 seconds = 615.000 FPS
For
On Wed, Feb 4, 2015 at 8:08 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> These act like flt32 except they take up two slots, and you
> can only add 2 x flt64 constants in one slot.
>
> The main reason they are different is we don't want to match half a flt64
> constants against a flt32 constant
total instructions in shared programs: 5764176 -> 5763808 (-0.01%)
instructions in affected programs: 25121 -> 24753 (-1.46%)
helped:164
HURT: 2
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 26 ++
1 file cha
This doesn't seem to be necessary.
---
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 8cd36f8..2820b8d 100644
--- a/src/mesa/drivers/dri/i965/br
Since .stride is 0 for a scalar write, we calculated regs_written = 0
for a mov(1) instruction. Instruction scheduling loops from 0 to
regs_written when calculating dependencies, so this would cause
problems.
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deleti
total instructions in shared programs: 5885407 -> 5940958 (0.94%)
instructions in affected programs: 3617311 -> 3672862 (1.54%)
helped:3
HURT: 23556
GAINED:31
LOST:
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 10 ++
src/mesa/drivers/dri/i965/brw_cfg.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 2d6a181..095c34f 100644
--- a/src/mesa/drivers/dri/i965/brw_
And then the opt_combine_constants() pass will pull them out into
registers. This will allow us to do some algebraic optimizations on MAD
and LRP.
total instructions in shared programs: 5946656 -> 5931320 (-0.26%)
instructions in affected programs: 778247 -> 762911 (-1.97%)
helped:
Previously we didn't emit MAD instructions since they cannot take
immediate arguments, but with the opt_combine_constants() pass we can
handle this properly.
total instructions in shared programs: 5920017 -> 5733278 (-3.15%)
instructions in affected programs: 3625153 -> 3438414 (-5.15%)
helped
total instructions in shared programs: 5895414 -> 5747578 (-2.51%)
instructions in affected programs: 3618111 -> 3470275 (-4.09%)
helped:20492
HURT: 4449
GAINED:54
LOST:
The fs_visitor's dump_instruction() implementation calls cfg_t()
indirectly through calculate_live_intervals, so if you have an infinite
loop in the CFG code, you can't call cfg::dump(fs_visitor *) to debug
it.
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 3 ++-
1 file changed, 2 insertions(+), 1 d
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 14 ++
src/mesa/drivers/dri/i965/brw_cfg.h | 1 +
2 files changed, 15 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_cfg.cpp
b/src/mesa/drivers/dri/i965/brw_cfg.cpp
index 068d4d6..2d6a181 100644
--- a/src/mesa/drivers/dri/i965/
---
src/mesa/drivers/dri/i965/brw_cfg.cpp | 68 +-
src/mesa/drivers/dri/i965/brw_cfg.h| 7 ++-
.../drivers/dri/i965/brw_dead_control_flow.cpp | 5 +-
3 files changed, 75 insertions(+), 5 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw
Is there a benchmark that demonstrates this? I'd like to test it out
with nouveau.
On Wed, Feb 4, 2015 at 10:47 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> The latter currently implies CPU access, so we have to avoid getting
> uncacheable memory.
>
> Bugzilla: https://bugs.freedesktop.org
From: Michel Dänzer
The latter currently implies CPU access, so we have to avoid getting
uncacheable memory.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88658
Cc: "10.3 10.4"
Signed-off-by: Michel Dänzer
---
src/mesa/state_tracker/st_cb_bufferobjects.c | 11 +--
1 file chan
On Mon, Feb 02, 2015 at 11:37:26PM -0500, Ilia Mirkin wrote:
> On Mon, Dec 8, 2014 at 9:50 PM, Ben Widawsky wrote:
> > Thanks. All the requests look good, and I'll post it in v3.
>
> What happened to this patch? It was pretty close... should be easy to
> add gallium support for it too once it's i
Previously, the hash_table_insert function would bail early if it found a
deleted slot that it could re-use. However, this is a problem if the key
being inserted is already in the hash table but further down the list. If
this happens, the element ends up getting inserted in the hash table twice.
Previously, the set_insert function would bail early if it found a deleted
slot that it could re-use. However, this is a problem if the key being
inserted is already in the set but further down the list. If this happens,
the element ends up getting inserted in the set twice. This commit makes
it
---
src/util/tests/hash_table/collision.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/src/util/tests/hash_table/collision.c
b/src/util/tests/hash_table/collision.c
index b76782b..a2210c3 100644
--- a/src/util/tests/hash_table/collision.c
+++ b/src/util/tests
On Wed, Feb 4, 2015 at 6:04 PM, Carl Worth wrote:
> On Wed, Feb 04 2015, Matt Turner wrote:
>> Rebase needed. I removed GLSL_SRCDIR a week and a half ago.
>
> Was this the removal of all those subdir-objects warnings? Thank you!
Yes! Just one warning remaining :).
>> I don't think it makes a dif
In the past I think we usually mentioned the date version (20150202) in
the commit msg. But not a big deal.
Reviewed-by: Brian Paul
On 02/04/2015 05:47 PM, Laura Ekstrand wrote:
Khronos modified glext.h to get rid of GL_TEXTURE_BINDING, a special enum
added for ARB_direct_state_access. This
On Wed, Feb 04 2015, Matt Turner wrote:
> Rebase needed. I removed GLSL_SRCDIR a week and a half ago.
Was this the removal of all those subdir-objects warnings? Thank you!
> I don't think it makes a difference to autotools, but I think I'd list
> cache.h here instead of in LIBGLSL_FILES.
Actuall
On Wed, Feb 04 2015, Matt Turner wrote:
> Is there some reason we should do this as a separate patch instead of
> just squashing it?
Not really. I've just squashed it, (while also fixing the space before
the parenthesis---I should probably add a pre-commit check for those to
help me break that hab
On Wed, Feb 4, 2015 at 8:08 PM, Dave Airlie wrote:
> This patch adds support for a set of double opcodes
> to TGSI. It is an update of work done originally
> by Michal Krol on the gallium-double-opcodes branch.
>
> The opcodes have a hint where they came from in the
> header file.
>
> v2: add unsi
On Wed, Jan 14, 2015 at 5:11 PM, Matt Turner wrote:
> On Wed, Jan 14, 2015 at 8:54 AM, Kenneth Graunke
> wrote:
>> In the common case, this is redundant - we set it a few lines later.
>>
>> However, when irb->mt->fast_clear_state == INTEL_FAST_CLEAR_STATE_CLEAR,
>> this causes irb->need_downsamp
Signed-off-by: Dave Airlie
---
src/gallium/auxiliary/tgsi/tgsi_exec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_exec.h
b/src/gallium/auxiliary/tgsi/tgsi_exec.h
index cc5a916..256cf72 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_exec.h
+++
This patch adds support for a set of double opcodes
to TGSI. It is an update of work done originally
by Michal Krol on the gallium-double-opcodes branch.
The opcodes have a hint where they came from in the
header file.
v2: add unsigned/int <-> double
v2.1: update docs.
v3: add DRSQ (Glenn), fix
From: Dave Airlie
These act like flt32 except they take up two slots, and you
can only add 2 x flt64 constants in one slot.
The main reason they are different is we don't want to match half a flt64
constants against a flt32 constant in the matching code, we need to make
sure we treat both parts
These 3 patches are similiar to the last repost, and I'd like
to merge them to get the ball rolling.
The main change is adding DRSQ to this list, Ilia has some other
patches to add the rounding ones, but I'd like to get things started
with this set and work forwards.
Dave.
__
On 30 December 2014 at 08:14, Roland Scheidegger wrote:
> Just minor nits, looks good to me otherwise.
> I agree with others that probably the round family of functions should
> be added too (but could be done in another patch). Maybe could have one
> cap bit then (so some implementations only doi
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #13 from Michel Dänzer ---
What does this say:
locate libtxc_dxtn.so | xargs file
Or, you can just try
sudo apt-get install libtxc-dxtn0:i386
which should either install the 32-bit version of the library or tell you that
it's alre
Khronos modified glext.h to get rid of GL_TEXTURE_BINDING, a special enum
added for ARB_direct_state_access. This enum was ruled unimplementable.
---
include/GL/glext.h | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index
On Wed, Feb 4, 2015 at 1:52 PM, Carl Worth wrote:
> - snprintf(cache->path, sizeof cache->path,
> -"%s/.cache/mesa", pwd.pw_dir);
> + cache->path = strdup(path);
> + if (cache->path == NULL) {
> + free (cache);
No space after the function name.
> + cache = NULL;
> +
On Wed, Feb 4, 2015 at 1:53 PM, Carl Worth wrote:
> The user can put the cache directory anywhere, so it's not safe to use
> fixed-size arrays to store filenames. Instead, allocate the cache
> pointer itself as a ralloc context and use that to dynamically
> allocate all filenames.
>
> While making
On Wed, Feb 04 2015, Kenneth Graunke wrote:
> The cache will need to be much larger than 1024 entries - perhaps by an
> order of magnitude.
Thanks for the feedback. I had meant to add a comment next to that 1024
in the code along the lines of "This value was chosen arbitrarily. An
appropriate valu
On Wed, Feb 4, 2015 at 1:52 PM, Carl Worth wrote:
> From: Kristian Høgsberg
>
> This code provides for an on-disk cache of objects. Objects are stored
> and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-byte
> sequences, (intended to be SHA-1 hashes of something identifying for
> t
On Wednesday, February 04, 2015 01:52:57 PM Carl Worth wrote:
> From: Kristian Høgsberg
>
> This code provides for an on-disk cache of objects. Objects are stored
> and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-byte
> sequences, (intended to be SHA-1 hashes of something identif
https://bugs.freedesktop.org/show_bug.cgi?id=88962
--- Comment #5 from Park, Jeongmin ---
Sorry about the first patch. I didn't see that.
In dri_sw.c, it checks for z/s buffer:
> if (ctx->pp && drawable->textures[ST_ATTACHMENT_DEPTH_STENCIL])
> pp_run(ctx->pp, ptex, ptex,
> drawabl
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #12 from Grimdoll ---
-
grimdoll@grimdoll-Aspire-5740:~ > whereis libtxc_dxtn.so
libtxc_dxtn:
-
I dont understand, what w
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #11 from Benjamin Bellec ---
I should have ask you this instead :
$ whereis libtxc_dxtn.so
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #10 from Grimdoll ---
"ERROR: cannot open `/usr/lib/libtxc_dxtn.so' (No such file or directory)" for
all of those commands
grimdoll@grimdoll-Aspire-5740:~ > glxinfo |grep "OpenGL core profile version
strin
This patch adds support for a new variable, MESA_GLSL_CACHE_DISABLE.
If this variable is set, then all use of the shader cache will be
disabled at run time.
---
docs/envvars.html | 1 +
src/glsl/cache.c | 4
2 files changed, 5 insertions(+)
diff --git a/docs/envvars.html b/docs/envvars.html
If Mesa is being compiled with no shader cache, (whether due to
explicit user request or due to a missing library dependency), then we
want to incur no cost on the implementation. To achieve this with as
little fuss as possible, (that is, without sprinkling #ifdef
throughout every call into cache f
This API forms the base infrastructure for the future shader cache. At
this point, the cache is simply a persistent, on-disk store of objects
stored and retrieved by 20-byte keys.
---
src/glsl/cache.h | 121 +++
1 file changed, 121 insertions(+)
Hi folks,
This series adds a layer of code to store a cache of objects on
disk. Thanks to Kristian Høgsberg for the initial proof-of-concept
implementation here. I've take his original code and added my own
cleanups and documentation to the cache API. I've also fixed up a
couple of the items he ha
From: Kristian Høgsberg
This code provides for an on-disk cache of objects. Objects are stored
and retrieved (in ~/.cache/mesa) via names that are arbitrary 20-byte
sequences, (intended to be SHA-1 hashes of something identifying for
the content).
The cache is limited to a maximum number of entr
The user can put the cache directory anywhere, so it's not safe to use
fixed-size arrays to store filenames. Instead, allocate the cache
pointer itself as a ralloc context and use that to dynamically
allocate all filenames.
While making this change, simplify the error handling in cache_get
with a
With this patch, there are now three different options for the shader
cache directory, (considered in order until the first variable is
set):
$MESA_GLSL_CACHE_DIR
$XDG_CACHE_HOME/mesa
/.cache/mesa
Also with this patch, once the desired path is determined, the
directory is
Instead of writing directly to the desired , with this patch
we instead first write to .tmp and then use rename() to
atomically rename from .tmp to . This ensures that
any process that opens for reading will never see any
partially written file.
---
src/glsl/cache.c | 41 +
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #9 from Benjamin Bellec ---
OK.
Could you tell us what reports these commands :
$ file /usr/lib32/libtxc_dxtn.so
$ file /usr/lib/libtxc_dxtn.so
$ file /usr/local/lib32/libtxc_dxtn.so
$ file /usr/local/lib/libtxc_dxtn.so
And also :
$
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #8 from Grimdoll ---
To be honest, I do not know. I try so many guides to install xorg drivers, to
install proprietary drivers. May be it was installed during installation of
Linux Mint.
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=88967
Benjamin Bellec changed:
What|Removed |Added
CC||b.bel...@gmail.com
--- Comment #7 from
---
src/gallium/auxiliary/hud/hud_context.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/auxiliary/hud/hud_context.c
b/src/gallium/auxiliary/hud/hud_context.c
index 98678fc..e46c68c 100644
--- a/src/gallium/auxiliary/hud/hud_context.c
+++ b/src/gallium/auxiliary/hud/hud_context
Convert the code to try formats from an array rather than a bunch
of if/else cases.
---
src/gallium/auxiliary/hud/font.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/gallium/auxiliary/hud/font.c b/src/gallium/auxiliary/hud/font.c
index 03e35d9..
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #6 from Grimdoll ---
I would like to show what's happening in console while I'm running Star
Conflict, but this game runs through steam, and don't show any usefull info in
console, just only about steam.
--
You are receiving this ma
On 04/02/15 20:18, Kenneth Graunke wrote:
On Wednesday, February 04, 2015 02:04:38 PM Jose Fonseca wrote:
This change broke MinGW/MSVC builds because ffsll is not available there.
There is a ffsll C fallback, but it's in src/mesa/main/imports.[ch]. So
rather than duplicating it in src/gallium
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #5 from Grimdoll ---
How to check version of libtxc-dxtn-s2tc0 ?
--
grimdoll@grimdoll-Aspire-5740:~ > glxinfo |grep
"GL_EXT_texture_compression_s3tc"
GL_EXT_texture_compression_rgtc, GL_
On Wed, Feb 4, 2015 at 12:22 PM, Kenneth Graunke wrote:
> On Friday, January 30, 2015 03:54:28 PM Matt Turner wrote:
>> ---
>> src/mesa/drivers/dri/i965/brw_shader.cpp | 5 +
>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>
>> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
>> b/sr
On Friday, January 30, 2015 03:54:28 PM Matt Turner wrote:
> ---
> src/mesa/drivers/dri/i965/brw_shader.cpp | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
> b/src/mesa/drivers/dri/i965/brw_shader.cpp
> index 678390e..c393bfc
On Wednesday, February 04, 2015 02:04:38 PM Jose Fonseca wrote:
> This change broke MinGW/MSVC builds because ffsll is not available there.
>
>
> There is a ffsll C fallback, but it's in src/mesa/main/imports.[ch]. So
> rather than duplicating it in src/gallium/auxiliary/util/u_math.h I'd
> pr
---
I don't know if this is right, but what we had before was definitely
wrong. (And gcc warned about it!)
src/glsl/nir/nir_lower_phis_to_scalar.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/glsl/nir/nir_lower_phis_to_scalar.c
b/src/glsl/nir/nir_lower_phis_to_sc
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #4 from Benjamin Bellec ---
I guess X3TC is a 32-bit game. Do you have the libtxc-dxtn-s2tc0 32-bit
version, and not only the 64-bit one ?
Also, what give this command:
$ glxinfo |grep "GL_EXT_texture_compression_s3tc"
--
You are r
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #3 from Grimdoll ---
When I launching X3TC game through console, after appearing of game menu, in
console I just see something like "can not to load texture, using dummy... can
not load dummy..." and this message repeating infinitely.
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #2 from Grimdoll ---
My system already have latest libtxc-dxtn-s2tc0
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
___
mesa-
On Wed, Feb 4, 2015 at 2:18 AM, Francisco Jerez wrote:
> Matt Turner writes:
>
>> Prevents piglit regressions from the next patch.
>> ---
>> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 37
>> +-
>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>
>> diff --git a/s
https://bugs.freedesktop.org/show_bug.cgi?id=88967
--- Comment #1 from Sven Arvidsson ---
Sounds like you might need to install libtxc-dxtn0 for S3TC support.
See http://dri.freedesktop.org/wiki/S3TC/
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=88962
--- Comment #4 from Brian Paul ---
The first patch looks good. I posted something similar to mesa-dev yesterday.
But the second patch doesn't seem right. There could be post-process stages
that don't care about the depth/stencil buffer but we'
On 02/04/2015 07:04 AM, Jose Fonseca wrote:
This change broke MinGW/MSVC builds because ffsll is not available there.
There is a ffsll C fallback, but it's in src/mesa/main/imports.[ch]. So
rather than duplicating it in src/gallium/auxiliary/util/u_math.h I'd
prefer move it to src/util.
And
https://bugs.freedesktop.org/show_bug.cgi?id=88967
Bug ID: 88967
Summary: Black textures Radeon m HD 5650
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: n
Hello list,
A candidate for the Mesa 10.4.4 release is now available. The current
patch queue is as follows:
- 7 queued
- 4 nominated (outstanding)
- and 1 rejected (obsolete) patches
In a nut shell this gives us a couple of build fixes, brings back one of
Mario's dri3 patches, addresses osmes
https://bugs.freedesktop.org/show_bug.cgi?id=88962
--- Comment #3 from Alex Deucher ---
Please send the patches to the mesa-dev mailing list if you haven't already.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
This change broke MinGW/MSVC builds because ffsll is not available there.
There is a ffsll C fallback, but it's in src/mesa/main/imports.[ch]. So
rather than duplicating it in src/gallium/auxiliary/util/u_math.h I'd
prefer move it to src/util.
And here lies the problem: what header name sh
Hi Marius,
This patch does indeed make the Piglit test pass but it doesn't seem
like a complete fix. It looks like there are still a number of places
that are copying via floats that the test wouldn't catch. There are also
lots of places that are still using GLfloat to store the attribute
values a
Matt Turner writes:
> Prevents piglit regressions from the next patch.
> ---
> src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 37
> +-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
> b/src/mesa/driver
https://bugs.freedesktop.org/show_bug.cgi?id=79629
--- Comment #17 from Chris Wilson ---
(In reply to Eero Tamminen from comment #14)
> (In reply to XiongZhang from comment #13)
> > Yes, I test with DRI3. When I compile xf86-video-intel and mesa, I add
> > --enable-dri3 option.
> > Without the pr
1 - 100 of 105 matches
Mail list logo
