[Mesa-dev] [PATCH 1/2] i965: Add #defines for Memory Object Control State fields on Gen7-7.5.
The L3 controls are identical on all platforms, but LLC differs:
- Ivybridge has a "cache in LLC" flag
- Baytrail has no LLC, but instead has a snoop bit:
"data accesses in this page must be snooped in the CPU caches."
- Haswell has writeback/uncached flags for LLC and eLLC (eDRAM).
Signed-off-by: Kenneth Graunke
Cc: Chad Versace
---
src/mesa/drivers/dri/i965/brw_defines.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 04422fe..db63b2b 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1728,6 +1728,20 @@ enum brw_wm_barycentric_interp_mode {
*/
#define BRW_MAX_NUM_BUFFER_ENTRIES (1 << 27)
+/* Memory Object Control State */
+#define GEN7_MOCS_L31
+
+/* Ivybridge only: cache in LLC */
+#define IVB_MOCS_LLC(1 << 1)
+
+/* Baytrail only: snoop in CPU cache */
+#define BYT_MOCS_SNOOP (1 << 1)
+
+/* Haswell only: LLC/eLLC controls (write-back or uncached) */
+#define HSW_MOCS_UC_LLC_UC_ELLC (1 << 1)
+#define HSW_MOCS_WB_LLC_WB_ELLC (2 << 1)
+#define HSW_MOCS_UC_LLC_WB_ELLC (3 << 1)
+
#include "intel_chipset.h"
#endif
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965: Add MOCS shift and mask for SURFACE_STATE entries.
Signed-off-by: Kenneth Graunke Cc: Chad Versace --- src/mesa/drivers/dri/i965/brw_defines.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index db63b2b..ee802f9 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h @@ -551,6 +551,9 @@ #define GEN7_SURFACE_MIN_LOD_SHIFT 4 #define GEN7_SURFACE_MIN_LOD_MASK INTEL_MASK(7, 4) +#define GEN7_SURFACE_MOCS_SHIFT 16 +#define GEN7_SURFACE_MOCS_MASK INTEL_MASK(19, 16) + /* Surface state DW6 */ #define GEN7_SURFACE_MCS_ENABLE (1 << 0) #define GEN7_SURFACE_MCS_PITCH_SHIFT3 -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/gen7: Add defines for Memory Object Control State
On 07/17/2013 04:46 PM, Chad Versace wrote:
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/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -550,6 +550,8 @@
#define BRW_SURFACE_Y_OFFSET_MASK INTEL_MASK(23, 20)
#define GEN7_SURFACE_MIN_LOD_SHIFT 4
#define GEN7_SURFACE_MIN_LOD_MASK INTEL_MASK(7, 4)
+#define GEN7_SURFACE_MOCS_SHIFT 16
+#define GEN7_SURFACE_MOCS_MASK INTEL_MASK(19, 16)
/* Surface state DW6 */
#define GEN7_SURFACE_MCS_ENABLE (1 << 0)
@@ -1727,6 +1729,24 @@ enum brw_wm_barycentric_interp_mode {
*/
#define BRW_MAX_NUM_BUFFER_ENTRIES(1 << 27)
+/* Memory Object Control State, Gen7 */
+/* L3 Cacheability Control */
+#define GEN7_MOCS_L3_UNCACHEABLE0
+#define GEN7_MOCS_L3_CACHEABLE 1
+/* LCC Cacheability Control */
+#define GEN7_MOCS_LCC_USE_PTE (0 << 1)
+#define GEN7_MOCS_LCC_CACHEABLE (1 << 1)
+
+/* Memory Object Control State, Haswell */
+/* L3 Cacheability Control */
+#define HSW_MOCS_L3_UNCACHEABLE 0
+#define HSW_MOCS_L3_CACHEABLE 1
+/* LCC Cacheability Control */
+#define HSW_MOCS_LCC_USE_PTE(0 << 1)
+#define HSW_MOCS_LCC_UNCACHEABLE(1 << 1)
+#define HSW_MOCS_LCC_WB_TO_LLC_ELLC (2 << 1)
+#define HSW_MOCS_LCC_WB_TO_ELLC (3 << 1)
+
#include "intel_chipset.h"
#endif
I'm really not a fan of "LCC", as that isn't a term used in the
documentation. It's "LLC/eLLC Cacheability Control (LLCCC)".
Also, the L3 defines are the same on Ivybridge, Haswell, and
Baytrail...so it would be nice to just use GEN7 rather than having HSW
#defines.
Chad, would you be okay with using the names in the patches I just sent
out instead of these? I feel like they're a bit more descriptive, and
they have GEN7_* for shared code, and platform-specific ones for both
Haswell and Baytrail.
Sorry for the trouble...
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/hsw: Set MOCS to L3_CACHEABLE for some packets
On 07/17/2013 04:46 PM, Chad Versace wrote:
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
SURFACE_STATE
It's not possible to set the MOCS of the MCS buffer, because the MCS
inherits MOCS from the parent surface.
Gives +5.68% on Xonotic 1920x1080 on Haswell GT2.
At this point, I'm quite happy to accept your choices of what to cache.
Two comments:
I'd really prefer to see each change split into a separate patch. You
don't need to benchmark them separately or anything, but it'd be nice.
I know Eric had hoped to see this happen as well.
I'd also prefer to see:
uint32_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
rather than if-blocks...it's just more concise. Not a big deal either
way, though.
Neither of those should affect the actual changes, so there would be no
need to re-run the benchmarks.
Thanks so much for reviving this work, Chad...really sorry for the trouble.
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 {
name: pts/xonotic-1.3.1 1920x1080 quality=high
delta: +5.68152% +/- 0.653452% (student's t) at 95% confidence
n: 3
pooled-s: 0.288297
mesa-base: master-00d32cd
}
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 3 +++
src/mesa/drivers/dri/i965/brw_misc_state.c| 11 +++-
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 14 +-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 32 ---
src/mesa/drivers/dri/i965/gen7_misc_state.c | 13 +++--
src/mesa/drivers/dri/i965/gen7_vs_state.c | 10 ++-
src/mesa/drivers/dri/i965/gen7_wm_state.c | 10 ++-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 18 -
8 files changed, 100 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 2952027..039c299 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -658,6 +658,9 @@ static void brw_emit_vertices(struct brw_context *brw)
if (brw->gen >= 7)
dw0 |= GEN7_VB0_ADDRESS_MODIFYENABLE;
+if (brw->is_haswell)
+ dw0 |= HSW_MOCS_L3_CACHEABLE << 16;
+
OUT_BATCH(dw0 | (buffer->stride << BRW_VB0_PITCH_SHIFT));
OUT_RELOC(buffer->bo, I915_GEM_DOMAIN_VERTEX, 0, buffer->offset);
if (brw->gen >= 5) {
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 0ab1e76..3811870 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -1023,13 +1023,22 @@ static void upload_state_base_address( struct
brw_context *brw )
*/
if (brw->gen >= 6) {
+ uint32_t mocs;
+
+ if (brw->is_haswell) {
+ mocs = HSW_MOCS_L3_CACHEABLE;
+ } else {
+ mocs = 0;
+ }
+
if (brw->gen == 6)
intel_emit_post_sync_nonzero_flush(brw);
BEGIN_BATCH(10);
OUT_BATCH(CMD_STATE_BASE_ADDRESS << 16 | (10 - 2));
/* General state base address: stateless DP read/write requests */
- OUT_BATCH(1);
+ OUT_BATCH(mocs << 8 |
+ 1 /*general state base address modify enable*/);
/* Surface state base address:
* BINDING_TABLE_STATE
* SURFACE_STATE
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 8056bf5..2a1e765 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -74,9 +74,18 @@ void
gen6_blorp_emit_state_base_address(struct brw_context *brw,
const brw_blorp_params *params)
{
+ uint32_t mocs;
+
+ if (brw->is_haswell) {
+ mocs = HSW_MOCS_L3_CACHEABLE;
+ } else {
+ mocs = 0;
+ }
+
BEGIN_BATCH(10);
OUT_BATCH(CMD_STATE_BASE_ADDRESS << 16 | (10 - 2));
- OUT_BATCH(1); /* GeneralStateBaseAddressModifyEnable */
+ OUT_BATCH(mocs << 8 |
+ 1 /* GeneralStateBaseAddressModifyEnable */);
/* SurfaceStateBaseAddress */
OUT_RELOC(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0, 1);
/* DynamicStateBaseAddress */
@@ -163,6 +172,9 @@ gen6_blorp_emit_vertices(struct brw_context *brw,
if (brw->gen >= 7)
dw0 |= GEN7_VB0_ADDRESS_MODIFYENABLE;
+ if (brw->is_haswell)
+ dw0 |= HSW_MOCS_L3_CACHEABLE << 16;
+
BEGIN_BATCH(batch_length);
OUT_BATCH((_3DSTATE_VERTEX_BUFFERS
[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 --- Comment #17 from Phil Armstrong --- Replaying the crashing trace recorded by apitrace does not cause the Xserver to crash, which seems unsurprising since everything is fine if the binary in question is linked against the system libstdc++ instead of the older bundled one. During the replay, we're recreating the latter situation, so it seems consistent that the Xserver is fine. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] don't include libdrm in an include statement
On Don, 2013-07-18 at 14:45 +1000, Jonathan Gray wrote: > 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 46aa998..1cd85c4 100644 > --- src/gallium/drivers/radeonsi/Makefile.am > +++ src/gallium/drivers/radeonsi/Makefile.am > @@ -29,7 +29,8 @@ AM_CPPFLAGS = \ > -I$(top_srcdir)/src/gallium/drivers/radeon \ > -I$(top_srcdir)/src/gallium/drivers \ > -I$(top_srcdir)/include \ > - $(GALLIUM_CFLAGS) > + $(GALLIUM_CFLAGS) \ > + $(LIBDRM_CFLAGS) > AM_CFLAGS = $(LLVM_CFLAGS) > > libradeonsi_la_SOURCES = $(C_SOURCES) > diff --git src/gallium/winsys/radeon/drm/radeon_winsys.h > src/gallium/winsys/radeon/drm/radeon_winsys.h > index a619d70..a500193 100644 > --- src/gallium/winsys/radeon/drm/radeon_winsys.h > +++ src/gallium/winsys/radeon/drm/radeon_winsys.h > @@ -41,7 +41,7 @@ > */ > > #include "pipebuffer/pb_buffer.h" > -#include "libdrm/radeon_surface.h" > +#include "radeon_surface.h" > > #define RADEON_MAX_CMDBUF_DWORDS (16 * 1024) > I guess this is okay for now, though in the long run we shouldn't leak winsys/platform specific details into the Gallium pipe driver like this. Don't you need to add $(LIBDRM_CFLAGS) to src/gallium/drivers/r600/Makefile.am as well though? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 --- Comment #18 from Michel Dänzer --- (In reply to comment #17) > Replaying the crashing trace recorded by apitrace does not cause the Xserver > to crash, [...] What if you replay it with LIBGL_ALWAYS_INDIRECT=y? I think this is just a normal indirect rendering bug, and libstdc++ only matters insofar as the bad one causes the app to fall back to indirect rendering. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] llvmpipe: clamp inputs for srgb render buffers
Series looks good to me.
Jose
- Original Message -
> 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 no difference for piglit though.
> Obviously we could skip this if fragment color clamping is enabled, but a)
> this is deprecated in OpenGL (d3d never had it) and b) we don't support it
> natively so it gets baked into the shader.
> Also add some comment about logic ops being broken for srgb, luckily no test
> tries to do that as there's no easy fix...
> ---
> src/gallium/drivers/llvmpipe/lp_state_fs.c | 35
>
> 1 file changed, 35 insertions(+)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_state_fs.c
> b/src/gallium/drivers/llvmpipe/lp_state_fs.c
> index a305109..3739941 100644
> --- a/src/gallium/drivers/llvmpipe/lp_state_fs.c
> +++ b/src/gallium/drivers/llvmpipe/lp_state_fs.c
> @@ -1671,6 +1671,35 @@ generate_unswizzled_blend(struct gallivm_state
> *gallivm,
> /* Convert */
> lp_build_conv(gallivm, fs_type, blend_type, &blend_color, 1,
> &blend_color, 1);
>
> + if (out_format_desc->colorspace == UTIL_FORMAT_COLORSPACE_SRGB) {
> + /*
> + * since blending is done with floats, there was no conversion.
> + * However, the rules according to fixed point renderbuffers still
> + * apply, that is we must clamp inputs to 0.0/1.0.
> + * (This would apply to separate alpha conversion too but we currently
> + * force has_alpha to be true.)
> + * TODO: should skip this with "fake" blend, since post-blend
> conversion
> + * will clamp anyway.
> + * TODO: could also skip this if fragment color clamping is enabled.
> We
> + * don't support it natively so it gets baked into the shader however,
> so
> + * can't really tell here.
> + */
> + struct lp_build_context f32_bld;
> + assert(row_type.floating);
> + lp_build_context_init(&f32_bld, gallivm, row_type);
> + for (i = 0; i < src_count; i++) {
> + src[i] = lp_build_clamp(&f32_bld, src[i], f32_bld.zero,
> f32_bld.one);
> + }
> + if (dual_source_blend) {
> + for (i = 0; i < src_count; i++) {
> +src1[i] = lp_build_clamp(&f32_bld, src1[i], f32_bld.zero,
> f32_bld.one);
> + }
> + }
> + /* probably can't be different than row_type but better safe than
> sorry... */
> + lp_build_context_init(&f32_bld, gallivm, blend_type);
> + blend_color = lp_build_clamp(&f32_bld, blend_color, f32_bld.zero,
> f32_bld.one);
> + }
> +
> /* Extract alpha */
> blend_alpha = lp_build_extract_broadcast(gallivm, blend_type, row_type,
> blend_color, lp_build_const_int32(gallivm, 3));
>
> @@ -1827,6 +1856,12 @@ generate_unswizzled_blend(struct gallivm_state
> *gallivm,
> */
> convert_to_blend_type(gallivm, block_size, out_format_desc, dst_type,
> row_type, dst, src_count);
>
> + /*
> +* FIXME: Really should get logic ops / masks out of generic blend / row
> +* format. Logic ops will definitely not work on the blend float format
> +* used for SRGB here and I think OpenGL expects this to work as expected
> +* (that is incoming values converted to srgb then logic op applied).
> +*/
> for (i = 0; i < src_count; ++i) {
>dst[i] = lp_build_blend_aos(gallivm,
>&variant->key.blend,
> --
> 1.7.9.5
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 --- Comment #19 from Phil Armstrong --- Ah, I'd missed that case! -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 --- Comment #20 from Phil Armstrong --- (Hit post accidentally there) OK, so if I just set LIBGL_ALWAYS_INDIRECT, and link the binary against the usual system libraries, not the bundled ones (verified with ldd & running the binary directly, not via any shellscripts) then the Xserver crashes. Replaying the trace doesn't seem the trigger the crash though. It claims that the final call is 'incomplete' so perhaps I'm missing some crucial data? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 --- Comment #21 from Phil Armstrong --- Running apitrace on the trace generated by running $ DISPLAY=:0.0 LIBGL_ALWAYS_INDIRECT=y apitrace trace ./amd64/bin/FTL from an ssh shell (which kills the Xserver) gives me the following output when I replay the trace: $ LIBGL_ALWAYS_INDIRECT=y apitrace replay FTL.trace apitrace: warning: caught signal 11 11813: error: caught an unhandled exception apitrace: info: taking default action for signal 11 but the Xserver remains live. The trace is 85Mb or so. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] don't include libdrm in an include statement
On 18.07.2013 10:24, Michel Dänzer wrote: > Don't you need to add $(LIBDRM_CFLAGS) to > src/gallium/drivers/r600/Makefile.am as well though? I sent a patch that adds $(LIBDRM_CFLAGS) to several Makefile.am in the following mail: http://lists.freedesktop.org/archives/mesa-dev/2013-June/041040.html -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 --- Comment #22 from Phil Armstrong --- tail of the trace dump is as follows: 11773 glGenTextures(n = 1, textures = &1870) 11774 glBindTexture(target = GL_TEXTURE_2D, texture = 1870) 11775 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA, width = 32, height = 32, border = 0, format = GL_RGBA, type = GL_UNSIGNED_BYTE, pixels = blob(4096)) 11776 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_NEAREST) 11777 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) 11778 glGenLists(range = 256) = 1 11779 glGenTextures(n = 256, textures = ?) // incomplete -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66955] Substituting an older libstdc++ when running a GL program causes a segfault in the Xserver.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 --- Comment #23 from Phil Armstrong --- Sorry: the mismatch in numbers is because the replay came from a different dump. Running it on the dump I posted gives the expected $ ~/Code/apitrace/build/apitrace replay FTL.trace apitrace: warning: caught signal 11 11779: error: caught an unhandled exception apitrace: info: taking default action for signal 11 -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] don't include libdrm in an include statement
On Thu, Jul 18, 2013 at 10:24:00AM +0200, Michel Dänzer wrote: > On Don, 2013-07-18 at 14:45 +1000, Jonathan Gray wrote: > > 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 46aa998..1cd85c4 100644 > > --- src/gallium/drivers/radeonsi/Makefile.am > > +++ src/gallium/drivers/radeonsi/Makefile.am > > @@ -29,7 +29,8 @@ AM_CPPFLAGS = \ > > -I$(top_srcdir)/src/gallium/drivers/radeon \ > > -I$(top_srcdir)/src/gallium/drivers \ > > -I$(top_srcdir)/include \ > > - $(GALLIUM_CFLAGS) > > + $(GALLIUM_CFLAGS) \ > > + $(LIBDRM_CFLAGS) > > AM_CFLAGS = $(LLVM_CFLAGS) > > > > libradeonsi_la_SOURCES = $(C_SOURCES) > > diff --git src/gallium/winsys/radeon/drm/radeon_winsys.h > > src/gallium/winsys/radeon/drm/radeon_winsys.h > > index a619d70..a500193 100644 > > --- src/gallium/winsys/radeon/drm/radeon_winsys.h > > +++ src/gallium/winsys/radeon/drm/radeon_winsys.h > > @@ -41,7 +41,7 @@ > > */ > > > > #include "pipebuffer/pb_buffer.h" > > -#include "libdrm/radeon_surface.h" > > +#include "radeon_surface.h" > > > > #define RADEON_MAX_CMDBUF_DWORDS (16 * 1024) > > > > I guess this is okay for now, though in the long run we shouldn't leak > winsys/platform specific details into the Gallium pipe driver like this. > > > Don't you need to add $(LIBDRM_CFLAGS) to > src/gallium/drivers/r600/Makefile.am as well though? I don't need to. Apparently because RADEON_CFLAGS includes the paths, perhaps the radeonsi Makefile.am should have RADEON_CFLAGS instead? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] don't include libdrm in an include statement
On Don, 2013-07-18 at 19:55 +1000, Jonathan Gray wrote: > On Thu, Jul 18, 2013 at 10:24:00AM +0200, Michel Dänzer wrote: > > On Don, 2013-07-18 at 14:45 +1000, Jonathan Gray wrote: > > > 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 46aa998..1cd85c4 100644 > > > --- src/gallium/drivers/radeonsi/Makefile.am > > > +++ src/gallium/drivers/radeonsi/Makefile.am > > > @@ -29,7 +29,8 @@ AM_CPPFLAGS = \ > > > -I$(top_srcdir)/src/gallium/drivers/radeon \ > > > -I$(top_srcdir)/src/gallium/drivers \ > > > -I$(top_srcdir)/include \ > > > - $(GALLIUM_CFLAGS) > > > + $(GALLIUM_CFLAGS) \ > > > + $(LIBDRM_CFLAGS) > > > AM_CFLAGS = $(LLVM_CFLAGS) > > > > > > libradeonsi_la_SOURCES = $(C_SOURCES) > > > diff --git src/gallium/winsys/radeon/drm/radeon_winsys.h > > > src/gallium/winsys/radeon/drm/radeon_winsys.h > > > index a619d70..a500193 100644 > > > --- src/gallium/winsys/radeon/drm/radeon_winsys.h > > > +++ src/gallium/winsys/radeon/drm/radeon_winsys.h > > > @@ -41,7 +41,7 @@ > > > */ > > > > > > #include "pipebuffer/pb_buffer.h" > > > -#include "libdrm/radeon_surface.h" > > > +#include "radeon_surface.h" > > > > > > #define RADEON_MAX_CMDBUF_DWORDS (16 * 1024) > > > > > > > I guess this is okay for now, though in the long run we shouldn't leak > > winsys/platform specific details into the Gallium pipe driver like this. > > > > > > Don't you need to add $(LIBDRM_CFLAGS) to > > src/gallium/drivers/r600/Makefile.am as well though? > > I don't need to. Apparently because RADEON_CFLAGS > includes the paths, perhaps the radeonsi Makefile.am should > have RADEON_CFLAGS instead? That sounds like a better solution to me. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66955] Running the game FTL with LIBGL_ALWAYS_INDIRECT=y set causes the Xserver to crash.
https://bugs.freedesktop.org/show_bug.cgi?id=66955 Phil Armstrong changed: What|Removed |Added Summary|Substituting an older |Running the game FTL with |libstdc++ when running a GL |LIBGL_ALWAYS_INDIRECT=y set |program causes a segfault |causes the Xserver to |in the Xserver. |crash. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 0/3] Wayland: update to 1.2 server API
Hi, Wayland 1.2 server API changed a little bit. The change that affects mesa the most is the deprecation of struct wl_buffer. This series updates all EGL code to use the new API. The motivation for the first patch was to split the usage of server and client API in the same source file in gallium egl. Even though struct wl_buffer is deprecated on the server side, occurences of it on the client side are still valid, but due to the mix of APIs that would cause warnings. In the process of doing that some code duplication is removed. Cheers, Ander Ander Conselvan de Oliveira (3): gallium-egl: Simplify native_wayland_drm_bufmgr_helper interface gallium-egl: Don't add a listener for wl_drm twice in wayland platform egl: Update to Wayland 1.2 server API docs/specs/WL_bind_wayland_display.spec| 8 +- include/EGL/eglmesaext.h | 6 +- src/egl/drivers/dri2/egl_dri2.c| 28 ++- src/egl/drivers/dri2/egl_dri2.h| 1 - src/egl/main/eglapi.c | 2 +- src/egl/main/eglapi.h | 2 +- src/egl/wayland/wayland-drm/wayland-drm.c | 66 +++--- src/egl/wayland/wayland-drm/wayland-drm.h | 13 +- src/gallium/state_trackers/egl/Makefile.am | 2 +- .../state_trackers/egl/common/egl_g3d_api.c| 2 +- .../state_trackers/egl/common/egl_g3d_image.c | 4 +- src/gallium/state_trackers/egl/common/native.h | 2 +- .../egl/common/native_wayland_bufmgr.h | 6 +- .../egl/common/native_wayland_drm_bufmgr.c | 221 + .../egl/common/native_wayland_drm_bufmgr.h | 37 .../egl/common/native_wayland_drm_bufmgr_helper.c | 106 -- .../egl/common/native_wayland_drm_bufmgr_helper.h | 47 - src/gallium/state_trackers/egl/drm/native_drm.c| 52 + src/gallium/state_trackers/egl/drm/native_drm.h| 2 +- .../state_trackers/egl/wayland/native_drm.c| 94 +++-- src/gallium/state_trackers/egl/x11/native_dri2.c | 87 +++- src/gbm/backends/dri/gbm_dri.c | 5 +- 22 files changed, 395 insertions(+), 398 deletions(-) create mode 100644 src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c create mode 100644 src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.h delete mode 100644 src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c delete mode 100644 src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 1/3] gallium-egl: Simplify native_wayland_drm_bufmgr_helper interface
The helper provides a series of functions to easy the implementation
of the WL_bind_wayland_display extension on different platforms. But
even with the helpers there was still a bit of duplicated code between
platforms, with the drm authentication being the only part that
differs.
This patch changes the bufmgr interface to provide a self contained
object with a create function that takes a drm authentication callback
as an argument. That way all the helper functions are made static and
the "_helper" suffix was removed from the sources file name.
This change also removes the mix of Wayland client and server code in
the wayland drm platform source file. All the uses of libwayland-server
are now contained in native_wayland_drm_bufmgr.c.
Changes to the drm platform are only compile tested.
Signed-off-by: Ander Conselvan de Oliveira
---
src/gallium/state_trackers/egl/Makefile.am | 2 +-
src/gallium/state_trackers/egl/common/native.h | 2 +-
.../egl/common/native_wayland_drm_bufmgr.c | 214 +
.../egl/common/native_wayland_drm_bufmgr.h | 37
.../egl/common/native_wayland_drm_bufmgr_helper.c | 106 --
.../egl/common/native_wayland_drm_bufmgr_helper.h | 47 -
src/gallium/state_trackers/egl/drm/native_drm.c| 52 +
src/gallium/state_trackers/egl/drm/native_drm.h| 2 +-
.../state_trackers/egl/wayland/native_drm.c| 93 +++--
src/gallium/state_trackers/egl/x11/native_dri2.c | 87 +++--
10 files changed, 305 insertions(+), 337 deletions(-)
create mode 100644
src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
create mode 100644
src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.h
delete mode 100644
src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c
delete mode 100644
src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h
diff --git a/src/gallium/state_trackers/egl/Makefile.am
b/src/gallium/state_trackers/egl/Makefile.am
index f78b36e..126fafc 100644
--- a/src/gallium/state_trackers/egl/Makefile.am
+++ b/src/gallium/state_trackers/egl/Makefile.am
@@ -38,7 +38,7 @@ libegl_la_SOURCES = \
common/egl_g3d_st.c \
common/egl_g3d_sync.c \
common/native_helper.c \
- common/native_wayland_drm_bufmgr_helper.c
+ common/native_wayland_drm_bufmgr.c
if HAVE_EGL_PLATFORM_X11
libegl_la_SOURCES += \
diff --git a/src/gallium/state_trackers/egl/common/native.h
b/src/gallium/state_trackers/egl/common/native.h
index 431bd3f..797933d 100644
--- a/src/gallium/state_trackers/egl/common/native.h
+++ b/src/gallium/state_trackers/egl/common/native.h
@@ -245,7 +245,7 @@ struct native_display {
const struct native_display_buffer *buffer;
const struct native_display_modeset *modeset;
- const struct native_display_wayland_bufmgr *wayland_bufmgr;
+ struct native_display_wayland_bufmgr *wayland_bufmgr;
};
/**
diff --git a/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
new file mode 100644
index 000..1603a3a
--- /dev/null
+++ b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
@@ -0,0 +1,214 @@
+#include
+#include
+
+#include "native.h"
+#include "util/u_inlines.h"
+#include "state_tracker/drm_driver.h"
+
+#ifdef HAVE_WAYLAND_BACKEND
+
+#include
+#include
+
+#include "native_wayland_drm_bufmgr.h"
+
+#include "wayland-drm.h"
+
+struct wayland_drm_bufmgr {
+ struct native_display_wayland_bufmgr base;
+
+ struct wl_drm *wl_server_drm;
+ char *device_name;
+
+ void *user_data;
+
+ wayland_drm_bufmgr_authenticate_func authenticate;
+};
+
+static INLINE struct wayland_drm_bufmgr *
+wayland_drm_bufmgr(const struct native_display_wayland_bufmgr *base)
+{
+ return (struct wayland_drm_bufmgr *) base;
+}
+
+static int
+wayland_drm_bufmgr_authenticate(void *user_data, uint32_t magic)
+{
+ struct native_display *ndpy = user_data;
+ struct wayland_drm_bufmgr *bufmgr;
+
+ bufmgr = wayland_drm_bufmgr(ndpy->wayland_bufmgr);
+
+ return bufmgr->authenticate(user_data, magic);
+}
+
+static void
+wayland_drm_bufmgr_reference_buffer(void *user_data, uint32_t name, int fd,
+struct wl_drm_buffer *buffer)
+{
+ struct native_display *ndpy = user_data;
+ struct pipe_resource templ;
+ struct winsys_handle wsh;
+ enum pipe_format pf;
+
+ switch (buffer->format) {
+ case WL_DRM_FORMAT_ARGB:
+ pf = PIPE_FORMAT_B8G8R8A8_UNORM;
+ break;
+ case WL_DRM_FORMAT_XRGB:
+ pf = PIPE_FORMAT_B8G8R8X8_UNORM;
+ break;
+ default:
+ pf = PIPE_FORMAT_NONE;
+ break;
+ }
+
+ if (pf == PIPE_FORMAT_NONE)
+ return;
+
+ memset(&templ, 0, sizeof(templ));
+ templ.target = PIPE_TEXTURE_2D;
+ templ.format = pf;
+ templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
+ templ.width0 = buffer->buffer.width;
+ templ.height0
[Mesa-dev] [PATCH mesa 2/3] gallium-egl: Don't add a listener for wl_drm twice in wayland platform
A listener is added just after the interface is bound, in registry_handle_global(). Signed-off-by: Ander Conselvan de Oliveira --- src/gallium/state_trackers/egl/wayland/native_drm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/gallium/state_trackers/egl/wayland/native_drm.c b/src/gallium/state_trackers/egl/wayland/native_drm.c index a4bcdd8..e1aeeeb 100644 --- a/src/gallium/state_trackers/egl/wayland/native_drm.c +++ b/src/gallium/state_trackers/egl/wayland/native_drm.c @@ -227,7 +227,6 @@ wayland_drm_display_init_screen(struct native_display *ndpy) if (wayland_roundtrip(&drmdpy->base) < 0 || drmdpy->wl_drm == NULL) return FALSE; - wl_drm_add_listener(drmdpy->wl_drm, &drm_listener, drmdpy); if (wayland_roundtrip(&drmdpy->base) < 0 || drmdpy->fd == -1) return FALSE; -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa 3/3] egl: Update to Wayland 1.2 server API
Since Wayland 1.2, struct wl_buffer and a few functions are deprecated.
References to wl_buffer are replaced with wl_resource and some getter
functions and calls to deprecated functions are replaced with the proper
new API. The latter changes are related to resource versioning.
Signed-off-by: Ander Conselvan de Oliveira
---
docs/specs/WL_bind_wayland_display.spec| 8 ++-
include/EGL/eglmesaext.h | 6 +-
src/egl/drivers/dri2/egl_dri2.c| 28 +
src/egl/drivers/dri2/egl_dri2.h| 1 -
src/egl/main/eglapi.c | 2 +-
src/egl/main/eglapi.h | 2 +-
src/egl/wayland/wayland-drm/wayland-drm.c | 66 +-
src/egl/wayland/wayland-drm/wayland-drm.h | 13 +++--
.../state_trackers/egl/common/egl_g3d_api.c| 2 +-
.../state_trackers/egl/common/egl_g3d_image.c | 4 +-
.../egl/common/native_wayland_bufmgr.h | 6 +-
.../egl/common/native_wayland_drm_bufmgr.c | 25 +---
src/gbm/backends/dri/gbm_dri.c | 5 +-
13 files changed, 99 insertions(+), 69 deletions(-)
diff --git a/docs/specs/WL_bind_wayland_display.spec
b/docs/specs/WL_bind_wayland_display.spec
index 02bd6ea..8f0083c 100644
--- a/docs/specs/WL_bind_wayland_display.spec
+++ b/docs/specs/WL_bind_wayland_display.spec
@@ -17,7 +17,7 @@ Status
Version
-Version 1, March 1, 2011
+Version 5, July 16, 2013
Number
@@ -57,7 +57,7 @@ New Procedures and Functions
struct wl_display *display);
EGLBoolean eglQueryWaylandBufferWL(EGLDisplay dpy,
- struct wl_buffer *buffer,
+ struct wl_resource *buffer,
EGLint attribute, EGLint *value);
New Tokens
@@ -173,3 +173,7 @@ Revision History
Use EGL_TEXTURE_FORMAT, EGL_TEXTURE_RGB, and EGL_TEXTURE_RGBA,
and just define the new YUV texture formats. Add support for
EGL_WIDTH and EGL_HEIGHT in the query attributes (Kristian Høgsberg)
+Version 5, July 16, 2013
+Change eglQueryWaylandBufferWL to take a resource pointer to the
+buffer instead of a pointer to a struct wl_buffer, as the latter has
+been deprecated. (Ander Conselvan de Oliveira)
diff --git a/include/EGL/eglmesaext.h b/include/EGL/eglmesaext.h
index d476d18..e0eae28 100644
--- a/include/EGL/eglmesaext.h
+++ b/include/EGL/eglmesaext.h
@@ -120,15 +120,15 @@ typedef EGLDisplay (EGLAPIENTRYP PFNEGLGETDRMDISPLAYMESA)
(int fd);
#define EGL_TEXTURE_Y_XUXV_WL 0x31D9
struct wl_display;
-struct wl_buffer;
+struct wl_resource;
#ifdef EGL_EGLEXT_PROTOTYPES
EGLAPI EGLBoolean EGLAPIENTRY eglBindWaylandDisplayWL(EGLDisplay dpy, struct
wl_display *display);
EGLAPI EGLBoolean EGLAPIENTRY eglUnbindWaylandDisplayWL(EGLDisplay dpy, struct
wl_display *display);
-EGLAPI EGLBoolean EGLAPIENTRY eglQueryWaylandBufferWL(EGLDisplay dpy, struct
wl_buffer *buffer, EGLint attribute, EGLint *value);
+EGLAPI EGLBoolean EGLAPIENTRY eglQueryWaylandBufferWL(EGLDisplay dpy, struct
wl_resource *buffer, EGLint attribute, EGLint *value);
#endif
typedef EGLBoolean (EGLAPIENTRYP PFNEGLBINDWAYLANDDISPLAYWL) (EGLDisplay dpy,
struct wl_display *display);
typedef EGLBoolean (EGLAPIENTRYP PFNEGLUNBINDWAYLANDDISPLAYWL) (EGLDisplay
dpy, struct wl_display *display);
-typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYWAYLANDBUFFERWL) (EGLDisplay dpy,
struct wl_buffer *buffer, EGLint attribute, EGLint *value);
+typedef EGLBoolean (EGLAPIENTRYP PFNEGLQUERYWAYLANDBUFFERWL) (EGLDisplay dpy,
struct wl_resource *buffer, EGLint attribute, EGLint *value);
#endif
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 1bce314..44fd8a8 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -41,6 +41,10 @@
#include "egl_dri2.h"
+#ifdef HAVE_WAYLAND_PLATFORM
+#include "wayland-drm.h"
+#endif
+
const __DRIuseInvalidateExtension use_invalidate = {
{ __DRI_USE_INVALIDATE, 1 }
};
@@ -1195,7 +1199,7 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay *disp,
_EGLContext *ctx,
EGLClientBuffer _buffer,
const EGLint *attr_list)
{
- struct wl_drm_buffer *buffer = (struct wl_drm_buffer *) _buffer;
+ struct wl_drm_buffer *buffer;
struct dri2_egl_display *dri2_dpy = dri2_egl_display(disp);
const struct wl_drm_components_descriptor *f;
__DRIimage *dri_image;
@@ -1203,7 +1207,8 @@ dri2_create_image_wayland_wl_buffer(_EGLDisplay *disp,
_EGLContext *ctx,
EGLint err;
int32_t plane;
- if (!wayland_buffer_is_drm(&buffer->buffer))
+ buffer = wayland_drm_buffer_get((struct wl_resource *) _buffer);
+ if (!buffer)
return NULL;
err = _eglParseImageAttribList(&attrs, disp, attr_
Re: [Mesa-dev] [PATCH] r300g: make use of gallium's os_get_process_name()
Pushed, thanks.
Marek
On Thu, Jul 18, 2013 at 8:44 AM, Jonathan Gray wrote:
> 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 100644
> --- src/gallium/drivers/r300/r300_chipset.c
> +++ src/gallium/drivers/r300/r300_chipset.c
> @@ -26,6 +26,7 @@
>
> #include "util/u_debug.h"
> #include "util/u_memory.h"
> +#include "os/os_process.h"
>
> #include
> #include
> @@ -47,9 +48,13 @@ static void r300_apply_hyperz_blacklist(struct
> r300_capabilities* caps)
> "firefox",
> };
> int i;
> +char proc_name[128];
> +
> +if (!os_get_process_name(proc_name, sizeof(proc_name)))
> +return;
>
> for (i = 0; i < Elements(list); i++) {
> -if (strcmp(list[i], program_invocation_short_name) == 0) {
> +if (strcmp(list[i], proc_name) == 0) {
> caps->zmask_ram = 0;
> caps->hiz_ram = 0;
> break;
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Distinction between ARB and EXT dispatch table entries related to framebuffer_object.
On Thu, Jul 18, 2013 at 1:38 AM, Ian Romanick wrote: > For these reasons, glBindFramebuffer and glBindRenderbuffer have different > GLX protocol opcodes than their EXT counterparts. I failed to notice this, > and all of the functions alias each other. This prevents us from being able > to strictly adhere to the specification in GL versions previous to OpenGL > 3.1 (in 3.1+ we no longer expose the EXT extensions, and we only do the > strict ARB behavior). We do expose the EXT extensions in 3.1+. Is that a mistake? Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] don't include libdrm in an include statement
v2: use RADEON_CFLAGS instead of LIBDRM_CFLAGS 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 46aa998..0c27973 100644 --- src/gallium/drivers/radeonsi/Makefile.am +++ src/gallium/drivers/radeonsi/Makefile.am @@ -29,7 +29,8 @@ AM_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/drivers/radeon \ -I$(top_srcdir)/src/gallium/drivers \ -I$(top_srcdir)/include \ - $(GALLIUM_CFLAGS) + $(GALLIUM_CFLAGS) \ + $(RADEON_CFLAGS) AM_CFLAGS = $(LLVM_CFLAGS) libradeonsi_la_SOURCES = $(C_SOURCES) diff --git src/gallium/winsys/radeon/drm/radeon_winsys.h src/gallium/winsys/radeon/drm/radeon_winsys.h index a619d70..a500193 100644 --- src/gallium/winsys/radeon/drm/radeon_winsys.h +++ src/gallium/winsys/radeon/drm/radeon_winsys.h @@ -41,7 +41,7 @@ */ #include "pipebuffer/pb_buffer.h" -#include "libdrm/radeon_surface.h" +#include "radeon_surface.h" #define RADEON_MAX_CMDBUF_DWORDS (16 * 1024) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Direct3D 9 state tracker
I think this Direct3D 9 state tracker is the most important project
since Mesa 1.0. I mean this adds native Direct3D 9 driver
infrastructure for Wine on Linux and as such should eventually be
competitive with Windows in terms of performance.
Do we need the horrible OpenGL anymore? Haha, just kidding.
If the Wine modifications are accepted by upstream Wine, I'd like this
state tracker to get merged. :)
Marek
On Tue, Jul 16, 2013 at 9:43 PM, Christoph Bumiller
wrote:
> So, about two months ago I had the insane idea to pick up Joakim
> Sindholt's Direct3D 9 state tracker that he'd started about 3 years ago
> with the goal to make it run StarCraft 2 so I could finally play at a
> reasonable frame rate ...
>
> With help from Joakim and advice from the wine developers, as well as
> wine's d3d9 tests, things went surprisingly smooth and my original goal
> has been achieved and surpassed, hence I thought I'd post a note here in
> case someone who doesn't yet know about it is interested in trying it out.
>
> ... Now wait, didn't we have a D3D10/11 state tracker already that we
> kicked out because it was unmaintained and not really useful ?
> Yes, but there are a couple of differences to d3d1x:
>
> - the original author has not vanished [yet] (Luca, if you can hear me:
> You cannot leave your children out to die like that !)
> - it's written in C instead of C++ and not relying on horrific multiple
> inheritance with templates hacks to make gcc generate COM-compatible
> vtables (and I'm still not sure if that actually worked)
> - gallium wasn't ready for D3D11, and still isn't (at least the pipe
> drivers aren't), but it is ready for D3D9, and all the features required
> from the pipe drivers are well tested via OpenGL
> - there are no motivating applications using Direct3D 10/11 yet (at
> least for me)
> - and most importantly, contrary to d3d1x, d3d9/st already actually
> works for real applications !
>
> So far I've tried Skyrim, Civilization 5, Anno 1404 and StarCraft 2 on
> the nvc0 and r600g drivers, which work pretty well, at up to x2 the fps
> I get with wined3d (NOTE: no thorough benchmarking done yet).
> Civilization 4 works, too, but it still has a couple of (not too severe)
> rendering issues because I didn't pay much attention to the fixed
> function pipeline and its interaction with the earlier shader versions yet.
>
> If people think it's a good idea to merge it, I'd clean up the few
> modifications I did to gallium, and, once they've been cleared, merge
> the state tracker itself.
> Unfortunately, for proper window system integration, a few modifications
> to wine are required (it used to run without them, but fully correct
> operation isn't possible like that).
>
> Here's the links to the mesa branch containing the state tracker and to
> a patched version of wine:
> https://github.com/chrisbmr/Mesa-3D/tree/gallium-nine
> https://github.com/chrisbmr/wine/tree/d3dadapter9-wip
> (The wine modifications only affect { d3d9.dll.so, gdi32.dll.so,
> user32.dll.so, wineps.drv.so and winex11.drv.so }, so you don't have to
> replace all of it).
>
> Some usage hints:
> https://github.com/chrisbmr/Mesa-3D/blob/gallium-nine/src/gallium/state_trackers/nine/README
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa Driver Changed With OS Update
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? > > My guess is your Fedora 18 system is missing some dependency that was > previously found on your Fedora 17 system. > > 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. > The only differences that stand out to me are: F17 used llvm-3.0 and F18 uses llvm-3.3. the LLVM_LIBS variables differed. I don't have the make output from F17 but the F18 output has : gmake[3]: Entering directory `/home/kevin/mesa/src/gallium/targets/osmesa' CC target.lo GEN libOSMesa.la /usr/bin/ld: cannot find -lLLVMMCJIT /usr/bin/ld: cannot find -lLLVMBitWriter /usr/bin/ld: cannot find -lLLVMX86Disassembler /usr/bin/ld: cannot find -lLLVMX86AsmParser /usr/bin/ld: cannot find -lLLVMX86CodeGen /usr/bin/ld: cannot find -lLLVMSelectionDAG /usr/bin/ld: cannot find -lLLVMAsmPrinter /usr/bin/ld: cannot find -lLLVMMCParser /usr/bin/ld: cannot find -lLLVMX86Desc /usr/bin/ld: cannot find -lLLVMX86Info /usr/bin/ld: cannot find -lLLVMX86AsmPrinter /usr/bin/ld: cannot find -lLLVMX86Utils /usr/bin/ld: cannot find -lLLVMJIT /usr/bin/ld: cannot find -lLLVMRuntimeDyld /usr/bin/ld: cannot find -lLLVMExecutionEngine /usr/bin/ld: cannot find -lLLVMCodeGen /usr/bin/ld: cannot find -lLLVMObjCARCOpts /usr/bin/ld: cannot find -lLLVMScalarOpts /usr/bin/ld: cannot find -lLLVMInstCombine /usr/bin/ld: cannot find -lLLVMTransformUtils /usr/bin/ld: cannot find -lLLVMipa /usr/bin/ld: cannot find -lLLVMAnalysis /usr/bin/ld: cannot find -lLLVMTarget /usr/bin/ld: cannot find -lLLVMMC /usr/bin/ld: cannot find -lLLVMObject /usr/bin/ld: cannot find -lLLVMCore /usr/bin/ld: cannot find -lLLVMSupport collect2: error: ld returned 1 exit status gmake[3]: [libOSMesa.la] Error 1 (ignored) /usr/bin/mkdir -p ../../../../lib; /usr/bin/mkdir -p ../../../../lib/gallium; ln -f .libs/libOSMesa.so ../../../../lib/gallium/libOSMesa.so; ln: accessing ‘.libs/libOSMesa.so’: No such file or directory gmake[3]: [all-local] Error 1 (ignored) ln -f .libs/libOSMesa.so.8 ../../../../lib/gallium/libOSMesa.so.8; ln: accessing ‘.libs/libOSMesa.so.8’: No such file or directory gmake[3]: [all-local] Error 1 (ignored) cp .libs/libOSMesa.so.8.0.0 ../../../../lib/gallium/ cp: cannot stat ‘.libs/libOSMesa.so.8.0.0’: No such file or directory gmake[3]: [all-local] Error 1 (ignored) gmake[3]: Leaving directory `/home/kevin/mesa/src/gallium/targets/osmesa' I should have noticed this earlier but libOSMesa.so* exist in the install directory so I didn't think to check until now. In fact this output repeats for nouveau and others. In the mesa build tree for F17 lib/gallium/ has lots of stuff but is empty in the mesa build tree for F18. I cannot find these libs anywhere on my system. Everything builds if I add --with-llvm-shared-libs. There also exists the F18 package llvm-static.x86_64 which I don't have installed... When I install the static libraries everything builds. signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965/gen7: Add defines for Memory Object Control State
On 07/18/2013 12:20 AM, Kenneth Graunke wrote: On 07/17/2013 04:46 PM, Chad Versace wrote: +/* Memory Object Control State, Gen7 */ +/* L3 Cacheability Control */ +#define GEN7_MOCS_L3_UNCACHEABLE0 +#define GEN7_MOCS_L3_CACHEABLE 1 +/* LCC Cacheability Control */ +#define GEN7_MOCS_LCC_USE_PTE (0 << 1) +#define GEN7_MOCS_LCC_CACHEABLE (1 << 1) + +/* Memory Object Control State, Haswell */ +/* L3 Cacheability Control */ +#define HSW_MOCS_L3_UNCACHEABLE 0 +#define HSW_MOCS_L3_CACHEABLE 1 +/* LCC Cacheability Control */ +#define HSW_MOCS_LCC_USE_PTE(0 << 1) +#define HSW_MOCS_LCC_UNCACHEABLE(1 << 1) +#define HSW_MOCS_LCC_WB_TO_LLC_ELLC (2 << 1) +#define HSW_MOCS_LCC_WB_TO_ELLC (3 << 1) + #include "intel_chipset.h" #endif I'm really not a fan of "LCC", as that isn't a term used in the documentation. It's "LLC/eLLC Cacheability Control (LLCCC)". I'm not a fan of that LCC either. Glad to see you chose a better naming scheme. Also, the L3 defines are the same on Ivybridge, Haswell, and Baytrail...so it would be nice to just use GEN7 rather than having HSW #defines. I agree. Chad, would you be okay with using the names in the patches I just sent out instead of these? I feel like they're a bit more descriptive, and they have GEN7_* for shared code, and platform-specific ones for both Haswell and Baytrail. I think your naming scheme is better, so let's go with yours. But I do have a comment/request on your names; see the reply to your patch. Sorry for the trouble... No trouble. The mailing list is here to make code better, and that's we're doing now. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965/hsw: Set MOCS to L3_CACHEABLE for some packets
On 07/18/2013 12:31 AM, Kenneth Graunke wrote: On 07/17/2013 04:46 PM, Chad Versace wrote: 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 SURFACE_STATE It's not possible to set the MOCS of the MCS buffer, because the MCS inherits MOCS from the parent surface. Gives +5.68% on Xonotic 1920x1080 on Haswell GT2. At this point, I'm quite happy to accept your choices of what to cache. Two comments: I'd really prefer to see each change split into a separate patch. You don't need to benchmark them separately or anything, but it'd be nice. I know Eric had hoped to see this happen as well. I considered that, but hesitated. I agree, such a patch series will be nicer. V3 coming soon. I'd also prefer to see: uint32_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0; rather than if-blocks...it's just more concise. Not a big deal either way, though. Sure. The if-blocks were an artifact of a more complex experiment I was doing. But, now that the MOCS settings are so simple, there's no longer a need for the if-block. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Add #defines for Memory Object Control State fields on Gen7-7.5.
On 07/18/2013 12:10 AM, Kenneth Graunke wrote:
The L3 controls are identical on all platforms, but LLC differs:
- Ivybridge has a "cache in LLC" flag
- Baytrail has no LLC, but instead has a snoop bit:
"data accesses in this page must be snooped in the CPU caches."
- Haswell has writeback/uncached flags for LLC and eLLC (eDRAM).
Signed-off-by: Kenneth Graunke
Cc: Chad Versace
---
src/mesa/drivers/dri/i965/brw_defines.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 04422fe..db63b2b 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1728,6 +1728,20 @@ enum brw_wm_barycentric_interp_mode {
*/
#define BRW_MAX_NUM_BUFFER_ENTRIES(1 << 27)
+/* Memory Object Control State */
+#define GEN7_MOCS_L31
+
+/* Ivybridge only: cache in LLC */
+#define IVB_MOCS_LLC(1 << 1)
+
+/* Baytrail only: snoop in CPU cache */
+#define BYT_MOCS_SNOOP (1 << 1)
+
+/* Haswell only: LLC/eLLC controls (write-back or uncached) */
+#define HSW_MOCS_UC_LLC_UC_ELLC (1 << 1)
+#define HSW_MOCS_WB_LLC_WB_ELLC (2 << 1)
+#define HSW_MOCS_UC_LLC_WB_ELLC (3 << 1)
I like these names better than my names. But...
The significance of dw0[0]=0 and dw0[1:2]=0, on both ivb and hsw, differ
greatly.
But that difference is not apparent from the token names nor the comments.
dw0[0]=0 means "uncacheable in L3", but dw0[1:2]=0 means "use the cacheability
controls from the PTE".
Please add some brief comments to that effect in the patch. Otherwise, I think
misunderstanding that difference will be a very easy, and frequent, mistake
made by many of us, including my future self.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] i965: Add MOCS shift and mask for SURFACE_STATE entries.
On 07/18/2013 12:10 AM, Kenneth Graunke wrote: Signed-off-by: Kenneth Graunke Cc: Chad Versace --- src/mesa/drivers/dri/i965/brw_defines.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_defines.h b/src/mesa/drivers/dri/i965/brw_defines.h index db63b2b..ee802f9 100644 --- a/src/mesa/drivers/dri/i965/brw_defines.h +++ b/src/mesa/drivers/dri/i965/brw_defines.h @@ -551,6 +551,9 @@ #define GEN7_SURFACE_MIN_LOD_SHIFT 4 #define GEN7_SURFACE_MIN_LOD_MASK INTEL_MASK(7, 4) +#define GEN7_SURFACE_MOCS_SHIFT 16 +#define GEN7_SURFACE_MOCS_MASK INTEL_MASK(19, 16) + /* Surface state DW6 */ #define GEN7_SURFACE_MCS_ENABLE (1 << 0) #define GEN7_SURFACE_MCS_PITCH_SHIFT3 Patch 2 is Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa/main: Check for 0 size draws after validation.
On Sat, May 25, 2013 at 4:33 AM, Fabian Bieler wrote: > When validating draw parameters move check for 0 draw count last > (drawing with count 0 is not an error), so that other parameters (e.g.: the > primitive type) are validated and the correct errors (if applicable) are > generated. > > >From the OpenGL 3.3 spec page 33 (page 48 of the PDF): > "[Regarding DrawArraysOneInstance, in terms of which other draw operations > are defined:] > If count is negative, an INVALID_VALUE error is generated." > > This patch also changes the bahavior of MultiDrawElements to perform the draw > operation if some primitive's index counts are zero. > > Signed-off-by: Fabian Bieler > --- Was this committed? I don't see it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 66806] [softpipe] glxgears floating point exception
https://bugs.freedesktop.org/show_bug.cgi?id=66806 Vinson Lee changed: What|Removed |Added CC||jfons...@vmware.com, ||srol...@vmware.com --- Comment #4 from Vinson Lee --- commit 63386b2f66a6d450889cd5368bc599beb7f1efbf also regresses ~4000 piglit tests on softpipe. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2] i965: Add #defines for Memory Object Control State fields on Gen7-7.5.
The L3 controls are identical on all platforms, but LLC differs:
- Ivybridge has a "cache in LLC" flag
- Baytrail has no LLC, but instead has a snoop bit:
"data accesses in this page must be snooped in the CPU caches."
- Haswell has writeback/uncached flags for LLC and eLLC (eDRAM).
Signed-off-by: Kenneth Graunke
Cc: Chad Versace
---
src/mesa/drivers/dri/i965/brw_defines.h | 25 +
1 file changed, 25 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index c6b8dab..49d9360 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -1730,6 +1730,31 @@ enum brw_wm_barycentric_interp_mode {
*/
#define BRW_MAX_NUM_BUFFER_ENTRIES (1 << 27)
+/* Memory Object Control State:
+ * Specifying zero for L3 means "uncached in L3", at least on Haswell
+ * and Baytrail, since there are no PTE flags for setting L3 cacheability.
+ * On Ivybridge, the PTEs do have a cache-in-L3 bit, so setting MOCS to 0
+ * may still respect that.
+ */
+#define GEN7_MOCS_L31
+
+/* Ivybridge only: cache in LLC.
+ * Specifying zero here means to use the PTE values set by the kernel;
+ * non-zero overrides the PTE values.
+ */
+#define IVB_MOCS_LLC(1 << 1)
+
+/* Baytrail only: snoop in CPU cache */
+#define BYT_MOCS_SNOOP (1 << 1)
+
+/* Haswell only: LLC/eLLC controls (write-back or uncached).
+ * Specifying zero here means to use the PTE values set by the kernel;
+ * non-zero overrides the PTE values.
+ */
+#define HSW_MOCS_UC_LLC_UC_ELLC (1 << 1)
+#define HSW_MOCS_WB_LLC_WB_ELLC (2 << 1)
+#define HSW_MOCS_UC_LLC_WB_ELLC (3 << 1)
+
#include "intel_chipset.h"
#endif
--
1.8.3.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Distinction between ARB and EXT dispatch table entries related to framebuffer_object.
On 07/18/2013 05:23 AM, Marek Olšák wrote: On Thu, Jul 18, 2013 at 1:38 AM, Ian Romanick wrote: For these reasons, glBindFramebuffer and glBindRenderbuffer have different GLX protocol opcodes than their EXT counterparts. I failed to notice this, and all of the functions alias each other. This prevents us from being able to strictly adhere to the specification in GL versions previous to OpenGL 3.1 (in 3.1+ we no longer expose the EXT extensions, and we only do the strict ARB behavior). We do expose the EXT extensions in 3.1+. Is that a mistake? Hmm... yeah, we probably shouldn't expose that or the other EXT extension that got folded into GL_ARB_framebuffer_object (e.g., GL_EXT_framebuffer_blit). Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/11] glsl: Parse the "binding" keyword and store it in ast_type_qualifier.
On 17 July 2013 18:24, Kenneth Graunke wrote:
> 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 6aede00..d98f1a3 100644
> --- a/src/glsl/ast.h
> +++ b/src/glsl/ast.h
> @@ -413,6 +413,12 @@ struct ast_type_qualifier {
> */
> unsigned explicit_index:1;
>
> + /**
> + * Flag set if GL_ARB_shading_language_420pack "binding" layout
> + * qualifier is used.
> + */
> + unsigned explicit_binding:1;
> +
> /** \name Layout qualifiers for GL_AMD_conservative_depth */
> /** \{ */
> unsigned depth_any:1;
> @@ -456,6 +462,14 @@ struct ast_type_qualifier {
> int index;
>
> /**
> +* Binding specified via GL_ARB_shading_language_420pack's "binding"
> keyword.
> +*
> +* \note
> +* This field is only valid if \c explicit_binding is set.
> +*/
> + int binding;
> +
> + /**
> * Return true if and only if an interpolation qualifier is present.
> */
> bool has_interpolation() const;
> diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp
> index 4cbb835..275b2a1 100644
> --- a/src/glsl/ast_type.cpp
> +++ b/src/glsl/ast_type.cpp
> @@ -71,7 +71,8 @@ ast_type_qualifier::has_layout() const
>|| this->flags.q.row_major
>|| this->flags.q.packed
>|| this->flags.q.explicit_location
> - || this->flags.q.explicit_index;
> + || this->flags.q.explicit_index
> + || this->flags.q.explicit_binding;
> }
>
> bool
> @@ -145,6 +146,9 @@ ast_type_qualifier::merge_qualifier(YYLTYPE *loc,
> if (q.flags.q.explicit_index)
>this->index = q.index;
>
> + if (q.flags.q.explicit_binding)
> + this->binding = q.binding;
> +
> return true;
> }
>
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index 3867cf8..013b327 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -1254,6 +1254,18 @@ layout_qualifier_id:
> }
>}
>
> + if (state->ARB_shading_language_420pack_enable &&
> + strcmp("binding", $1) == 0) {
> + $$.flags.q.explicit_binding = 1;
> +
> + if ($3 >= 0) {
>
Isn't this redundant with the check performed by validate_binding_qualifier
(which is added in patch 4)? I'd rather not do the same check in two
places, and I have a minor preference to drop it from here and do it only
in validate_binding_qualifier.
> +$$.binding = $3;
> + } else {
> +_mesa_glsl_error(& @3, state, "invalid binding %d
> specified\n", $3);
> +YYERROR;
> + }
> + }
> +
>/* If the identifier didn't match any known layout identifiers,
> * emit an error.
> */
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/11] glsl: Parse the "binding" keyword and store it in ast_type_qualifier.
On 07/18/2013 11:39 AM, Paul Berry wrote:
On 17 July 2013 18:24, Kenneth Graunke mailto:kenn...@whitecape.org>> wrote:
Nothing actually uses this yet.
Signed-off-by: Kenneth Graunke mailto: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 b/src/glsl/ast.h
index 6aede00..d98f1a3 100644
--- a/src/glsl/ast.h
+++ b/src/glsl/ast.h
@@ -413,6 +413,12 @@ struct ast_type_qualifier {
*/
unsigned explicit_index:1;
+ /**
+ * Flag set if GL_ARB_shading_language_420pack "binding"
layout
+ * qualifier is used.
+ */
+ unsigned explicit_binding:1;
+
/** \name Layout qualifiers for GL_AMD_conservative_depth */
/** \{ */
unsigned depth_any:1;
@@ -456,6 +462,14 @@ struct ast_type_qualifier {
int index;
/**
+* Binding specified via GL_ARB_shading_language_420pack's
"binding" keyword.
+*
+* \note
+* This field is only valid if \c explicit_binding is set.
+*/
+ int binding;
+
+ /**
* Return true if and only if an interpolation qualifier is
present.
*/
bool has_interpolation() const;
diff --git a/src/glsl/ast_type.cpp b/src/glsl/ast_type.cpp
index 4cbb835..275b2a1 100644
--- a/src/glsl/ast_type.cpp
+++ b/src/glsl/ast_type.cpp
@@ -71,7 +71,8 @@ ast_type_qualifier::has_layout() const
|| this->flags.q.row_major
|| this->flags.q.packed
|| this->flags.q.explicit_location
- || this->flags.q.explicit_index;
+ || this->flags.q.explicit_index
+ || this->flags.q.explicit_binding;
}
bool
@@ -145,6 +146,9 @@ ast_type_qualifier::merge_qualifier(YYLTYPE *loc,
if (q.flags.q.explicit_index)
this->index = q.index;
+ if (q.flags.q.explicit_binding)
+ this->binding = q.binding;
+
return true;
}
diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
index 3867cf8..013b327 100644
--- a/src/glsl/glsl_parser.yy
+++ b/src/glsl/glsl_parser.yy
@@ -1254,6 +1254,18 @@ layout_qualifier_id:
}
}
+ if (state->ARB_shading_language_420pack_enable &&
+ strcmp("binding", $1) == 0) {
+ $$.flags.q.explicit_binding = 1;
+
+ if ($3 >= 0) {
Isn't this redundant with the check performed by
validate_binding_qualifier (which is added in patch 4)? I'd rather not
do the same check in two places, and I have a minor preference to drop
it from here and do it only in validate_binding_qualifier.
Yes, mostly. The YYERROR here causes it to stop parsing as well, but I
don't really know if that's a feature. All the other layout qualifiers
enforce the >= 0 check here in the parser, so I did likewise for symmetry.
But I do prefer handling all the range checking in one place, so I'm
happy to remove this and just keep the check in
validate_binding_qualifier().
+$$.binding = $3;
+ } else {
+_mesa_glsl_error(& @3, state, "invalid binding %d
specified\n", $3);
+YYERROR;
+ }
+ }
+
/* If the identifier didn't match any known layout identifiers,
* emit an error.
*/
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 11/11] i965: Enable the GL_ARB_shading_language_420pack extension on Gen6+.
While all the work is in the shared GLSL compiler, this extension requires GLSL 1.30, which is currently only supported on Gen6+. 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_extensions.c index 1e762ef..409d40b 100644 --- a/src/mesa/drivers/dri/i965/intel_extensions.c +++ b/src/mesa/drivers/dri/i965/intel_extensions.c @@ -139,6 +139,7 @@ intelInitExtensions(struct gl_context *ctx) ctx->Extensions.ARB_draw_buffers_blend = true; ctx->Extensions.ARB_ES3_compatibility = true; ctx->Extensions.ARB_uniform_buffer_object = true; + ctx->Extensions.ARB_shading_language_420pack = true; ctx->Extensions.ARB_texture_buffer_object = true; ctx->Extensions.ARB_texture_buffer_object_rgb32 = true; ctx->Extensions.ARB_texture_cube_map_array = true; -- 1.8.3.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 12/11] st/mesa: Enable the ARB_shading_language_420pack extension for 1.30+.
Any driver that supports GLSL 1.30 should be able to handle this
extension, as it's entirely implemented in the GLSL compiler.
Signed-off-by: Kenneth Graunke
---
src/mesa/state_tracker/st_extensions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index 32348ef..d019429 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -615,6 +615,7 @@ void st_init_extensions(struct st_context *st)
ctx->Extensions.ARB_shader_bit_encoding = GL_TRUE;
ctx->Extensions.ARB_shading_language_packing = GL_TRUE;
ctx->Extensions.OES_depth_texture_cube_map = GL_TRUE;
+ ctx->Extensions.ARB_shading_language_420pack = GL_TRUE;
} else {
/* Optional integer support for GLSL 1.2. */
if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
--
1.8.3.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH 00/12] Enable GL_AMD_vertex_shader_layer extension
On Wed, Jul 17, 2013 at 1:09 PM, Paul Berry wrote: > 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. >> >> This should allows us to support layered rendering, >> although testing of this is not completed. Layered >> rendering will be required for GL 3.2 / GLSL 1.50 >> support, but it can also be exposed via the >> GL_AMD_vertex_shader_layer extension. > > > I sent out comments on patches 2, 6, and 11. The remainder are: > > Reviewed-by: Paul Berry > > One question, though: > > One of the things I recall us talking about is the problem that Intel > hardware assumes that we always render to the same level/layer of the depth > buffer as we do to the stencil buffer. When the framebuffer is layered, > that happens automatically, but when the framebuffer isn't layered, there's > nothing in the GL API to enforce this restriction. > > I recall some time ago talking about two possible solutions to that: > > (a) If the user tries to create a non-layered framebuffer where the depth > and stencil attachments use different level/layer settings, mark the > framebuffer as incomplete using FRAMEBUFFER_UNSUPPORTED (the GL spec allows > for this in order to accommodate implementation-dependent restrictions, and > it sounds like this is precisely the situation we find ourselves in) > > (b) If the user tries to render to a non-layered framebuffer in which the > depth and stencil attachments use different level/layer settings, blit into > a temporary non-layered depth/stencil buffer for the duration of rendering > (much of the infrastructure behind brw_workaround_depthstencil_alignment() > could probably be re-used for this purpose). > > I don't see your series doing either of these two things. Am I missing > something? No. Sorry, I missed this. > My preference, incidentally, is to do (a), since it's far easier, and it's > totally permitted by the GL spec. If we discover that marking the > framebuffer as incomplete is causing real-world apps to fail, we can always > switch to (b) in the future. I made a quick hack depthstencil-different-lod test here: git://people.freedesktop.org/~jljusten/piglit depthstencil-different-lod http://cgit.freedesktop.org/~jljusten/piglit/commit/?h=depthstencil-different-lod&id=2ce6ca61 It tries to attach depth lod 1 and stencil lod 0. This test does not try to render anything. It just tries to set up the framebuffer. On Mesa IVB (as expected) this currently succeeds. On 3.3.0 NVIDIA 304.88 / GeForce GT 240/PCIe/SSE2, I see framebuffer incomplete. Based on this, it seems likely that this might be an okay candidate for framebuffer incomplete, but should we check more drivers? Does my test code look like it is checking properly? -Jordan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa 1/3] gallium-egl: Simplify native_wayland_drm_bufmgr_helper interface
On 18/07/13 13:11, Ander Conselvan de Oliveira wrote:
> The helper provides a series of functions to easy the implementation
> of the WL_bind_wayland_display extension on different platforms. But
> even with the helpers there was still a bit of duplicated code between
> platforms, with the drm authentication being the only part that
> differs.
>
> This patch changes the bufmgr interface to provide a self contained
> object with a create function that takes a drm authentication callback
> as an argument. That way all the helper functions are made static and
> the "_helper" suffix was removed from the sources file name.
>
> This change also removes the mix of Wayland client and server code in
> the wayland drm platform source file. All the uses of libwayland-server
> are now contained in native_wayland_drm_bufmgr.c.
>
> Changes to the drm platform are only compile tested.
>
Hi Ander Conselvan de Oliveira
Thanks for doing this, I was wondering what's happening with my mesa
build since updating wayland to 1.2 :)
I have a rather silly question
> Signed-off-by: Ander Conselvan de Oliveira
>
> ---
> src/gallium/state_trackers/egl/Makefile.am | 2 +-
> src/gallium/state_trackers/egl/common/native.h | 2 +-
> .../egl/common/native_wayland_drm_bufmgr.c | 214
> +
> .../egl/common/native_wayland_drm_bufmgr.h | 37
> .../egl/common/native_wayland_drm_bufmgr_helper.c | 106 --
> .../egl/common/native_wayland_drm_bufmgr_helper.h | 47 -
> src/gallium/state_trackers/egl/drm/native_drm.c| 52 +
> src/gallium/state_trackers/egl/drm/native_drm.h| 2 +-
> .../state_trackers/egl/wayland/native_drm.c| 93 +++--
> src/gallium/state_trackers/egl/x11/native_dri2.c | 87 +++--
> 10 files changed, 305 insertions(+), 337 deletions(-)
> create mode 100644
> src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
> create mode 100644
> src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.h
> delete mode 100644
> src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c
> delete mode 100644
> src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h
[...]
> diff --git
> a/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
> b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
> new file mode 100644
> index 000..1603a3a
> --- /dev/null
> +++ b/src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c
> @@ -0,0 +1,214 @@
> +#include
> +#include
> +
> +#include "native.h"
> +#include "util/u_inlines.h"
> +#include "state_tracker/drm_driver.h"
> +
> +#ifdef HAVE_WAYLAND_BACKEND
> +
> +#include
> +#include
> +
> +#include "native_wayland_drm_bufmgr.h"
> +
> +#include "wayland-drm.h"
> +
> +struct wayland_drm_bufmgr {
> + struct native_display_wayland_bufmgr base;
> +
> + struct wl_drm *wl_server_drm;
> + char *device_name;
> +
> + void *user_data;
> +
> + wayland_drm_bufmgr_authenticate_func authenticate;
> +};
> +
> +static INLINE struct wayland_drm_bufmgr *
> +wayland_drm_bufmgr(const struct native_display_wayland_bufmgr *base)
> +{
> + return (struct wayland_drm_bufmgr *) base;
> +}
> +
> +static int
> +wayland_drm_bufmgr_authenticate(void *user_data, uint32_t magic)
> +{
> + struct native_display *ndpy = user_data;
> + struct wayland_drm_bufmgr *bufmgr;
> +
> + bufmgr = wayland_drm_bufmgr(ndpy->wayland_bufmgr);
> +
> + return bufmgr->authenticate(user_data, magic);
> +}
> +
> +static void
> +wayland_drm_bufmgr_reference_buffer(void *user_data, uint32_t name, int fd,
> +struct wl_drm_buffer *buffer)
> +{
> + struct native_display *ndpy = user_data;
> + struct pipe_resource templ;
> + struct winsys_handle wsh;
> + enum pipe_format pf;
> +
> + switch (buffer->format) {
> + case WL_DRM_FORMAT_ARGB:
> + pf = PIPE_FORMAT_B8G8R8A8_UNORM;
> + break;
> + case WL_DRM_FORMAT_XRGB:
> + pf = PIPE_FORMAT_B8G8R8X8_UNORM;
> + break;
> + default:
> + pf = PIPE_FORMAT_NONE;
> + break;
> + }
> +
> + if (pf == PIPE_FORMAT_NONE)
> + return;
> +
> + memset(&templ, 0, sizeof(templ));
> + templ.target = PIPE_TEXTURE_2D;
> + templ.format = pf;
> + templ.bind = PIPE_BIND_RENDER_TARGET | PIPE_BIND_SAMPLER_VIEW;
> + templ.width0 = buffer->buffer.width;
> + templ.height0 = buffer->buffer.height;
> + templ.depth0 = 1;
> + templ.array_size = 1;
> +
> + memset(&wsh, 0, sizeof(wsh));
> + wsh.handle = name;
> + wsh.stride = buffer->stride[0];
> +
> + buffer->driver_buffer =
> + ndpy->screen->resource_from_handle(ndpy->screen, &templ, &wsh);
> +}
> +
> +static void
> +wayland_drm_bufmgr_unreference_buffer(void *user_data,
> + struct wl_drm_buffer *buffer)
> +{
> + struct pipe_resource *resource = buffer->driver_buffer;
> +
> + pipe_resource_reference(&resource, NU
Re: [Mesa-dev] [PATCH mesa 0/3] Wayland: update to 1.2 server API
On 07/18/2013 02:11 PM, Ander Conselvan de Oliveira wrote: > Hi, > > Wayland 1.2 server API changed a little bit. The change that affects > mesa the most is the deprecation of struct wl_buffer. This series > updates all EGL code to use the new API. > > The motivation for the first patch was to split the usage of server and > client API in the same source file in gallium egl. Even though struct > wl_buffer is deprecated on the server side, occurences of it on the > client side are still valid, but due to the mix of APIs that would > cause warnings. In the process of doing that some code duplication is > removed. > > Cheers, > Ander > > Ander Conselvan de Oliveira (3): > gallium-egl: Simplify native_wayland_drm_bufmgr_helper interface > gallium-egl: Don't add a listener for wl_drm twice in wayland platform > egl: Update to Wayland 1.2 server API > > docs/specs/WL_bind_wayland_display.spec| 8 +- > include/EGL/eglmesaext.h | 6 +- > src/egl/drivers/dri2/egl_dri2.c| 28 ++- > src/egl/drivers/dri2/egl_dri2.h| 1 - > src/egl/main/eglapi.c | 2 +- > src/egl/main/eglapi.h | 2 +- > src/egl/wayland/wayland-drm/wayland-drm.c | 66 +++--- > src/egl/wayland/wayland-drm/wayland-drm.h | 13 +- > src/gallium/state_trackers/egl/Makefile.am | 2 +- > .../state_trackers/egl/common/egl_g3d_api.c| 2 +- > .../state_trackers/egl/common/egl_g3d_image.c | 4 +- > src/gallium/state_trackers/egl/common/native.h | 2 +- > .../egl/common/native_wayland_bufmgr.h | 6 +- > .../egl/common/native_wayland_drm_bufmgr.c | 221 > + > .../egl/common/native_wayland_drm_bufmgr.h | 37 > .../egl/common/native_wayland_drm_bufmgr_helper.c | 106 -- > .../egl/common/native_wayland_drm_bufmgr_helper.h | 47 - > src/gallium/state_trackers/egl/drm/native_drm.c| 52 + > src/gallium/state_trackers/egl/drm/native_drm.h| 2 +- > .../state_trackers/egl/wayland/native_drm.c| 94 +++-- > src/gallium/state_trackers/egl/x11/native_dri2.c | 87 +++- > src/gbm/backends/dri/gbm_dri.c | 5 +- > 22 files changed, 395 insertions(+), 398 deletions(-) > create mode 100644 > src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.c > create mode 100644 > src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr.h > delete mode 100644 > src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.c > delete mode 100644 > src/gallium/state_trackers/egl/common/native_wayland_drm_bufmgr_helper.h > patches break my multilib build (without wayland) CC x11/native_x11.lo x11/native_dri2.c: In function 'dri2_display_destroy': x11/native_dri2.c:760:4: error: implicit declaration of function 'wayland_drm_bufmgr_destroy' [-Werror=implicit-function-declaration] wayland_drm_bufmgr_destroy(ndpy->wayland_bufmgr); ^ cc1: some warnings being treated as errors make[3]: *** [x11/native_dri2.lo] Error 1 make[3]: *** Waiting for unfinished jobs ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/11] glsl: Propagate explicit binding information from AST to IR.
On 17 July 2013 18:24, Kenneth Graunke wrote:
> Rather than creating a new "binding" field in ir_variable, we reuse
> constant_value since the linker code for handling uniform initializers
> uses that.
>
I'm uncomfortable with this. It's already a bit irregular that we use
constant_value for this purpose in handling uniform initializers (since the
value of a uniform initializer can be overridden using the GL API, and
hence isn't really constant), and we already have some ugly workaround code
to deal with that irregularity (see
ir_dereference_variable::constant_expression_value(), which has to have a
special case to ignore constant_value when looking at a uniform). In point
of fact, I'm worried that there may be bugs in opt_constant_variable.cpp,
because it doesn't seem to go to any effort to avoid trying to treat
uniforms with initializers as constants.
Re-using constant_value for bindings seems even more dangerous, since now
the types won't even match.
>
> Since UBOs and samplers can't otherwise have initializers/constant
> values, there shouldn't be a conflict.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/ast_to_hir.cpp | 7 +--
> src/glsl/ir.h | 8
> src/glsl/ir_clone.cpp | 1 +
> 3 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/src/glsl/ast_to_hir.cpp b/src/glsl/ast_to_hir.cpp
> index 4a04b60..f438b6d 100644
> --- a/src/glsl/ast_to_hir.cpp
> +++ b/src/glsl/ast_to_hir.cpp
> @@ -2158,8 +2158,11 @@ apply_type_qualifier_to_variable(const struct
> ast_type_qualifier *qual,
> "explicit index requires explicit location\n");
> }
>
> - if (qual->flags.q.explicit_binding)
> - validate_binding_qualifier(state, loc, var, qual);
> + if (qual->flags.q.explicit_binding &&
> + validate_binding_qualifier(state, loc, var, qual)) {
> + var->explicit_binding = true;
> + var->constant_value = new(state) ir_constant(qual->binding);
> + }
>
> /* Does the declaration use the deprecated 'attribute' or 'varying'
> * keywords?
> diff --git a/src/glsl/ir.h b/src/glsl/ir.h
> index 1f0dc09..46bdb38 100644
> --- a/src/glsl/ir.h
> +++ b/src/glsl/ir.h
> @@ -471,6 +471,14 @@ public:
> unsigned explicit_index:1;
>
> /**
> +* Was an initial binding explicitly set in the shader?
> +*
> +* If so, constant_value contains an integer ir_constant representing
> the
> +* initial binding point.
> +*/
> + unsigned explicit_binding:1;
> +
> + /**
> * Does this variable have an initializer?
> *
> * This is used by the linker to cross-validiate initializers of global
> diff --git a/src/glsl/ir_clone.cpp b/src/glsl/ir_clone.cpp
> index 5b42935..535f5ce 100644
> --- a/src/glsl/ir_clone.cpp
> +++ b/src/glsl/ir_clone.cpp
> @@ -55,6 +55,7 @@ ir_variable::clone(void *mem_ctx, struct hash_table *ht)
> const
> var->pixel_center_integer = this->pixel_center_integer;
> var->explicit_location = this->explicit_location;
> var->explicit_index = this->explicit_index;
> + var->explicit_binding = this->explicit_binding;
> var->has_initializer = this->has_initializer;
> var->depth_layout = this->depth_layout;
>
> --
> 1.8.3.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 02/14] glsl: Add a new ast_type_qualifier::has_storage() method.
On Mon, Jul 15, 2013 at 7:32 PM, Kenneth Graunke wrote: > This makes it easy to check if any storage qualifiers are set. > > XXX: I'm not sure if centroid should be in this or not Ken and I decided yesterday that it should not be. So, just squash your other patch into this. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/14] glsl: Handle most qualifier ordering in C code rather than the grammar.
On Mon, Jul 15, 2013 at 7:32 PM, Kenneth Graunke wrote:
> The GL_ARB_shading_language_420pack extension/GLSL 4.20 allow qualifiers
> to be specified in (basically) any order. In order to support this, we
> can't hardcode the ordering restrictions in the grammar.
>
> This patch alters the grammar to accept invariant, storage, layout, and
> interpolation qualifiers in any order, but adds C code to enforce the
> ordering requirements. In the 420pack case, we should be able to simply
> skip the error checks.
>
> As a bonus, this also lets us generate decent error messages, rather
> than Bison's awful "unexpected TOKEN" errors.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/glsl/glsl_parser.yy | 110
>
> 1 file changed, 92 insertions(+), 18 deletions(-)
>
> diff --git a/src/glsl/glsl_parser.yy b/src/glsl/glsl_parser.yy
> index b8f3df9..72bf560 100644
> --- a/src/glsl/glsl_parser.yy
> +++ b/src/glsl/glsl_parser.yy
> @@ -1314,34 +1314,108 @@ parameter_type_qualifier:
> ;
>
> type_qualifier:
> - storage_qualifier
> - | layout_qualifier
> - | layout_qualifier storage_qualifier
> + /* Single qualifiers */
> + INVARIANT
> {
> - $$ = $1;
> - $$.flags.i |= $2.flags.i;
> + memset(& $$, 0, sizeof($$));
> + $$.flags.q.invariant = 1;
> }
> + | storage_qualifier
> | interpolation_qualifier
> - | interpolation_qualifier storage_qualifier
> - {
> - $$ = $1;
> - $$.flags.i |= $2.flags.i;
> - }
> - | INVARIANT storage_qualifier
> + | layout_qualifier
> +
> + /* Multiple qualifiers:
> +* In GLSL 4.20, these can be specified in any order. In earlier
> versions,
> +* they appear in this order (see GLSL 1.50 section 4.7 & comments below):
> +*
> +*invariant interpolation storage precision ...or...
> +*layout storage precision
> +*
> +* Each qualifier's rule ensures that the accumulated qualifiers on the
> right
> +* side don't contain any that must appear on the left hand side.
> +* For example, when processing a storage qualifier, we check that there
> are
> +* no interpolation, layout, or invariant qualifiers to the right.
> +*/
> + | INVARIANT type_qualifier
> {
> + if ($2.flags.q.invariant)
> + _mesa_glsl_error(&@1, state, "Duplicate \"invariant\"
> qualifier.\n");
> +
> + if ($2.has_layout()) {
> + _mesa_glsl_error(&@1, state,
> + "\"invariant\" cannot be used with
> layout(...).\n");
> + }
> +
>$$ = $2;
>$$.flags.q.invariant = 1;
> }
> - | INVARIANT interpolation_qualifier storage_qualifier
> + | interpolation_qualifier type_qualifier
> + {
> + /* Section 4.3 of the GLSL 1.40 specification states:
> + * "...qualified with one of these interpolation qualifiers"
> + *
> + * GLSL 1.30 claims to allow "one or more", but insists that:
> + * "These interpolation qualifiers may only precede the qualifiers in,
> + * centroid in, out, or centroid out in a declaration."
> + *
> + * ...which means that e.g. smooth can't precede smooth, so there can
> be
> + * only one after all, and the 1.40 text is a clarification, not a
> change.
> + */
> + if ($2.has_interpolation())
> + _mesa_glsl_error(&@1, state, "Duplicate interpolation
> qualifier.\n");
> +
> + if ($2.has_layout()) {
> + _mesa_glsl_error(&@1, state, "Interpolation qualifiers cannot be
> used "
> + "with layout(...).\n");
> + }
> +
> + if ($2.flags.q.invariant) {
> + _mesa_glsl_error(&@1, state, "Interpolation qualifiers must come "
> + "after \"invariant\".\n");
> + }
> +
> + $$ = $1;
> + $$.flags.i |= $2.flags.i;
> + }
> + | layout_qualifier type_qualifier
> {
> - $$ = $2;
> - $$.flags.i |= $3.flags.i;
> - $$.flags.q.invariant = 1;
> + /* The GLSL 1.50 grammar indicates that a layout(...) declaration can
> be
> + * used standalone or immediately before a storage qualifier. It
> cannot
> + * be used with interpolation qualifiers or invariant. There does not
> + * appear to be any text indicating that it must come before the
> storage
> + * qualifier, but always seems to in examples.
> + */
> + if ($2.has_layout())
Should be
if (!state->ARB_shading_language_420pack_enable && $2.has_layout())
Since duplicate layout qualifiers are explicitly allowed.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 00/14] Qualifier ordering for 420pack
On Mon, Jul 15, 2013 at 7:32 PM, Kenneth Graunke wrote: > Hello! > > The GL_ARB_shading_language_420pack allows qualifiers to be specified in > a flexible order, which is nice now that there are so many different > qualifiers. Yet, we still need to support the old language semantics > which enforce a particular ordering as well. > > Previously, we handled the ordering requirements using the GLSL 1.50 > grammar rules. This obviously can't handle the flexible ordering, so > so I had to rewrite the grammar to allow qualifiers in any order, then > add C code to enforce the pre-4.20 ordering restrictions. > > No regressions observed on Piglit or ES3, though we need a bunch more > tests. A few extra are in the 'qualifiers' branch of ~kwg/piglit, though > I believe Matt is writing more. > > I'm hoping to land this before Thursday. With one more tiny feature, > we can enable 420pack for 9.2... > > Please review...sooner rather than later :) > > The series is available as the 'qualifiers' branch of ~kwg/mesa; if > applying from the mailing list, apply these first: > > glsl: Silence the last shift/reduce conflict warning in the grammar. > glsl: Fail the build if the grammar contains shift/reduce errors. > glsl: Fix absurd whitespace conventions in the parser. The series is Reviewed-by: Matt Turner with the two fixes folded in. The duplicate layout qualifier change should probably go in a different patch from the one I commented on. Piglit tests are on the list, and after reviewing your series I see some other things I should test. Thanks! Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] builtin_compiler/build: Avoid using libtool if cross compiling
On Tue, Jun 4, 2013 at 6:03 AM, Jonathan Liu wrote: > Adds the dependencies of builtin_compiler as sources when cross > compiling instead of using libtool to share compilation with src/glsl. > The builtin_compiler executable is built for the host when cross > compiling so it doesn't make sense to share compilation with src/glsl > built for the target in this case. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44618 > Signed-off-by: Jonathan Liu > --- Thanks, committed (finally). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gen_matypes: fix cross-compiling with gcc
On Mon, Feb 4, 2013 at 6:27 PM, Mike Frysinger wrote: > The current gen_matypes logic assumes that the host compiler will produce > information that is useful for the target compiler. Unfortunately, this > is not the case whenever cross-compiling. > > When we detect that we're cross-compiling and using GCC, use the target > compiler to produce assembly from the gen_matypes.c source, then process > it with a shell script to create a usable header. This is similar to how > the linux kernel creates its asm-offsets.c file. > > Signed-off-by: Mike Frysinger > --- Thanks, committed (finally). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] ax_prog_flex.m4: change grep syntax to accept e.g. flex.real
On Mon, Apr 15, 2013 at 1:46 PM, Andreas Oberritter wrote: > This is required in case a wrapper or symlink is used. This patch > has also been sent upstream, awaiting moderation. > > Signed-off-by: Andreas Oberritter > --- Thanks, committed (finally). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 44618] Cross-compilation broken by glsl builtin_compiler
https://bugs.freedesktop.org/show_bug.cgi?id=44618 Matt Turner changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #28 from Matt Turner --- Thanks! I've finally committed the patch. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 12/11] st/mesa: Enable the ARB_shading_language_420pack extension for 1.30+.
Reviewed-by: Marek Olšák
Marek
On Thu, Jul 18, 2013 at 8:51 PM, Kenneth Graunke wrote:
> Any driver that supports GLSL 1.30 should be able to handle this
> extension, as it's entirely implemented in the GLSL compiler.
>
> Signed-off-by: Kenneth Graunke
> ---
> src/mesa/state_tracker/st_extensions.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/src/mesa/state_tracker/st_extensions.c
> b/src/mesa/state_tracker/st_extensions.c
> index 32348ef..d019429 100644
> --- a/src/mesa/state_tracker/st_extensions.c
> +++ b/src/mesa/state_tracker/st_extensions.c
> @@ -615,6 +615,7 @@ void st_init_extensions(struct st_context *st)
>ctx->Extensions.ARB_shader_bit_encoding = GL_TRUE;
>ctx->Extensions.ARB_shading_language_packing = GL_TRUE;
>ctx->Extensions.OES_depth_texture_cube_map = GL_TRUE;
> + ctx->Extensions.ARB_shading_language_420pack = GL_TRUE;
> } else {
>/* Optional integer support for GLSL 1.2. */
>if (screen->get_shader_param(screen, PIPE_SHADER_VERTEX,
> --
> 1.8.3.3
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 11/11] i965: Enable the GL_ARB_shading_language_420pack extension.
On 17 July 2013 18:24, Kenneth Graunke wrote: > Everything is done. Every driver that supports 1.30 should enable this > extension. > > Signed-off-by: Kenneth Graunke > I've made comments on patches 3 and 5. We talked in person about clarifying the commit messages in patches 1 and 7. I don't think those clarifications are critical, so in any case those two patches get my reviewed-by. I don't feel qualified to review patches 8 and 10--they touch code in sampler and UBO land that I'm not sufficiently familiar with. I'm happy to give them an acked-by, though. The remainder (patches 2, 4, 6, 9, and 11) look great, and are: Reviewed-by: Paul Berry ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] R600: Expand VSELECT for all types
On Wed, Jul 17, 2013 at 09:46:43AM -0500, Aaron Watry wrote:
> 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 successfully run an int/int2/int4 min/max/clamp CL builtin test
> on my Pitcairn, so as far as I can tell, this is working correctly
> now.
>
Thanks for testing, I've pushed these patches.
> If we're concerned about the sign extension of boolean to 32-bit ints,
> I'd say that we should open a new bug for that.
>
Sounds good to me.
-Tom
>
> On Tue, Jul 16, 2013 at 8:39 PM, Tom Stellard wrote:
> > Hi,
> >
> > The attached three patches along with this one should fix VSELECT on SI
> > as well.
> >
> > -Tom
> >
> > On Tue, Jul 16, 2013 at 05:12:40PM -0500, Aaron Watry wrote:
> >> Looks good to me.
> >>
> >> I've tested on Cedar (HD5400) with no OpenCL regressions, but cannot
> >> test on SI because SETCC still causes issues (see
> >> https://bugs.freedesktop.org/show_bug.cgi?id=66175). Once SETCC is
> >> fixed for SI, we should probably add SI-CHECK lines to vselect.ll
> >>
> >> --Aaron
> >>
> >> On Tue, Jul 16, 2013 at 2:15 PM, Tom Stellard wrote:
> >> > From: Tom Stellard
> >> >
> >> > ---
> >> > lib/Target/R600/AMDGPUISelLowering.cpp | 3 +++
> >> > lib/Target/R600/R600ISelLowering.cpp | 3 ---
> >> > test/CodeGen/R600/vselect.ll | 30
> >> > ++
> >> > 3 files changed, 33 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/lib/Target/R600/AMDGPUISelLowering.cpp
> >> > b/lib/Target/R600/AMDGPUISelLowering.cpp
> >> > index 9891ad3..e93ddc4 100644
> >> > --- a/lib/Target/R600/AMDGPUISelLowering.cpp
> >> > +++ b/lib/Target/R600/AMDGPUISelLowering.cpp
> >> > @@ -77,6 +77,8 @@
> >> > AMDGPUTargetLowering::AMDGPUTargetLowering(TargetMachine &TM) :
> >> >setOperationAction(ISD::UDIV, MVT::i32, Expand);
> >> >setOperationAction(ISD::UDIVREM, MVT::i32, Custom);
> >> >setOperationAction(ISD::UREM, MVT::i32, Expand);
> >> > + setOperationAction(ISD::VSELECT, MVT::v2f32, Expand);
> >> > + setOperationAction(ISD::VSELECT, MVT::v4f32, Expand);
> >> >
> >> >int types[] = {
> >> > (int)MVT::v2i32,
> >> > @@ -97,6 +99,7 @@
> >> > AMDGPUTargetLowering::AMDGPUTargetLowering(TargetMachine &TM) :
> >> > setOperationAction(ISD::SUB, VT, Expand);
> >> > setOperationAction(ISD::UDIV, VT, Expand);
> >> > setOperationAction(ISD::UREM, VT, Expand);
> >> > +setOperationAction(ISD::VSELECT, VT, Expand);
> >> > setOperationAction(ISD::XOR, VT, Expand);
> >> >}
> >> > }
> >> > diff --git a/lib/Target/R600/R600ISelLowering.cpp
> >> > b/lib/Target/R600/R600ISelLowering.cpp
> >> > index 7aef08a..1067b38 100644
> >> > --- a/lib/Target/R600/R600ISelLowering.cpp
> >> > +++ b/lib/Target/R600/R600ISelLowering.cpp
> >> > @@ -67,9 +67,6 @@ R600TargetLowering::R600TargetLowering(TargetMachine
> >> > &TM) :
> >> >setOperationAction(ISD::SELECT, MVT::i32, Custom);
> >> >setOperationAction(ISD::SELECT, MVT::f32, Custom);
> >> >
> >> > - setOperationAction(ISD::VSELECT, MVT::v4i32, Expand);
> >> > - setOperationAction(ISD::VSELECT, MVT::v2i32, Expand);
> >> > -
> >> >// Legalize loads and stores to the private address space.
> >> >setOperationAction(ISD::LOAD, MVT::i32, Custom);
> >> >setOperationAction(ISD::LOAD, MVT::v2i32, Expand);
> >> > diff --git a/test/CodeGen/R600/vselect.ll b/test/CodeGen/R600/vselect.ll
> >> > index 3f08cec..79d896b 100644
> >> > --- a/test/CodeGen/R600/vselect.ll
> >> > +++ b/test/CodeGen/R600/vselect.ll
> >> > @@ -14,6 +14,20 @@ entry:
> >> >ret void
> >> > }
> >> >
> >> > +;EG-CHECK: @test_select_v2f32
> >> > +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW],
> >> > T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> >> > +;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW],
> >> > T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> >> > +
> >> > +define void @test_select_v2f32(<2 x float> addrspace(1)* %out, <2 x
> >> > float> addrspace(1)* %in0, <2 x float> addrspace(1)* %in1) {
> >> > +entry:
> >> > + %0 = load <2 x float> addrspace(1)* %in0
> >> > + %1 = load <2 x float> addrspace(1)* %in1
> >> > + %cmp = fcmp one <2 x float> %0, %1
> >> > + %result = select <2 x i1> %cmp, <2 x float> %0, <2 x float> %1
> >> > + store <2 x float> %result, <2 x float> addrspace(1)* %out
> >> > + ret void
> >> > +}
> >> > +
> >> > ;EG-CHECK: @test_select_v4i32
> >> > ;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW],
> >> > T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> >> > ;EG-CHECK: CNDE_INT {{\*? *}}T{{[0-9]+\.[XYZW], PV\.[XYZW],
> >> > T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
> >> > @@ -29,3 +43,19 @@ entry:
> >> >store <4 x i32> %result, <4 x i32> addrspace(1)* %out
> >> >ret void
> >> > }
> >> > +
> >> > +;EG-CHECK
[Mesa-dev] [PATCH 0/5] i965/hsw: Use L3 with MOCS
Nothing was landing in the L3 cache because we neglected to set the MOCS L3
bit. This fixes that and puts a bunch of stuff into L3.
Improves Xonotic 1920x1080 by +5.68% on Haswell Mobile GT2.
No Piglit regressions.
This series depends on Ken's recent patches and lives on my hsw-mocs-l3-v04
branc.
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 {
name: pts/xonotic-1.3.1 1920x1080 quality=high
delta: +5.68152% +/- 0.653452(student's t) at 95% confidence
n: 3
pooled-s: 0.288297
mesa-base: master-00d32cd
}
Chad Versace (5):
i965/hsw: Change L3 MOCS of STATE_BASE_ADDRESS
i965/hsw: Change L3 MOCS of 3DSTATE_VERTEX_BUFFERS
i965/hsw: Change L3 MOCS of SURFACE_STATE
i965/hsw: Change L3 MOCS of 3DSTATE_CONSTANT_VS/PS
i965/hsw: Change L3 MOCS for depth, hiz, and stencil
src/mesa/drivers/dri/i965/brw_draw_upload.c | 3 +++
src/mesa/drivers/dri/i965/brw_misc_state.c| 9 -
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 12 +++-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 14 ++
src/mesa/drivers/dri/i965/gen7_misc_state.c | 7 +--
src/mesa/drivers/dri/i965/gen7_vs_state.c | 4 +++-
src/mesa/drivers/dri/i965/gen7_wm_state.c | 4 +++-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 6 +-
8 files changed, 48 insertions(+), 11 deletions(-)
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/5] i965/hsw: Change L3 MOCS of STATE_BASE_ADDRESS
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_misc_state.c | 9 -
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 9 -
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_misc_state.c
b/src/mesa/drivers/dri/i965/brw_misc_state.c
index 0ab1e76..cfd5acf 100644
--- a/src/mesa/drivers/dri/i965/brw_misc_state.c
+++ b/src/mesa/drivers/dri/i965/brw_misc_state.c
@@ -1023,13 +1023,20 @@ static void upload_state_base_address( struct
brw_context *brw )
*/
if (brw->gen >= 6) {
+ /* The MOCS of the STATE_BASE_ADDRESS applies to stateless buffers
+ * accessed by the data port, indirect state objects, and shader kernels.
+ * See the PRM, Section "Memory Object Control State".
+ */
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
+
if (brw->gen == 6)
intel_emit_post_sync_nonzero_flush(brw);
BEGIN_BATCH(10);
OUT_BATCH(CMD_STATE_BASE_ADDRESS << 16 | (10 - 2));
/* General state base address: stateless DP read/write requests */
- OUT_BATCH(1);
+ OUT_BATCH(mocs << 8 |
+ 1 /*GeneralStateBaseAddressModifyEnable*/);
/* Surface state base address:
* BINDING_TABLE_STATE
* SURFACE_STATE
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 8056bf5..fd220f6 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -74,9 +74,16 @@ void
gen6_blorp_emit_state_base_address(struct brw_context *brw,
const brw_blorp_params *params)
{
+ /* The MOCS of the STATE_BASE_ADDRESS applies to stateless buffers accessed
+* by the data port, indirect state objects, and shader kernels. See the
+* PRM, Section "Memory Object Control State".
+*/
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
+
BEGIN_BATCH(10);
OUT_BATCH(CMD_STATE_BASE_ADDRESS << 16 | (10 - 2));
- OUT_BATCH(1); /* GeneralStateBaseAddressModifyEnable */
+ OUT_BATCH(mocs << 8 |
+ 1 /* GeneralStateBaseAddressModifyEnable */);
/* SurfaceStateBaseAddress */
OUT_RELOC(brw->batch.bo, I915_GEM_DOMAIN_SAMPLER, 0, 1);
/* DynamicStateBaseAddress */
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/5] i965/hsw: Change L3 MOCS of 3DSTATE_VERTEX_BUFFERS
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/brw_draw_upload.c | 3 +++
src/mesa/drivers/dri/i965/gen6_blorp.cpp| 3 +++
2 files changed, 6 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c
b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index 2952027..897e733 100644
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -658,6 +658,9 @@ static void brw_emit_vertices(struct brw_context *brw)
if (brw->gen >= 7)
dw0 |= GEN7_VB0_ADDRESS_MODIFYENABLE;
+if (brw->is_haswell)
+ dw0 |= GEN7_MOCS_L3 << 16;
+
OUT_BATCH(dw0 | (buffer->stride << BRW_VB0_PITCH_SHIFT));
OUT_RELOC(buffer->bo, I915_GEM_DOMAIN_VERTEX, 0, buffer->offset);
if (brw->gen >= 5) {
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index fd220f6..904568c 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -170,6 +170,9 @@ gen6_blorp_emit_vertices(struct brw_context *brw,
if (brw->gen >= 7)
dw0 |= GEN7_VB0_ADDRESS_MODIFYENABLE;
+ if (brw->is_haswell)
+ dw0 |= GEN7_MOCS_L3 << 16;
+
BEGIN_BATCH(batch_length);
OUT_BATCH((_3DSTATE_VERTEX_BUFFERS << 16) | (batch_length - 2));
OUT_BATCH(dw0);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/5] i965/hsw: Change L3 MOCS of SURFACE_STATE
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 4 +++-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 6 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index fbdd2be..0c08584 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -143,6 +143,7 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
*/
struct intel_region *region = surface->mt->region;
uint32_t tile_x, tile_y;
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
uint32_t tiling = surface->map_stencil_as_y_tiled
? I915_TILING_Y : region->tiling;
@@ -175,7 +176,8 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
assert(tile_x % 4 == 0);
assert(tile_y % 2 == 0);
surf[5] = SET_FIELD(tile_x / 4, BRW_SURFACE_X_OFFSET) |
- SET_FIELD(tile_y / 2, BRW_SURFACE_Y_OFFSET);
+ SET_FIELD(tile_y / 2, BRW_SURFACE_Y_OFFSET) |
+ SET_FIELD(mocs, GEN7_SURFACE_MOCS);
surf[2] = SET_FIELD(width - 1, GEN7_SURFACE_WIDTH) |
SET_FIELD(height - 1, GEN7_SURFACE_HEIGHT);
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
index fe97803..34cf63b 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -286,6 +286,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
struct gl_texture_image *firstImage = tObj->Image[0][tObj->BaseLevel];
struct gl_sampler_object *sampler = _mesa_get_samplerobj(ctx, unit);
uint32_t tile_x, tile_y;
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
if (tObj->Target == GL_TEXTURE_BUFFER) {
gen7_update_buffer_texture_surface(ctx, unit, binding_table, surf_index);
@@ -334,6 +335,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
*/
surf[5] = ((tile_x / 4) << BRW_SURFACE_X_OFFSET_SHIFT |
(tile_y / 2) << BRW_SURFACE_Y_OFFSET_SHIFT |
+ SET_FIELD(mocs, GEN7_SURFACE_MOCS) |
/* mip count */
(intelObj->_MaxLevel - tObj->BaseLevel));
@@ -512,6 +514,7 @@ gen7_update_renderbuffer_surface(struct brw_context *brw,
bool is_array = false;
int depth = MAX2(rb->Depth, 1);
int min_array_element;
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
GLenum gl_target = rb->TexImage ?
rb->TexImage->TexObject->Target : GL_TEXTURE_2D;
@@ -571,7 +574,8 @@ gen7_update_renderbuffer_surface(struct brw_context *brw,
assert(brw->has_surface_tile_offset);
- surf[5] = irb->mt_level - irb->mt->first_level;
+ surf[5] = SET_FIELD(mocs, GEN7_SURFACE_MOCS) |
+ (irb->mt_level - irb->mt->first_level);
surf[2] = SET_FIELD(irb->mt->logical_width0 - 1, GEN7_SURFACE_WIDTH) |
SET_FIELD(irb->mt->logical_height0 - 1, GEN7_SURFACE_HEIGHT);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/5] i965/hsw: Change L3 MOCS of 3DSTATE_CONSTANT_VS/PS
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
In blorp, change only the PS packet, because the VS packet is disabled.
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 4 +++-
src/mesa/drivers/dri/i965/gen7_vs_state.c | 4 +++-
src/mesa/drivers/dri/i965/gen7_wm_state.c | 4 +++-
3 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 0c08584..0fa352a 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -616,6 +616,8 @@ gen7_blorp_emit_constant_ps(struct brw_context *brw,
const brw_blorp_params *params,
uint32_t wm_push_const_offset)
{
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
+
/* Make sure the push constants fill an exact integer number of
* registers.
*/
@@ -630,7 +632,7 @@ gen7_blorp_emit_constant_ps(struct brw_context *brw,
(7 - 2));
OUT_BATCH(BRW_BLORP_NUM_PUSH_CONST_REGS);
OUT_BATCH(0);
- OUT_BATCH(wm_push_const_offset);
+ OUT_BATCH(wm_push_const_offset | mocs);
OUT_BATCH(0);
OUT_BATCH(0);
OUT_BATCH(0);
diff --git a/src/mesa/drivers/dri/i965/gen7_vs_state.c
b/src/mesa/drivers/dri/i965/gen7_vs_state.c
index 7369a9c..0340da4 100644
--- a/src/mesa/drivers/dri/i965/gen7_vs_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_vs_state.c
@@ -63,6 +63,8 @@ upload_vs_state(struct brw_context *brw)
OUT_BATCH(0);
ADVANCE_BATCH();
} else {
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
+
BEGIN_BATCH(7);
OUT_BATCH(_3DSTATE_CONSTANT_VS << 16 | (7 - 2));
OUT_BATCH(brw->vs.push_const_size);
@@ -70,7 +72,7 @@ upload_vs_state(struct brw_context *brw)
/* Pointer to the VS constant buffer. Covered by the set of
* state flags from gen6_prepare_wm_contants
*/
- OUT_BATCH(brw->vs.push_const_offset);
+ OUT_BATCH(brw->vs.push_const_offset | mocs);
OUT_BATCH(0);
OUT_BATCH(0);
OUT_BATCH(0);
diff --git a/src/mesa/drivers/dri/i965/gen7_wm_state.c
b/src/mesa/drivers/dri/i965/gen7_wm_state.c
index 8f90371..1bc6e2e 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_state.c
@@ -141,6 +141,8 @@ upload_ps_state(struct brw_context *brw)
OUT_BATCH(0);
ADVANCE_BATCH();
} else {
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
+
BEGIN_BATCH(7);
OUT_BATCH(_3DSTATE_CONSTANT_PS << 16 | (7 - 2));
@@ -150,7 +152,7 @@ upload_ps_state(struct brw_context *brw)
/* Pointer to the WM constant buffer. Covered by the set of
* state flags from gen6_upload_wm_push_constants.
*/
- OUT_BATCH(brw->wm.push_const_offset);
+ OUT_BATCH(brw->wm.push_const_offset | mocs);
OUT_BATCH(0);
OUT_BATCH(0);
OUT_BATCH(0);
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/5] i965/hsw: Change L3 MOCS for depth, hiz, and stencil
Change from "not cacheable" to "cacheable" in L3.
Do so for the draw upload path and blorp.
CC: Kenneth Graunke
Signed-off-by: Chad Versace
---
src/mesa/drivers/dri/i965/gen7_blorp.cpp| 6 --
src/mesa/drivers/dri/i965/gen7_misc_state.c | 7 +--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 0fa352a..71a5a30 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -662,6 +662,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
uint32_t draw_x = params->depth.x_offset;
uint32_t draw_y = params->depth.y_offset;
uint32_t tile_mask_x, tile_mask_y;
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
brw_get_depthstencil_tile_masks(params->depth.mt,
params->depth.level,
@@ -713,7 +714,7 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
offset);
OUT_BATCH((params->depth.width + tile_x - 1) << 4 |
(params->depth.height + tile_y - 1) << 18);
- OUT_BATCH(0);
+ OUT_BATCH(mocs);
OUT_BATCH(tile_x |
tile_y << 16);
OUT_BATCH(0);
@@ -730,7 +731,8 @@ gen7_blorp_emit_depth_stencil_config(struct brw_context
*brw,
BEGIN_BATCH(3);
OUT_BATCH((GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16) | (3 - 2));
- OUT_BATCH(hiz_region->pitch - 1);
+ OUT_BATCH((mocs << 25) |
+(hiz_region->pitch - 1));
OUT_RELOC(hiz_region->bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
hiz_offset);
diff --git a/src/mesa/drivers/dri/i965/gen7_misc_state.c
b/src/mesa/drivers/dri/i965/gen7_misc_state.c
index 7f61881..7d63b2e 100644
--- a/src/mesa/drivers/dri/i965/gen7_misc_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_misc_state.c
@@ -40,6 +40,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
uint32_t tile_x, uint32_t tile_y)
{
struct gl_context *ctx = &brw->ctx;
+ uint8_t mocs = brw->is_haswell ? GEN7_MOCS_L3 : 0;
intel_emit_depth_stall_flushes(brw);
@@ -63,7 +64,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
OUT_BATCH(((width + tile_x - 1) << 4) |
((height + tile_y - 1) << 18));
- OUT_BATCH(0);
+ OUT_BATCH(mocs);
OUT_BATCH(tile_x | (tile_y << 16));
OUT_BATCH(0);
ADVANCE_BATCH();
@@ -78,7 +79,8 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
struct intel_mipmap_tree *hiz_mt = depth_mt->hiz_mt;
BEGIN_BATCH(3);
OUT_BATCH(GEN7_3DSTATE_HIER_DEPTH_BUFFER << 16 | (3 - 2));
- OUT_BATCH(hiz_mt->region->pitch - 1);
+ OUT_BATCH((mocs << 25) |
+(hiz_mt->region->pitch - 1));
OUT_RELOC(hiz_mt->region->bo,
I915_GEM_DOMAIN_RENDER,
I915_GEM_DOMAIN_RENDER,
@@ -108,6 +110,7 @@ gen7_emit_depth_stencil_hiz(struct brw_context *brw,
* same text, and experiments indicate that this is necessary.
*/
OUT_BATCH(enabled |
+mocs << 25 |
(2 * stencil_mt->region->pitch - 1));
OUT_RELOC(stencil_mt->region->bo,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER,
--
1.8.3.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/10] Float fbconfigs frontend patch [2/3] Creation of dummy X pixmap associated with float buffer.
On 07/17/2013 04:49 AM, Tomasz Lis wrote:
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 buffers,
but even then, there wouldn't be any point in allocating full-size associated
pixmap which can never be used.
I'm not sure this is correct. I want to do some more research and play
around with some other implementations. I've pushed all of the series
(with some changes) except this patch. Since this would qualify as a
bug fix, this can get cherry picked to the 9.2 branch.
Signed-off-by: Tomasz Lis
---
src/glx/glx_pbuffer.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/src/glx/glx_pbuffer.c b/src/glx/glx_pbuffer.c
index f11305a..67776c4 100644
--- a/src/glx/glx_pbuffer.c
+++ b/src/glx/glx_pbuffer.c
@@ -554,8 +554,23 @@ CreatePbuffer(Display * dpy, struct glx_config *config,
UnlockDisplay(dpy);
SyncHandle();
- pixmap = XCreatePixmap(dpy, RootWindow(dpy, config->screen),
- width, height, config->rgbBits);
+ /* From SGIX_pbuffer spec:
+* GLXPbuffers are equivalent to GLXPixmaps with the following exceptions:
+* There is no associated X pixmap. Also, since a GLXPbuffer is a GLX
+* resource, it may not be possible to render to it using X or an
+* X extension other than GLX.
+*/
+ if (config->floatMode) {
+ /* There are no float X pixmaps - create a dummy one, with 1 BPP.
+* The 1 BPP is a special value which disables BPP verification
+* in XServer. */
+ pixmap = XCreatePixmap(dpy, RootWindow(dpy, config->screen),
+ width, height, 1);
+ } else {
+ /* If it is possible to associate an X pixmap, do it. */
+ pixmap = XCreatePixmap(dpy, RootWindow(dpy, config->screen),
+ width, height, config->rgbBits);
+ }
if (!CreateDRIDrawable(dpy, config, pixmap, id, attrib_list, i)) {
CARD32 o = glx_1_3 ? X_GLXDestroyPbuffer :
X_GLXvop_DestroyGLXPbufferSGIX;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/5] i965/hsw: Use L3 with MOCS
Patches 2-5 are committed, with Ken's r-b.
Patch 1 is blocked by concerns from Ken. The patch doesn't
do what it claims to do. I'll resubmit it later, but let's not
block the 9.2 branch on it.
On 07/18/2013 03:00 PM, Chad Versace wrote:
Nothing was landing in the L3 cache because we neglected to set the MOCS L3
bit. This fixes that and puts a bunch of stuff into L3.
Improves Xonotic 1920x1080 by +5.68% on Haswell Mobile GT2.
No Piglit regressions.
This series depends on Ken's recent patches and lives on my hsw-mocs-l3-v04
branc.
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 {
name: pts/xonotic-1.3.1 1920x1080 quality=high
delta: +5.68152% +/- 0.653452(student's t) at 95% confidence
n: 3
pooled-s: 0.288297
mesa-base: master-00d32cd
}
Chad Versace (5):
i965/hsw: Change L3 MOCS of STATE_BASE_ADDRESS
i965/hsw: Change L3 MOCS of 3DSTATE_VERTEX_BUFFERS
i965/hsw: Change L3 MOCS of SURFACE_STATE
i965/hsw: Change L3 MOCS of 3DSTATE_CONSTANT_VS/PS
i965/hsw: Change L3 MOCS for depth, hiz, and stencil
src/mesa/drivers/dri/i965/brw_draw_upload.c | 3 +++
src/mesa/drivers/dri/i965/brw_misc_state.c| 9 -
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 12 +++-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 14 ++
src/mesa/drivers/dri/i965/gen7_misc_state.c | 7 +--
src/mesa/drivers/dri/i965/gen7_vs_state.c | 4 +++-
src/mesa/drivers/dri/i965/gen7_wm_state.c | 4 +++-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 6 +-
8 files changed, 48 insertions(+), 11 deletions(-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Disable GL_EXT_framebuffer_object in core profiles and OpenGL 3.1
From: Ian Romanick
GL_EXT_framebuffer_object differs from GL_ARB_framebuffer_object in ways
that we can't and don't implement in core profiles. Exposing it is a
lie, so we shouldn't do that.
It's possible the some other GL_EXT_framebuffer_* extensions should be
disabled, but it's not quite so clear cut.
Signed-off-by: Ian Romanick
---
src/mesa/main/extensions.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index e0428c6..4e46cf0 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -184,7 +184,7 @@ static const struct extension extension_table[] = {
{ "GL_EXT_framebuffer_blit",o(EXT_framebuffer_blit),
GL, 2005 },
{ "GL_EXT_framebuffer_multisample",
o(EXT_framebuffer_multisample), GL, 2005 },
{ "GL_EXT_framebuffer_multisample_blit_scaled",
o(EXT_framebuffer_multisample_blit_scaled), GL, 2011 },
- { "GL_EXT_framebuffer_object", o(dummy_true),
GL, 2000 },
+ { "GL_EXT_framebuffer_object", o(dummy_true),
GLL,2000 },
{ "GL_EXT_framebuffer_sRGB",o(EXT_framebuffer_sRGB),
GL, 1998 },
{ "GL_EXT_gpu_program_parameters",
o(EXT_gpu_program_parameters), GLL,2006 },
{ "GL_EXT_gpu_shader4", o(EXT_gpu_shader4),
GL, 2006 },
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 9.2 branch created
The 9.2 branch is now live. From this point on, the branch will be treated just like any other stable release branch. Please remember to CC any patches destined for the release to mesa-stable. The current target date for the release is August 22nd. We'll start having release candidates weekly starting August 1st. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Disable GL_EXT_framebuffer_object in core profiles and OpenGL 3.1
On 07/18/2013 05:05 PM, Ian Romanick wrote:
From: Ian Romanick
GL_EXT_framebuffer_object differs from GL_ARB_framebuffer_object in ways
that we can't and don't implement in core profiles. Exposing it is a
lie, so we shouldn't do that.
It's possible the some other GL_EXT_framebuffer_* extensions should be
disabled, but it's not quite so clear cut.
Signed-off-by: Ian Romanick
---
src/mesa/main/extensions.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/mesa/main/extensions.c b/src/mesa/main/extensions.c
index e0428c6..4e46cf0 100644
--- a/src/mesa/main/extensions.c
+++ b/src/mesa/main/extensions.c
@@ -184,7 +184,7 @@ static const struct extension extension_table[] = {
{ "GL_EXT_framebuffer_blit",o(EXT_framebuffer_blit),
GL, 2005 },
{ "GL_EXT_framebuffer_multisample",
o(EXT_framebuffer_multisample), GL, 2005 },
{ "GL_EXT_framebuffer_multisample_blit_scaled",
o(EXT_framebuffer_multisample_blit_scaled), GL, 2011 },
- { "GL_EXT_framebuffer_object", o(dummy_true),
GL, 2000 },
+ { "GL_EXT_framebuffer_object", o(dummy_true),
GLL,2000 },
{ "GL_EXT_framebuffer_sRGB",o(EXT_framebuffer_sRGB),
GL, 1998 },
{ "GL_EXT_gpu_program_parameters",
o(EXT_gpu_program_parameters), GLL,2006 },
{ "GL_EXT_gpu_shader4", o(EXT_gpu_shader4),
GL, 2006 },
Reviewed-by: Kenneth Graunke
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
