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(-)
From: Tomasz Lis tomasz@intel.com
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 lis...@gmail.com
---
src/glx/glxextensions.c |2 ++
src/glx/glxextensions.h |
Looks good AFAICT.
Just one detail:
s/false/FALSE/
s/true/TRUE/
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Instead of just ignoring the srgb/linear conversions, simply call the
corresponding conversion functions, for all of pack/unpack/fetch,
both
https://bugs.freedesktop.org/show_bug.cgi?id=66833
--- Comment #15 from Vedran Rodic vro...@gmail.com ---
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.
___
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-sample
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 +++
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 +-
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: 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(-)
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 +
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: 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
From: Tomasz Lis tomasz@intel.com
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)
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.
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
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
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
On Tue, Jul 9, 2013 at 11:21 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
v2:
- Extend to target size rather than aligned size
- Support for big-endian
---
src/gallium/state_trackers/clover/core/kernel.cpp | 58
--
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
https://bugs.freedesktop.org/show_bug.cgi?id=66955
Ian Romanick i...@freedesktop.org changed:
What|Removed |Added
CC||cwo...@cworth.org,
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
jordan.l.jus...@intel.com
On 15 July 2013 17:14, Jordan Justen jordan.l.jus...@intel.com 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
On 15 July 2013 17:14, Jordan Justen jordan.l.jus...@intel.com wrote:
In layered rendering this will be 0. Otherwise it will be the
selected slice.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp|6 ++
On 15 July 2013 17:14, Jordan Justen jordan.l.jus...@intel.com 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 jordan.l.jus...@intel.com
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 state
On Wed, Jul 17, 2013 at 10:25:31AM -0500, Aaron Watry wrote:
On Tue, Jul 9, 2013 at 11:21 PM, Tom Stellard t...@stellard.net wrote:
From: Tom Stellard thomas.stell...@amd.com
v2:
- Extend to target size rather than aligned size
- Support for big-endian
---
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
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
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:
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 possible to
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
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 \
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #11 from Phil Armstrong p...@kantaka.co.uk ---
iIs 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
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #12 from Phil Armstrong p...@kantaka.co.uk ---
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #13 from Alan Coopersmith alan.coopersm...@oracle.com ---
(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
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #14 from Phil Armstrong p...@kantaka.co.uk ---
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
https://bugs.freedesktop.org/show_bug.cgi?id=66955
--- Comment #15 from Ian Romanick i...@freedesktop.org ---
(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
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:
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 jordan.l.jus...@intel.com
---
For Ivybridge and Haswell.
Signed-off-by: Chad Versace chad.vers...@linux.intel.com
---
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
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
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 {
From: Roland Scheidegger srol...@vmware.com
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
From: Roland Scheidegger srol...@vmware.com
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
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.
Thank
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
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
GL_ARB_shading_language_420pack also provides layout qualifiers.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
---
Nothing actually uses this yet.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
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
All compilation units need to agree on the binding point, if they
specify one at all.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/glsl/linker.cpp | 22 ++
1 file changed, 22 insertions(+)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index
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
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
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
Everything is done. Every driver that supports 1.30 should enable this
extension.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
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
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
On Wed, Jun 26, 2013 at 12:11 AM, Jonathan Gray j...@jsg.id.au wrote:
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
configure.ac | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git configure.ac configure.ac
index 6832b0d..6a817d0 100644
--- configure.ac
+++
On Wed, Jul 17, 2013 at 09:26:34PM -0700, Vinson Lee wrote:
On Wed, Jun 26, 2013 at 12:11 AM, Jonathan Gray j...@jsg.id.au wrote:
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
configure.ac | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git configure.ac
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
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
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
Signed-off-by: Jonathan Gray j...@jsg.id.au
---
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
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 j...@jsg.id.au
---
Looks good to me.
- Original Message -
From: Roland Scheidegger srol...@vmware.com
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
(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,
66 matches
Mail list logo
