Hi,
I built mesa 9.1 with following configuration:
--enable-xlib-glx --disable-dri --with-gallium-drivers=swrast
--enable-osmesa --with-osmesa-bits=32
The mesa package is used by TurboVNC, so xlib glx has to be used
instead of DRI. It works well to gain faster speed in glxgears, but it
has huge
When forcing the compiler to always generate pull constants instead of
push constants (in order to have an easy to use testcase), improves
performance of my old GLSL demo 23.3553% +/- 1.42968% (n=7).
---
src/mesa/drivers/dri/i965/brw_defines.h |2 +-
src/mesa/drivers/dri/i965/brw_fs.cpp
We were handling the the dependency workaround for the first written reg
of a send preceding the one we're fixing up, but didn't consider the other
regs. Thus if you had two sampler calls that got allocated to the same
set of regs, one might, rarely, ovewrite the other. This was occurring in
XBMC
The lowering process creates a new vgrf on gen7 that should be represented
in live interval analysis. As-is, it was getting a conflicting allocation
with gl_FragDepth in the dolphin emulator, producing broken rendering.
NOTE: This is a candidate for the 9.1 branch.
Bugzilla: https://bugs.freedesk
We were allowing a compressed instruction to write a register that
contained the last use of a uniform pull constant (either UBO load or push
constant spillover), so it would get half its values smashed.
Since we need to see the actual instruction to decide this, move the
pre-gen6 pixel_x/y logic
I was going to fix the code above like the previous commit, but we already
had that covered (otherwise all our uniform access would have been broken,
unlike just pull constants).
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp |4
1 file changed, 4 insertions(+)
diff --git a/src/me
I was looking at the list to see what might be interesting to document for
application developers, and it turns out some are completely dead.
---
src/mesa/drivers/dri/intel/intel_context.c |4
src/mesa/drivers/dri/intel/intel_context.h |4
2 files changed, 8 deletions(-)
diff --
https://bugs.freedesktop.org/show_bug.cgi?id=61933
Priority: medium
Bug ID: 61933
Assignee: mesa-dev@lists.freedesktop.org
Summary: Weston EGL clients hang with software rendering upon
startup
Severity: normal
Classificat
On Wed, Mar 6, 2013 at 5:39 PM, Maxence Le Doré
wrote:
> While I was trying to understand how cpu features detection works, I noticed
> that every was coherent except for the TSC ( Time Stamp Counter). I found
> many pages on the net that suggest that the right value for the
> corresponding shift
While I was trying to understand how cpu features detection works, I
noticed that every was coherent except for the TSC ( Time Stamp
Counter). I found many pages on the net that suggest that the right
value for the corresponding shift would be 4 and not 8. Even the
commented bitfields that repr
On 03/06/2013 11:46 AM, Alan Hourihane wrote:
On 03/06/13 18:36, Brian Paul wrote:
On 03/06/2013 11:23 AM, Alan Hourihane wrote:
If the sampler object has been deleted on another context, an
alternative context may reference the old sampler. So ensure the
sampler
object still exists.
Alan, is
It fails on 32-bit systems (I only tested on 64-bit). Power of two
size isn't required, so just remove the assertion.
---
src/gallium/drivers/llvmpipe/lp_scene.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_scene.c
b/src/gallium/d
https://bugs.freedesktop.org/show_bug.cgi?id=61907
--- Comment #2 from Brian Paul ---
Just a quick note- it would be great to have a piglit test that exercises this
issue (if there isn't one already).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=61907
--- Comment #1 from Colin McDonald ---
I've realised that I was so focused on describing my code changes that
I omitted to adequately describe the problem symptoms, other than to say
that multi-texturing is "broken".
OpenSceneGraph makes extens
https://bugs.freedesktop.org/show_bug.cgi?id=61919
Priority: medium
Bug ID: 61919
Assignee: mesa-dev@lists.freedesktop.org
Summary: make fails without C_INCLUDE_PATH:
xlib_sw_winsys.c:49:33: fatal error:
X11/extensi
On Tue, Mar 05, 2013 at 07:51:02PM +0100, Tom Stellard wrote:
> On Tue, Mar 05, 2013 at 03:27:19PM +0100, Christian König wrote:
> > From: Christian König
> >
> > Signed-off-by: Christian König
>
> This series has my r-b, but I'd like to test it on r600,
> before you push it.
>
Hi Christian,
> - The patch doesn't compile cleanly on master. In particular, it looks
> like it was made using a version of the code prior to commit 42a29d8 (glsl:
> Eliminate ambiguity between function ins/outs and shader ins/outs).
Whoops, indeed. I made in my own modified Mesa fork (GLSL Optimizer,
https:/
https://bugs.freedesktop.org/show_bug.cgi?id=58812
Matt Turner changed:
What|Removed |Added
Status|NEEDINFO|REOPENED
--- Comment #3 from Matt Turner
This fixes a crash when a display list is created in one context
but executed from a second one. The vbo_save_context::vertex_store
memeber will be NULL if we never created a display list with the
context. Just check for that before dereferencing the pointer.
Fixes http://bugzilla.redhat.com/sho
On 03/06/13 18:36, Brian Paul wrote:
On 03/06/2013 11:23 AM, Alan Hourihane wrote:
If the sampler object has been deleted on another context, an
alternative context may reference the old sampler. So ensure the sampler
object still exists.
Alan, is this specified somewhere in a spec? I can't f
Hi,
I do not know if it's the right place for this, but I sent an email to the
Mesa-users mailing list explaining the problem, and I have no answers, so
if anyone can help, this is what happens:
I'm using Mesa 9.1, EGL and xcb, to make texture from pixmap.
Using EGL_KHR_image_pixmap, i get error
If the sampler object has been deleted on another context, an
alternative context may reference the old sampler. So ensure the sampler
object still exists.
Signed-off-by: Alan Hourihane
---
src/mesa/main/get.c| 12 +++-
src/mesa/main/samplerobj.c |2 +-
src/mesa/main/sampl
On 03/06/2013 11:23 AM, Alan Hourihane wrote:
If the sampler object has been deleted on another context, an
alternative context may reference the old sampler. So ensure the sampler
object still exists.
Alan, is this specified somewhere in a spec? I can't find a
description of this behaviour a
On 3 March 2013 00:44, Aras Pranckevicius wrote:
> >> opt_constant_variable was marking a variable as constant as long as
> there was
> >> exactly one constant assignment to it, but did not take into account
> that this
> >> assignment might be in a dynamic branch or a loop.
> >> Was happening on
Looks good. Thanks for fine tuning these parameters!
Jose
- Original Message -
> We advertise a max texture/surfaces size of 8K x 8K but the old values
> for these limits didn't actually allow us to handle that surface size.
>
> For 8K x 8K we'll have 16384 bins. Each bin needs at least
On 03/06/2013 09:15 AM, Alan Hourihane wrote:
> This change specifically unbinds a sampler object from the texture unit
> if it's bound to a unit. The spec calls for default object when
deleting
> sampler objects which are currently bound.
Candidate for the stable branches, I think.
>
> Sign
This change specifically unbinds a sampler object from the texture unit
if it's bound to a unit. The spec calls for default object when deleting
sampler objects which are currently bound.
Signed-off-by: Alan Hourihane
---
src/mesa/main/samplerobj.c | 10 ++
1 files changed, 10 inserti
On 03/06/2013 01:54 AM, Michel Dänzer wrote:
> Actually, you asked for two different software renderers:
> --with-dri-drivers=swrast produces lib/swrast_dri.so based on classic
> swrast, --with-gallium-drivers=swrast produces lib/gallium/swrast_dri.so
> based on llvmpipe/softpipe.
>
> Presumably
Am 06.03.2013 02:09, schrieb Brian Paul:
> Use 0 instead.
> ---
> src/gallium/drivers/llvmpipe/lp_setup.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_setup.c
> b/src/gallium/drivers/llvmpipe/lp_setup.c
> index 4529775..299fd6
https://bugs.freedesktop.org/show_bug.cgi?id=61907
Priority: medium
Bug ID: 61907
Assignee: mesa-dev@lists.freedesktop.org
Summary: Indirect rendering of multi-texture vertex arrays
broken
Severity: normal
Classification:
On Saturday 02 March 2013, Ian Romanick wrote:
> GLX_RENDERER_OPENGL_CORE_PROFILE_VERSION_MESA
>2 Maximum core profile
> major and
>minor version supported
> by the
>
On Mit, 2013-03-06 at 11:56 +0100, Christian König wrote:
> Am 05.03.2013 18:32, schrieb Vincent Lejeune:
> > LICM stands for Loop Invariant Code Motion.
> > Instructions that does not depend of loop index are moved outside of loop
> > body.
> > (This solves one of llvm generated code Vadim point
Am 05.03.2013 18:32, schrieb Vincent Lejeune:
LICM stands for Loop Invariant Code Motion.
Instructions that does not depend of loop index are moved outside of loop body.
(This solves one of llvm generated code Vadim pointed in another thread)
DCE is DeadCodeElimination...I don't know the differe
Am 05.03.2013 18:18, schrieb Michel Dänzer:
On Die, 2013-03-05 at 15:27 +0100, Christian König wrote:
From: Christian König
Signed-off-by: Christian König
---
src/gallium/drivers/radeonsi/radeonsi_shader.c | 31 +---
1 file changed, 12 insertions(+), 19 deletions(-)
On 5 March 2013 19:57, Matt Turner wrote:
> Commit 67ef7559 added an || test "x$enable_dri" check, which was just
> wrong since the whole block was enclosed in if test "x$enable_dri". The
> comment added with it stated the actual intent: to enable when any DRI
> drivers were built.
> ---
> config
35 matches
Mail list logo
