https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #16 from Phil Armstrong ---
So, running the Xserver as usual (ie, unchanged from stock install) & running
FTL linked against the old libstdc++ but with LIBGL_ALWAYS_INDIRECT=y causes
the Xserver to crash as before.
I'm fairly sure th
Lets the code compile on non Linux systems.
Signed-off-by: Jonathan Gray
---
src/gallium/drivers/r300/r300_chipset.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git src/gallium/drivers/r300/r300_chipset.c
src/gallium/drivers/r300/r300_chipset.c
index 11061ed..30e085a 100
On Wed, Jun 26, 2013 at 6:46 AM, Jean-Sébastien Pédron
wrote:
> On 26.06.2013 15:35, Jonathan Gray wrote:
>> On Wed, Jun 26, 2013 at 02:54:34PM +0200, Jean-Sébastien Pédron wrote:
>>> Hello,
>>>
>>> On FreeBSD, the x86-64 arch is named "amd64". This patch fixes its
>>> detection in the configure s
On Thu, Jun 20, 2013 at 3:14 AM, Jonathan Gray wrote:
> Use grep -w instead of the empty string escape sequences
> which are less portable. Makes the grep tests
> function as intended on OpenBSD.
>
> Signed-off-by: Jonathan Gray
> ---
> configure.ac | 6 +++---
> 1 file changed, 3 insertions(+)
(Expanded CC list.)
A little bit of back story is in order here.
When I added support to Mesa for GL_ARB_famebuffer_object, I made a
mistake. Almost all of the functions between the ARB and the EXT share
the same GLX protocol because the functionality is, essentially,
identical. However, th
Looks good to me.
- Original Message -
> From: Roland Scheidegger
>
> We were fixing up the blend factor to ZERO, however this only works correctly
> with fixed point render buffers where the input values are clamped to 0/1
> (because src_alpha_saturate is min(As, 1-Ad) so can be negativ
I'm not entirely sure if this one is right, but a change along these
lines is required to build on systems with X11 outside of the system
path in say /usr/X11R6 like on OpenBSD.
On Thu, Jul 18, 2013 at 02:57:14PM +1000, Jonathan Gray wrote:
> Signed-off-by: Jonathan Gray
> ---
> src/egl/drivers/
Signed-off-by: Jonathan Gray
---
src/egl/drivers/glx/Makefile.am| 2 +-
src/gallium/winsys/sw/xlib/Makefile.am | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git src/egl/drivers/glx/Makefile.am src/egl/drivers/glx/Makefile.am
index 6bf67ea..220134d 100644
--- src/egl/dri
Hey Mesa + qemu lists,
since I suppose these communities would be most interested in this and
might not all read my blog or G+ stream,
"Virgil is a research project I've been working on at Red Hat for a
few months now and I think is ready for at least announcing upstream
and seeing if there is an
Signed-off-by: Jonathan Gray
---
src/gallium/drivers/radeonsi/Makefile.am | 3 ++-
src/gallium/winsys/radeon/drm/radeon_winsys.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git src/gallium/drivers/radeonsi/Makefile.am
src/gallium/drivers/radeonsi/Makefile.am
index 46aa9
On Wed, Jul 17, 2013 at 09:26:34PM -0700, Vinson Lee wrote:
> On Wed, Jun 26, 2013 at 12:11 AM, Jonathan Gray wrote:
> > Signed-off-by: Jonathan Gray
> > ---
> > configure.ac | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git configure.ac configure.ac
> > index 68
On Wed, Jun 26, 2013 at 12:11 AM, Jonathan Gray wrote:
> Signed-off-by: Jonathan Gray
> ---
> configure.ac | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git configure.ac configure.ac
> index 6832b0d..6a817d0 100644
> --- configure.ac
> +++ configure.ac
> @@ -449,7 +449
Mesa 9.1.5 has been released. Mesa 9.1.5 is a bug fix release which
fixes bugs fixed since the 9.1.4 release.
The tag in the GIT repository for Mesa 9.1.5 is 'mesa-9.1.5'.
Mesa 9.1.5 is available for download at
ftp://freedesktop.org/pub/mesa/9.1.5/
md5sums:
4ed2af5943141a85a21869053a2fc2eb Me
Everything is done. Every driver that supports 1.30 should enable this
extension.
Signed-off-by: Kenneth Graunke
---
src/mesa/drivers/dri/i965/intel_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c
b/src/mesa/drivers/dri/i965/intel_e
layout(binding = N) is equivalent to calling glUniformBlockBinding(_,N).
This currently only handles the GLSL 1.40 case - no interface names, no
arrays of uniform blocks. This is okay since we don't yet support GLSL
1.50, and don't expose ARB_shading_language_420pack in ES 3.0.
Signed-off-by: Ke
Without an instance name, there is no ir_variable representing the
actual uniform block declaration. When the linker goes to set uniform
initializers, it only sees the members as ir_variables; never the block.
So, unfortunately, the members need to know about the binding.
There has to be a bette
Normally, uniform array variables are initialized by array literals.
That is, val->type->array_elements >= storage->array_elements.
However, samplers are different. Consider a declaration such as:
layout(binding = 5) uniform sampler2D[3];
The initializer value is a single integer (5), while
The first case handles uniform variables whose initializers are array
literals. Prior to GLSL 4.20's "binding" keyword, samplers don't have
initializers at all. With the binding keyword, the "initializer" is a
single integer representing the texture unit to use for the first
element; consecutive
All compilation units need to agree on the binding point, if they
specify one at all.
Signed-off-by: Kenneth Graunke
---
src/glsl/linker.cpp | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index ba97ade..cca66f8 100644
--- a/s
Rather than creating a new "binding" field in ir_variable, we reuse
constant_value since the linker code for handling uniform initializers
uses that.
Since UBOs and samplers can't otherwise have initializers/constant
values, there shouldn't be a conflict.
Signed-off-by: Kenneth Graunke
---
src/
The "binding" qualifier only applies to UBO blocks and samplers, along
with arrays of those types. (It would also apply to images and atomic
counters, but we don't support those yet.)
This also validates sampler bindings against the maximum number of
texture units, and UBO bindings against the nu
Nothing actually uses this yet.
Signed-off-by: Kenneth Graunke
---
src/glsl/ast.h | 14 ++
src/glsl/ast_type.cpp | 6 +-
src/glsl/glsl_parser.yy | 12
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/src/glsl/ast.h b/src/glsl/ast.h
index 6ae
GL_ARB_shading_language_420pack also provides layout qualifiers.
Signed-off-by: Kenneth Graunke
---
src/glsl/glsl_lexer.ll | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/glsl/glsl_lexer.ll b/src/glsl/glsl_lexer.ll
index e66ce7b..dbc8154 100644
--- a/src/glsl/glsl_lexer
Signed-off-by: Kenneth Graunke
---
src/glsl/ast_to_hir.cpp | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
index 3ed6f01..e8ed77a 100644
--- a/src/glsl/ast_to_hir.cpp
+++ b/src/glsl/ast_to_hir.cpp
@@ -2080,12 +2080,6 @@
In the old language rules, you can't specify "centroid" by itself; it's
always "centroid in", "centroid out", or "centroid varying." So one of
the other storage qualifiers will always be set; there's no need to
specifically check for centroid.
In the new rules, centroid is an auxiliary storage qu
On 07/17/2013 06:12 PM, Brian Paul wrote:
> On 07/17/2013 03:10 PM, Kevin H. Hobbs wrote:
>>
>> Can anybody give me a clue as to what's going on?
>
> I'd try to compare Mesa config.log files from 17 vs. 18 to see what
> might be different. Or, just the output from running ./configure on each.
>
From: Roland Scheidegger
Usually with fixed point renderbuffers clamping is done as part of conversion.
However, since we blend in float format, we essentially skip all conversion
steps pre-blend but since this is still a fixed point renderbuffer we must
still clamp the inputs in this case. Makes
From: Roland Scheidegger
We were fixing up the blend factor to ZERO, however this only works correctly
with fixed point render buffers where the input values are clamped to 0/1
(because src_alpha_saturate is min(As, 1-Ad) so can be negative with unclamped
inputs). Haven't seen any failure anywher
Gives +5.68% on 1920x1080 Xonotic on Haswell GT2.
Performance Measurements
system-info {
gpu: haswell_m_gt2 0x0416 rev05
arch: x86_64
kernel: 3.9.9-1-ARCH (Archlinux)
xf86-video-intel: 2.12.11-1 (Archlinux)
libdrm: 2.4.46-2 (Archlinux)
}
test {
nam
Set MOCS to L3_CACHEABLE for the following packets, during the normal
draw upload path and during blorp:
3DSTATE_CONSTANT_PS
3DSTATE_CONSTANT_VS
3DSTATE_DEPTH_BUFFER
3DSTATE_HIER_DEPTH_BUFFER
3DSTATE_STENCIL_BUFFER
3DSTATE_VERTEX_BUFFERS
CMD_STATE_BASE_ADDRESS
SURFAC
For Ivybridge and Haswell.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_defines.h | 20
1 file changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index fa257ac..ebce8b9 100644
--- a/src/
On 07/15/2013 05:14 PM, Jordan Justen wrote:
This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
Note: Cube maps are treated as 2D arrays with 6 times as
many array elements as the cube map array would have.
Signed-off-by: Jordan Justen
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp
NAK this. Better perf changes coming in v2.
On 07/17/2013 02:28 PM, Chad Versace wrote:
Performance Measurements
test {
name: pts/xonotic-1.3.1 1920x1080 quality=high
n: 3
delta: +3.827% +/- 1.55968% (student's t) at 95% confidence
pooled-s: 0.322153
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #15 from Ian Romanick ---
(In reply to comment #14)
> Given that the program is being run as an ordinary unprivileged user, it
> shouldn't be playing games with ldconfig.
It seems unlikely that it is, and that's why I've asked for th
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #14 from Phil Armstrong ---
Given that the program is being run as an ordinary unprivileged user, it
shouldn't be playing games with ldconfig.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #13 from Alan Coopersmith ---
(In reply to comment #12)
> NB. To put this another way, why is the Xserver letting a userspace program
> decide which libraries it should link it's own glx drivers against?
It shouldn't, unless that pro
On 07/17/2013 03:01 PM, Chad Versace wrote:
On 07/17/2013 02:42 PM, Chris Wilson wrote:
On Wed, Jul 17, 2013 at 02:28:55PM -0700, Chad Versace wrote:
Set MOCS to L3_CACHEABLE for the following packets, during the normal
draw upload path and during blorp:
SURFACE_STATE
3DSTATE_DEPTH_BU
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #12 from Phil Armstrong ---
NB. To put this another way, why is the Xserver letting a userspace program
decide which libraries it should link it's own glx drivers against? Isn't that
asking for trouble?
--
You are receiving this mai
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #11 from Phil Armstrong ---
Is the libstdc++ that the Xserver sees replaced? If the server is picking
up the wrong libstdc++... yeah, don't do that. You wouldn't replace parts of
your car engine with random parts from a different mo
On 07/17/2013 03:10 PM, Kevin H. Hobbs wrote:
I build Mesa with OSMesa from git source for testing VTK on two hosts with:
./autogen.sh \
--prefix=/home/kevin/mesa_nightly \
--enable-glx \
--enable-dri \
--enable-shared-glapi \
--enable-gallium-llvm \
--with-gallium-drivers=nouv
On 07/17/2013 02:42 PM, Chris Wilson wrote:
On Wed, Jul 17, 2013 at 02:28:55PM -0700, Chad Versace wrote:
Set MOCS to L3_CACHEABLE for the following packets, during the normal
draw upload path and during blorp:
SURFACE_STATE
3DSTATE_DEPTH_BUFFER
3DSTATE_HIER_DEPTH_BUFFER
3DST
On Wed, Jul 17, 2013 at 02:28:55PM -0700, Chad Versace wrote:
> Set MOCS to L3_CACHEABLE for the following packets, during the normal
> draw upload path and during blorp:
> SURFACE_STATE
> 3DSTATE_DEPTH_BUFFER
> 3DSTATE_HIER_DEPTH_BUFFER
> 3DSTATE_STENCIL_BUFFER
>
> It's not possib
For Ivybridge and Haswell.
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_defines.h | 20
1 file changed, 20 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index fa257ac..ebce8b9 100644
--- a/src/
Performance Measurements
test {
name: pts/xonotic-1.3.1 1920x1080 quality=high
n: 3
delta: +3.827% +/- 1.55968% (student's t) at 95% confidence
pooled-s: 0.322153
mesa-base: master-00d32cd
}
system-info {
gpu: haswell_m_gt2 0x0416 rev05
arch:
Set MOCS to L3_CACHEABLE for the following packets, during the normal
draw upload path and during blorp:
SURFACE_STATE
3DSTATE_DEPTH_BUFFER
3DSTATE_HIER_DEPTH_BUFFER
3DSTATE_STENCIL_BUFFER
It's not possible to set the MOCS of the MCS buffer, because the MCS
inherits MOCS from the p
I build Mesa with OSMesa from git source for testing VTK on two hosts with:
./autogen.sh \
--prefix=/home/kevin/mesa_nightly \
--enable-glx \
--enable-dri \
--enable-shared-glapi \
--enable-gallium-llvm \
--with-gallium-drivers=nouveau,swrast \
--enable-osmesa
When I used Fedora 17
On Wed, Jul 17, 2013 at 10:25:31AM -0500, Aaron Watry wrote:
> On Tue, Jul 9, 2013 at 11:21 PM, Tom Stellard wrote:
> > From: Tom Stellard
> >
> > v2:
> > - Extend to target size rather than aligned size
> > - Support for big-endian
> > ---
> > src/gallium/state_trackers/clover/core/kernel.c
On Tue, Jul 16, 2013 at 07:03:29AM -0700, Jose Fonseca wrote:
> - Original Message -
> > Has anyone had a chance to look at this series?
>
> No, I just noticed this one now.
>
>
> FWIW, I don't see much value in constifying gallium interfaces:
>
> - interfaces like pipe_screen have no s
On 15 July 2013 17:14, Jordan Justen wrote:
> git://people.freedesktop.org/~jljusten/mesa ivb-full-depth-buffer-v1
>
> This series converts DEPTH_BUFFER to use the LOD and
> minimum array element fields and always points the
> depth, hiz and stencil buffers at the top of the
> miptree surface.
>
On 15 July 2013 17:14, Jordan Justen wrote:
> We now also need to stop setting the FORCE_ZERO_RTAINDEX bit
> in the clip date so render target array values other than zero
>
Do you mean "clip state"?
> can be used.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/gen7_clip_
On 15 July 2013 17:14, Jordan Justen wrote:
> In layered rendering this will be 0. Otherwise it will be the
> selected slice.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/gen7_blorp.cpp|6 ++
> src/mesa/drivers/dri/i965/gen7_misc_state.c |9 +
> 2 f
On 15 July 2013 17:14, Jordan Justen wrote:
> This will be used in 3DSTATE_DEPTH_BUFFER in a later patch.
>
> Note: Cube maps are treated as 2D arrays with 6 times as
> many array elements as the cube map array would have.
>
> Signed-off-by: Jordan Justen
> ---
> src/mesa/drivers/dri/i965/gen7
A little clarification of the RFC tag for this series.
Patches 1-9: Should be ready, and could be applied separately
Patch 10: I'm working with Chad to verify this better
Patches 11-12: I need more layered rendering tests
On Mon, Jul 15, 2013 at 5:14 PM, Jordan Justen
wrote:
> git://people.freed
https://bugs.freedesktop.org/show_bug.cgi?id=66955
Ian Romanick changed:
What|Removed |Added
CC||cwo...@cworth.org,
|
Hi all,
It's time to start nailing down the agenda for the Graphics and Display
microconference at the Linux Plumbers Conference 2013. For conference approval
and preliminary planning purposes, we have compiled a list of possible topics
for discussion. The overview and general list of topic ide
On Tue, Jul 9, 2013 at 11:21 PM, Tom Stellard wrote:
> From: Tom Stellard
>
> v2:
> - Extend to target size rather than aligned size
> - Support for big-endian
> ---
> src/gallium/state_trackers/clover/core/kernel.cpp | 58
> --
> src/gallium/state_trackers/clover/core/
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/drivers/common/meta.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/met
Ahh with some documentation and another name this looks much better now.
I don't really deal with dri interfacing much so someone else should
probably give it a look but looks reasonable. I wonder though if we
still need the flush_frontbuffer stuff or if that should go and be
replaced with this plu
We weren't looping over all the slices in the array. The updated
code should also correctly handle 3D compressed textures too, whenever
we have that feature.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850
NOTE: This is a candidate for the 9.1 branch
---
src/mesa/main/mipmap.c |
If we call glGetTexImage() for a compressed 2D texture array we need
to loop over all the slices.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66850
NOTE: This is a candidate for the 9.1 branch.
---
src/mesa/main/texgetimage.c | 52 ---
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=66850
--- Comment #7 from Brian Paul ---
OK, great. I'll post the patches for review and push them.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-
Hi Tom,
I have verified that these patches, along with the previous one fix
the errors that I was getting for SI. The test case from that FD.o
bug still fails, but that's due to attempting to sign extend the
v2i1/v4i1 result to v2i32/v4i32, which isn't necessary when doing
vselect properly.
I've
From: Tomasz Lis
glx: Float configs extension strings.
The patch defines fbconfig_float in tables of extensions and enables
reporting the extension availability.
Signed-off-by: Tomasz Lis
---
src/glx/glxextensions.c |2 ++
src/glx/glxextensions.h |2 ++
2 files changed, 4 insertions(+
From: Tomasz Lis
glx: Creation of dummy X pixmap associated with float buffer.
This change addresses the fact that float configs can be only used for pbuffers,
and that 2D driver may not allow creation of an associated pixmap.
It wouldn't be needed if 2D driver could always support 128 bpp buffe
From: Tomasz Lis
dri: Introduce new flags in __DRI_ATTRIB_RENDER_TYPE.
The patch marks __DRI_ATTRIB_FLOAT_MODE as deprecated and introduces
nrw flags to __DRI_ATTRIB_RENDER_TYPE which are to define float modes.
Both signed float (fbconfig_float) and unsigned (packed_float) is
introduced as a fla
glx: Require proper drawableType in init_fbconfig_for_chooser.
This patch makes sure that init_fbconfig_for_chooser sets correct
value of drawableType for visual configs and fbconfigs.
---
src/glx/glxcmds.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/glx/glxcm
glx: Storing the RENDER_TYPE in indirect rendering.
The change allows to store RENDER_TYPE value in GLX context
when indirect rendering is in use.
---
src/glx/create_context.c |4 +++-
src/glx/glxclient.h |7 +++
src/glx/glxcmds.c|1 -
src/glx/indirect_glx.c | 29
glx: Verification of the RENDER_TYPE value.
The change is to correctly handle the value of renderType in GLX context.
In case of the value being incorrect, context creation fails.
---
src/glx/dri2_glx.c |9 +
src/glx/dri_glx.c |5 +
src/glx/drisw_glx.c
glx: Handling RENDER_TYPE in glXCreateContext and init_fbconfig_for_chooser.
This patch sets the correct values of renderType
in glXCreateContext and init_fbconfig_for_chooser routines.
---
src/glx/glxcmds.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
d
glx: Changes to visual configs initialization.
The change is to correctly handle the value of renderType and
drawableType in fbconfig. This part modifies glXInitializeVisualConfigFromTags
to read the parameter value, or detect it if it's not there.
---
src/glx/glxext.c | 37 ++
glx: Retrieve the value of RENDER_TYPE from GLX attribs array.
This change makes sure that context creation routines are provided
with the value of RENDER_TYPE retrieved from GLX attribs.
---
src/glx/dri2_glx.c |3 ++-
src/glx/dri_common.c |8
src/glx/dri_common.h |2 +-
sr
glx: Store the value of renderType while creating context.
This patch makes sure that renderType property value is stored in GLX context
while it's being created. Further patches will be provided to make the value
correspond to fbconfig's renderType.
---
src/glx/dri2_glx.c |7 +++
src/gl
On 17.07.2013 02:05, Marek Olšák wrote:
> No, it's not faster, but it's not slower either.
>
> Now that I think about it, I can't come up with a good shader-based
> algorithm for the resolve operation.
>
> I don't think Christoph's approach that an MSAA texture can be viewed
> as a larger single-sa
https://bugs.freedesktop.org/show_bug.cgi?id=66833
--- Comment #15 from Vedran Rodic ---
This is confirmed to be fixed in current Dota 2 test build.
--
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
me
Looks good AFAICT.
Just one detail:
s/false/FALSE/
s/true/TRUE/
Jose
- Original Message -
> From: Roland Scheidegger
>
> Instead of just ignoring the srgb/linear conversions, simply call the
> corresponding conversion functions, for all of pack/unpack/fetch,
> both for float and u
From: Tomasz Lis
glx: Float configs extension strings.
The patch defines fbconfig_float in tables of extensions and enables
reporting the extension availability.
Signed-off-by: Tomasz Lis
---
src/glx/glxextensions.c |2 ++
src/glx/glxextensions.h |6 +-
2 files changed, 7 insertio
glx: Handling RENDER_TYPE in glXCreateContext and init_fbconfig_for_chooser.
This patch sets the correct values of renderType
in glXCreateContext and init_fbconfig_for_chooser routines.
---
src/glx/glxcmds.c | 28
1 file changed, 24 insertions(+), 4 deletions(-)
d
77 matches
Mail list logo
