Re: [Mesa-dev] [PATCH 01/12] i965: Assign PS kernel start pointers when we decide which kernels to use
On Mon, Aug 11, 2014 at 10:40:25PM -0700, Kenneth Graunke wrote:
On Monday, August 11, 2014 07:53:11 PM Ben Widawsky wrote:
On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
[snip]
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index 3d6d7f0..f58d49c 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -134,7 +134,7 @@ static void
upload_ps_state(struct brw_context *brw)
{
struct gl_context *ctx = brw-ctx;
- uint32_t dw3 = 0, dw6 = 0, dw7 = 0;
+ uint32_t dw3 = 0, dw6 = 0, dw7 = 0, ksp0, ksp2 = 0;
Should ksp0 and ksp2 be uint64_t? I realize the current code is broken
anyway. (/me makes note for no reloc branch).
It's not necessary. The kernel start pointers are relative to Instruction
State Base Address, which we set to the start of a buffer that contains all
of the shader programs. That buffer isn't going to be bigger than 4GB, so
the offsets will always fit in 32 bits.
--Ken
I was mostly thinking of a future with the ability to OUT_BATCH64, or
OUT_BATCH_KERNEL the pointer (and as a readability thing). I agree it
doesn't have any real impact.
One of the paths I was considering with the no reloc thing was to always
set the state base addresses to be 0 (for everything), and in that case
the kernel start pointer very well could be 4GB. There are other ways
to solve that problem of course, but I felt compelled to justify.
--
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/12] i965: Assign PS kernel start pointers when we decide which kernels to use
On Mon, Aug 11, 2014 at 11:18:36PM -0700, Ben Widawsky wrote:
On Mon, Aug 11, 2014 at 10:40:25PM -0700, Kenneth Graunke wrote:
On Monday, August 11, 2014 07:53:11 PM Ben Widawsky wrote:
On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
[snip]
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index 3d6d7f0..f58d49c 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -134,7 +134,7 @@ static void
upload_ps_state(struct brw_context *brw)
{
struct gl_context *ctx = brw-ctx;
- uint32_t dw3 = 0, dw6 = 0, dw7 = 0;
+ uint32_t dw3 = 0, dw6 = 0, dw7 = 0, ksp0, ksp2 = 0;
Should ksp0 and ksp2 be uint64_t? I realize the current code is broken
anyway. (/me makes note for no reloc branch).
It's not necessary. The kernel start pointers are relative to Instruction
State Base Address, which we set to the start of a buffer that contains all
of the shader programs. That buffer isn't going to be bigger than 4GB, so
the offsets will always fit in 32 bits.
--Ken
I was mostly thinking of a future with the ability to OUT_BATCH64, or
OUT_BATCH_KERNEL the pointer (and as a readability thing). I agree it
doesn't have any real impact.
One of the paths I was considering with the no reloc thing was to always
set the state base addresses to be 0 (for everything), and in that case
the kernel start pointer very well could be 4GB. There are other ways
to solve that problem of course, but I felt compelled to justify.
On further consideration, even if you malloc the shader and use that
address, 4G is a possibility.
--
Ben Widawsky, Intel Open Source Technology Center
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] mesa: update mangle script to force locale
On 12.08.2014 04:07, Ilia Mirkin wrote: The sorting is different with LC_ALL=C. To avoid different people's locale settings from fighting, force it to the one that was used to generate the current file. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Not sure if there's a better way of doing it... perhaps forcing to C and just regenerating with that may be better? Not sure. I think so, the en_US.utf8 locale may not be available everywhere (in fact, it currently isn't on this system). -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] radeonsi: fix buffer invalidation of unbound texture buffer objects
On 12.08.2014 05:46, Marek Olšák wrote: From: Marek Olšák marek.ol...@amd.com This maintains a list of all TBOs in a pipe_context. Reviewed-by: Michel Dänzer michel.daen...@amd.com -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] i965: Broadwell using brw_eu_emit.c, part 2
I obviously can't test on Broadwell, but via eyeballs only: For the series: Reviewed-by: Chris Forbes chr...@ijw.co.nz On Tue, Aug 12, 2014 at 5:18 PM, Kenneth Graunke kenn...@whitecape.org wrote: Hello, This series finishes getting Broadwell to use brw_eu_emit.c, and finally kills off gen8_*_generator.* and gen8_instruction.*. The diffstat is quite encouraging: 16 files changed, 147 insertions(+), 4152 deletions(-) While doing this work, I've been diffing the assembly generated via both methods across an entire Piglit run. Because of this, I was able to find a bunch of bugs in both generators, which was really useful. I've fixed those before unifying the two generators, and Cc'd stable. As is, this series doesn't get the two generating identical assembly. There are a bunch of small differences that shouldn't matter, and some compaction-related optimizations Matt did in the brw_eu_emit.c code that I never did in the Gen8 code. But, we want those - if I wanted to have zero differences, I'd disable them on gen = 8, throw the switch, and then immediately revert those changes. But it's pretty close. This series is available as the 'kill-generators' branch of git://people.freedesktop.org/~kwg/mesa/ The 'kill-generators-zerodiff' branch is also available, and has zero differences in the generated assembly. I'm not proposing to upstream those, but people can at least see the remaining differences. Patch 11 also improves performance of Trine 2 on Haswell by 45%, so... that's always nice, right? :) --Ken ___ 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/11] mesa: Add a new function for getting the nonconst sampler array index
Landed patches 1 2 to avoid holding up the nouveau enabling of this
feature while waiting for review on the i965 bits.
On Sun, Aug 10, 2014 at 2:22 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Sat, Aug 9, 2014 at 10:14 PM, Chris Forbes chr...@ijw.co.nz wrote:
If the array index is not a constant expression, the existing support
will assume a zero offset (giving us the sampler index of the base of
the array).
For dynamically uniform indexing of sampler arrays, we need both that
and the indexing expression.
Signed-off-by: Chris Forbes chr...@ijw.co.nz
Patches 1-2 are
Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
---
src/mesa/program/sampler.cpp | 11 +++
src/mesa/program/sampler.h | 3 +++
2 files changed, 14 insertions(+)
diff --git a/src/mesa/program/sampler.cpp b/src/mesa/program/sampler.cpp
index e6532be..29a5408 100644
--- a/src/mesa/program/sampler.cpp
+++ b/src/mesa/program/sampler.cpp
@@ -134,3 +134,14 @@ _mesa_get_sampler_uniform_value(class ir_dereference
*sampler,
return shader_program-UniformStorage[location].sampler[shader].index +
getname.offset;
}
+
+
+extern C class ir_rvalue *
+_mesa_get_sampler_array_nonconst_index(class ir_dereference *sampler)
+{
+ ir_dereference_array *deref_arr = sampler-as_dereference_array();
+ if (!deref_arr || deref_arr-array_index-as_constant())
+ return NULL;
+
+ return deref_arr-array_index;
+}
diff --git a/src/mesa/program/sampler.h b/src/mesa/program/sampler.h
index 22467e9..8b7c3b6 100644
--- a/src/mesa/program/sampler.h
+++ b/src/mesa/program/sampler.h
@@ -27,3 +27,6 @@ int
_mesa_get_sampler_uniform_value(class ir_dereference *sampler,
struct gl_shader_program *shader_program,
const struct gl_program *prog);
+
+class ir_rvalue *
+_mesa_get_sampler_array_nonconst_index(class ir_dereference *sampler);
--
2.0.4
___
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] [Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680
--- Comment #17 from Eugene ken20...@ukr.net ---
Yeah, and not the only one, because I had to run 'continue' several times. But
when crash after firefox closing happend I still could not run bt ('no stack'
reply on my 'bt' try):
Starting program: /usr/lib/firefox/firefox
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
[New Thread 0x7fffe9be4700 (LWP 4433)]
[Thread 0x7fffe9be4700 (LWP 4433) exited]
[New Thread 0x7fffe9be4700 (LWP 4436)]
[New Thread 0x7fffe2eff700 (LWP 4437)]
[New Thread 0x7fffe1ee6700 (LWP 4438)]
[New Thread 0x7fffe16e5700 (LWP 4439)]
[New Thread 0x7fffe0934700 (LWP 4440)]
[New Thread 0x7fffdebff700 (LWP 4443)]
[New Thread 0x7fffde3fe700 (LWP )]
[New Thread 0x7fffe3030700 (LWP 4445)]
[New Thread 0x7fffdd4ff700 (LWP 4446)]
[New Thread 0x7fffdc6ff700 (LWP 4447)]
[New Thread 0x7fffe0ee4700 (LWP 4448)]
[New Thread 0x7fffddbfd700 (LWP 4449)]
[New Thread 0x7fffdccfe700 (LWP 4450)]
[New Thread 0x7fffdbefe700 (LWP 4451)]
[New Thread 0x7fffc15ff700 (LWP 4452)]
[New Thread 0x7fffc07ff700 (LWP 4454)]
[New Thread 0x7fffc01ff700 (LWP 4455)]
[New Thread 0x7fffbf6ff700 (LWP 4456)]
[New Thread 0x7fffbeefe700 (LWP 4457)]
[New Thread 0x7fffbe6fd700 (LWP 4458)]
[New Thread 0x7fffbdbff700 (LWP 4459)]
[New Thread 0x7fffbd3fe700 (LWP 4460)]
[Thread 0x7fffdc6ff700 (LWP 4447) exited]
[Thread 0x7fffbe6fd700 (LWP 4458) exited]
[Thread 0x7fffbf6ff700 (LWP 4456) exited]
[New Thread 0x7fffbc9ff700 (LWP 4461)]
[New Thread 0x7fffbc1fe700 (LWP 4462)]
[Thread 0x7fffbeefe700 (LWP 4457) exited]
[New Thread 0x7fffdc6ff700 (LWP 4463)]
[New Thread 0x7fffbe6fd700 (LWP 4464)]
[New Thread 0x7fffbeefe700 (LWP 4465)]
[New Thread 0x7fffbf6ff700 (LWP 4466)]
[New Thread 0x7fffbb9fd700 (LWP 4467)]
[Thread 0x7fffbe6fd700 (LWP 4464) exited]
[Thread 0x7fffbc1fe700 (LWP 4462) exited]
[Thread 0x7fffbb9fd700 (LWP 4467) exited]
[Thread 0x7fffbf6ff700 (LWP 4466) exited]
[Thread 0x7fffbeefe700 (LWP 4465) exited]
[New Thread 0x7fffbe6fd700 (LWP 4468)]
[Thread 0x7fffdc6ff700 (LWP 4463) exited]
[New Thread 0x7fffdc6ff700 (LWP 4469)]
[Thread 0x7fffbe6fd700 (LWP 4468) exited]
[New Thread 0x7fffbe6fd700 (LWP 4470)]
[Thread 0x7fffdc6ff700 (LWP 4469) exited]
[New Thread 0x7fffdc6ff700 (LWP 4471)]
[Thread 0x7fffdc6ff700 (LWP 4471) exited]
[New Thread 0x7fffdc6ff700 (LWP 4472)]
[Thread 0x7fffbe6fd700 (LWP 4470) exited]
[New Thread 0x7fffbe6fd700 (LWP 4473)]
[Thread 0x7fffbe6fd700 (LWP 4473) exited]
[New Thread 0x7fffbe6fd700 (LWP 4474)]
[New Thread 0x7fffbc1fe700 (LWP 4475)]
[New Thread 0x7fffbeefe700 (LWP 4476)]
Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
716/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h: Немає
такого файла або каталогу.
Continuing.
[Thread 0x7fffbc1fe700 (LWP 4475) exited]
Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
716in /build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h
Continuing.
[New Thread 0x7fffbc1fe700 (LWP 4515)]
[New Thread 0x7fffbb9fd700 (LWP 4516)]
[New Thread 0x7fffb1eff700 (LWP 4517)]
[Thread 0x7fffdc6ff700 (LWP 4472) exited]
[New Thread 0x7fffb0cff700 (LWP 4518)]
[New Thread 0x7fffb04fe700 (LWP 4519)]
[New Thread 0x7fffaf396700 (LWP 4520)]
[New Thread 0x7fffaeb95700 (LWP 4521)]
[New Thread 0x7fffae394700 (LWP 4522)]
[New Thread 0x7fffadb93700 (LWP 4523)]
[New Thread 0x7fffad392700 (LWP 4524)]
[New Thread 0x7fffac98e700 (LWP 4525)]
[New Thread 0x7fffabaff700 (LWP 4526)]
[New Thread 0x7fffab2fe700 (LWP 4527)]
[New Thread 0x7fffbf948700 (LWP 4528)]
Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
716in /build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h
Continuing.
Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
716in /build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h
Continuing.
[New Thread 0x7fffdc6ff700 (LWP 4533)]
Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
716in /build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h
Continuing.
Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
/build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h:716
716in /build/buildd/firefox-31.0+build1/js/src/jit/x64/Assembler-x64.h
Continuing.
[New Thread 0x7fffa96ff700 (LWP 4545)]
Program received signal SIGSEGV, Segmentation fault.
PatchJump (label=..., jump=...) at
Re: [Mesa-dev] [PATCH] gallium: remove support for predicates from TGSI
On Tue, Aug 12, 2014 at 4:22 AM, Connor Abbott cwabbo...@gmail.com wrote: On Mon, Aug 11, 2014 at 4:32 PM, Eric Anholt e...@anholt.net wrote: Connor Abbott cwabbo...@gmail.com writes: On Wed, Aug 6, 2014 at 6:29 PM, Marek Olšák mar...@gmail.com wrote: What IR? A flatland GLSL IR? A replacement for Mesa IR? Something else? It's a flatland IR, similar to TGSI/Direct3D style with enough GLSL IR-like stuff to get existing things working now and enable us to eventually do linking in it (so we can use the same optimizations before linking and after). I was hoping to get a patch series out soon for discussion, and I've got an experimental i965 fs backend to try it out. It should be able to replace Mesa IR too, but that's not the primary goal - it's mostly to be able to do SSA-based optimizations in a backend-independent way. You can find a branch here: https://github.com/cwabbott0/mesa/tree/nir but I'd like to wait on discussing it until I put out some patches. It's more of a question of which gallium hardware drivers are going to support it. I don't think there will be any eager candidates. AFAIK almost every HW out there supports predication in one form or another - why wouldn't it make sense for a higher level part of the compiler to do e.g. if-conversion based on cost estimates provided by the driver, similar to how LLVM handles vectorization? That way, it can take advantage of the fact that things are predicated by being more aggressive with optimizations like code motion, CSE, etc. - that's why I originally added support for predication to NIR. Also, I'm sure that drivers that don't support control flow (i.e. vc4) will like having the frontend do if-conversion for them and pass along the predicated code - Eric? I'd be much more likely to eat whatever TGSI is generated, generate NIR, and then do lowering to predicated moves in NIR. Well at that point, assuming NIR is turned on in the frontend, you'd be going GLSL IR - NIR - TGSI - NIR - your backend... might be easier to just rip out TGSI altogether. This would also benefit other drivers that already use SSA, since we can avoid the round-trip of going out of and back into SSA since TGSI doesn't support SSA. It's nearly impossible to get rid of TGSI now. Too many things depend on it. It's the most used IR in Mesa. If somebody is planning to do optimizations in the backend, I recommend this: GLSL IR (no optimizations) - TGSI - NIR - your backend Marek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/st: enable ARB_gpu_shader5 if the reported GLSL version = 400
So... any objections to this approach? All the other gs5 bits are in for mesa/st now. On Sat, Aug 9, 2014 at 11:01 PM, Ilia Mirkin imir...@alum.mit.edu wrote: The ARB_gpu_shader5 extension is made up of a lot of small sub-parts. Instead of adding PIPE_CAP's for each of these, just rely on the GLSL version reported by the pipe driver. The remaining extensions lend themselves naturally to being checked through a single CAP. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- The only issue will happen when GLSL 4.00 is supported for real and so we can't rely on the st to clamp it down to 330. (Although perhaps the mesa version limiting logic would kick in then as well?) The alternative is to add a ARB_GS5 cap, or a bunch of little ones for the sub-parts, but that doesn't seem too useful. src/mesa/state_tracker/st_extensions.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/state_tracker/st_extensions.c b/src/mesa/state_tracker/st_extensions.c index 7ac4840..51fd71a 100644 --- a/src/mesa/state_tracker/st_extensions.c +++ b/src/mesa/state_tracker/st_extensions.c @@ -826,4 +826,7 @@ void st_init_extensions(struct st_context *st) } if (ctx-Const.MaxProgramTextureGatherComponents 0) ctx-Extensions.ARB_texture_gather = GL_TRUE; + + if (glsl_feature_level = 400) + ctx-Extensions.ARB_gpu_shader5 = GL_TRUE; } -- 1.8.5.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/5] mesa: update mangle script to force locale
On Tue, Aug 12, 2014 at 3:07 AM, Michel Dänzer mic...@daenzer.net wrote: On 12.08.2014 04:07, Ilia Mirkin wrote: The sorting is different with LC_ALL=C. To avoid different people's locale settings from fighting, force it to the one that was used to generate the current file. Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Not sure if there's a better way of doing it... perhaps forcing to C and just regenerating with that may be better? Not sure. I think so, the en_US.utf8 locale may not be available everywhere (in fact, it currently isn't on this system). I was afraid that'd be the case... Would having a giant diff which alters the sort order be OK? I think the sorting of numbers vs letters is different with LANG=C vs LANG=en_US.utf8. Perhaps there's some other way of forcing that? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] radeonsi: turn off PARTIAL_VS_WAVE and bump PRIMGROUP_SIZE, do the same for SI
On Mon, Aug 11, 2014 at 4:39 PM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
These are recommended values. Some additional tweeks will be needed
for tessellation.
For the series:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/radeonsi/si_state.c | 6 -
src/gallium/drivers/radeonsi/si_state_draw.c | 33
2 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 6e9a60a..e85f601 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3013,12 +3013,6 @@ void si_init_config(struct si_context *sctx)
si_pm4_set_reg(pm4, R_028B90_VGT_GS_INSTANCE_CNT, 0);
si_pm4_set_reg(pm4, R_028B98_VGT_STRMOUT_BUFFER_CONFIG, 0x0);
- if (sctx-b.chip_class == SI) {
- si_pm4_set_reg(pm4, R_028AA8_IA_MULTI_VGT_PARAM,
- S_028AA8_SWITCH_ON_EOP(1) |
- S_028AA8_PARTIAL_VS_WAVE_ON(1) |
- S_028AA8_PRIMGROUP_SIZE(63));
- }
si_pm4_set_reg(pm4, R_028AB4_VGT_REUSE_OFF, 0x);
si_pm4_set_reg(pm4, R_028AB8_VGT_VTX_CNT_EN, 0x0);
if (sctx-b.chip_class CIK)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 411ea04..15e6bac 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -384,12 +384,17 @@ static bool si_update_draw_info_state(struct si_context
*sctx,
{
struct si_pm4_state *pm4 = si_pm4_alloc_state(sctx);
struct si_shader *vs = si_get_vs_state(sctx);
+ struct si_state_rasterizer *rs = sctx-queued.named.rasterizer;
unsigned prim = si_conv_pipe_prim(info-mode);
unsigned gs_out_prim =
si_conv_prim_to_gs_out(sctx-gs_shader ?
sctx-gs_shader-current-shader.gs_output_prim :
info-mode);
unsigned ls_mask = 0;
+ unsigned primgroup_size = 256;
+ /* SWITCH_ON_EOP(0) is always preferable. */
+ bool wd_switch_on_eop = false;
+ bool ia_switch_on_eop = false;
if (pm4 == NULL)
return false;
@@ -399,14 +404,17 @@ static bool si_update_draw_info_state(struct si_context
*sctx,
return false;
}
- if (sctx-b.chip_class = CIK) {
- struct si_state_rasterizer *rs =
sctx-queued.named.rasterizer;
- unsigned primgroup_size = 64;
+ if (prim == V_008958_DI_PT_TRISTRIP_ADJ)
+ primgroup_size = 128;
- /* SWITCH_ON_EOP(0) is always preferable. */
- bool wd_switch_on_eop = false;
- bool ia_switch_on_eop = false;
+ /* This is a hardware requirement. */
+ if ((rs rs-line_stipple_enable) ||
+ (sctx-b.screen-debug_flags DBG_SWITCH_ON_EOP)) {
+ ia_switch_on_eop = true;
+ wd_switch_on_eop = true;
+ }
+ if (sctx-b.chip_class = CIK) {
/* WD_SWITCH_ON_EOP has no effect on GPUs with less than
* 4 shader engines. Set 1 to pass the assertion below.
* The other cases are hardware requirements. */
@@ -425,13 +433,6 @@ static bool si_update_draw_info_state(struct si_context
*sctx,
(info-indirect || info-instance_count 1))
wd_switch_on_eop = true;
- /* This is a hardware requirement. */
- if ((rs rs-line_stipple_enable) ||
- (sctx-b.screen-debug_flags DBG_SWITCH_ON_EOP)) {
- ia_switch_on_eop = true;
- wd_switch_on_eop = true;
- }
-
/* If the WD switch is false, the IA switch must be false
too. */
assert(wd_switch_on_eop || !ia_switch_on_eop);
@@ -442,13 +443,17 @@ static bool si_update_draw_info_state(struct si_context
*sctx,
si_pm4_cmd_add(pm4, prim); /* VGT_PRIMITIVE_TYPE */
si_pm4_cmd_add(pm4, /* IA_MULTI_VGT_PARAM */
S_028AA8_SWITCH_ON_EOP(ia_switch_on_eop) |
- S_028AA8_PARTIAL_VS_WAVE_ON(1) |
+ S_028AA8_PARTIAL_VS_WAVE_ON(0) |
S_028AA8_PRIMGROUP_SIZE(primgroup_size - 1) |
S_028AA8_WD_SWITCH_ON_EOP(wd_switch_on_eop));
si_pm4_cmd_add(pm4, 0); /* VGT_LS_HS_CONFIG */
si_pm4_cmd_end(pm4, false);
} else {
si_pm4_set_reg(pm4, R_008958_VGT_PRIMITIVE_TYPE, prim);
+ si_pm4_set_reg(pm4, R_028AA8_IA_MULTI_VGT_PARAM,
+
Re: [Mesa-dev] [PATCH 1/4] r600g: clear constant buffer sizes at the beginning of CS
On Mon, Aug 11, 2014 at 4:46 PM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
For the series:
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
src/gallium/drivers/r600/evergreen_state.c | 104
++---
src/gallium/drivers/r600/evergreend.h | 1 +
src/gallium/drivers/r600/r600_state.c | 31 -
3 files changed, 49 insertions(+), 87 deletions(-)
diff --git a/src/gallium/drivers/r600/evergreen_state.c
b/src/gallium/drivers/r600/evergreen_state.c
index 7495857..67f505d 100644
--- a/src/gallium/drivers/r600/evergreen_state.c
+++ b/src/gallium/drivers/r600/evergreen_state.c
@@ -2182,9 +2182,9 @@ void cayman_init_common_regs(struct r600_command_buffer
*cb,
static void cayman_init_atom_start_cs(struct r600_context *rctx)
{
struct r600_command_buffer *cb = rctx-start_cs_cmd;
- int tmp;
+ int tmp, i;
- r600_init_command_buffer(cb, 256);
+ r600_init_command_buffer(cb, 320);
/* This must be first. */
r600_store_value(cb, PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
@@ -2295,40 +2295,24 @@ static void cayman_init_atom_start_cs(struct
r600_context *rctx)
/* to avoid GPU doing any preloading of constant from random address
*/
r600_store_context_reg_seq(cb, R_028140_ALU_CONST_BUFFER_SIZE_PS_0,
16);
- r600_store_value(cb, 0); /* R_028140_ALU_CONST_BUFFER_SIZE_PS_0 */
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
+ for (i = 0; i 16; i++)
+ r600_store_value(cb, 0);
r600_store_context_reg_seq(cb, R_028180_ALU_CONST_BUFFER_SIZE_VS_0,
16);
- r600_store_value(cb, 0); /* R_028180_ALU_CONST_BUFFER_SIZE_VS_0 */
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
+ for (i = 0; i 16; i++)
+ r600_store_value(cb, 0);
+
+ r600_store_context_reg_seq(cb, R_0281C0_ALU_CONST_BUFFER_SIZE_GS_0,
16);
+ for (i = 0; i 16; i++)
+ r600_store_value(cb, 0);
+
+ r600_store_context_reg_seq(cb, R_028FC0_ALU_CONST_BUFFER_SIZE_LS_0,
16);
+ for (i = 0; i 16; i++)
+ r600_store_value(cb, 0);
+
+ r600_store_context_reg_seq(cb, R_028F80_ALU_CONST_BUFFER_SIZE_HS_0,
16);
+ for (i = 0; i 16; i++)
+ r600_store_value(cb, 0);
if (rctx-screen-b.has_streamout) {
r600_store_context_reg(cb,
R_028B28_VGT_STRMOUT_DRAW_OPAQUE_OFFSET, 0);
@@ -2472,14 +2456,14 @@ void evergreen_init_atom_start_cs(struct r600_context
*rctx)
int num_hs_stack_entries;
int num_ls_stack_entries;
enum radeon_family family;
- unsigned tmp;
+ unsigned tmp, i;
if (rctx-b.chip_class == CAYMAN) {
cayman_init_atom_start_cs(rctx);
return;
}
- r600_init_command_buffer(cb, 256);
+ r600_init_command_buffer(cb, 320);
/* This must be first. */
r600_store_value(cb, PKT3(PKT3_CONTEXT_CONTROL, 1, 0));
@@ -2752,40 +2736,24 @@ void evergreen_init_atom_start_cs(struct r600_context
*rctx)
/* to avoid GPU doing any preloading of constant from random address
*/
r600_store_context_reg_seq(cb, R_028140_ALU_CONST_BUFFER_SIZE_PS_0,
16);
- r600_store_value(cb, 0); /* R_028140_ALU_CONST_BUFFER_SIZE_PS_0 */
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
- r600_store_value(cb, 0);
+ for (i = 0; i 16; i++)
+ r600_store_value(cb, 0);
r600_store_context_reg_seq(cb, R_028180_ALU_CONST_BUFFER_SIZE_VS_0,
16);
-
[Mesa-dev] [PATCH 2/3] mesa: update glxext.h to version 20140810
---
include/GL/glxext.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/GL/glxext.h b/include/GL/glxext.h
index b96133e..174fc21 100644
--- a/include/GL/glxext.h
+++ b/include/GL/glxext.h
@@ -33,10 +33,10 @@ extern C {
** used to make the header, and the header can be found at
** http://www.opengl.org/registry/
**
-** Khronos $Revision: 27498 $ on $Date: 2014-07-25 19:12:07 -0700 (Fri, 25 Jul
2014) $
+** Khronos $Revision: 27684 $ on $Date: 2014-08-11 01:21:35 -0700 (Mon, 11 Aug
2014) $
*/
-#define GLX_GLXEXT_VERSION 20140725
+#define GLX_GLXEXT_VERSION 20140810
/* Generated C header for:
* API: glx
@@ -158,6 +158,13 @@ __GLXextFuncPtr glXGetProcAddress (const GLubyte
*procName);
#endif
#endif /* GLX_VERSION_1_4 */
+#ifndef GLX_ARB_context_flush_control
+#define GLX_ARB_context_flush_control 1
+#define GLX_CONTEXT_RELEASE_BEHAVIOR_ARB 0x2097
+#define GLX_CONTEXT_RELEASE_BEHAVIOR_NONE_ARB 0
+#define GLX_CONTEXT_RELEASE_BEHAVIOR_FLUSH_ARB 0x2098
+#endif /* GLX_ARB_context_flush_control */
+
#ifndef GLX_ARB_create_context
#define GLX_ARB_create_context 1
#define GLX_CONTEXT_DEBUG_BIT_ARB 0x0001
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] mesa: update wglext.h to version 20140810
---
include/GL/wglext.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/GL/wglext.h b/include/GL/wglext.h
index 5860c86..daba410 100644
--- a/include/GL/wglext.h
+++ b/include/GL/wglext.h
@@ -33,7 +33,7 @@ extern C {
** used to make the header, and the header can be found at
** http://www.opengl.org/registry/
**
-** Khronos $Revision: 27191 $ on $Date: 2014-06-30 15:11:33 -0700 (Mon, 30 Jun
2014) $
+** Khronos $Revision: 27684 $ on $Date: 2014-08-11 01:21:35 -0700 (Mon, 11 Aug
2014) $
*/
#if defined(_WIN32) !defined(APIENTRY) !defined(__CYGWIN__)
!defined(__SCITECH_SNAP__)
@@ -41,7 +41,7 @@ extern C {
#include windows.h
#endif
-#define WGL_WGLEXT_VERSION 20140630
+#define WGL_WGLEXT_VERSION 20140810
/* Generated C header for:
* API: wgl
@@ -70,6 +70,13 @@ BOOL WINAPI wglRestoreBufferRegionARB (HANDLE hRegion, int
x, int y, int width,
#endif
#endif /* WGL_ARB_buffer_region */
+#ifndef WGL_ARB_context_flush_control
+#define WGL_ARB_context_flush_control 1
+#define WGL_CONTEXT_RELEASE_BEHAVIOR_ARB 0x2097
+#define WGL_CONTEXT_RELEASE_BEHAVIOR_NONE_ARB 0
+#define WGL_CONTEXT_RELEASE_BEHAVIOR_FLUSH_ARB 0x2098
+#endif /* WGL_ARB_context_flush_control */
+
#ifndef WGL_ARB_create_context
#define WGL_ARB_create_context 1
#define WGL_CONTEXT_DEBUG_BIT_ARB 0x0001
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] mesa: update glext.h to version 20140810
This brings in the new OpenGL 4.5 features.
---
include/GL/glext.h | 380 +++-
1 file changed, 378 insertions(+), 2 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 5e67830..256ad35 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -33,7 +33,7 @@ extern C {
** used to make the header, and the header can be found at
** http://www.opengl.org/registry/
**
-** Khronos $Revision: 27498 $ on $Date: 2014-07-25 19:12:07 -0700 (Fri, 25 Jul
2014) $
+** Khronos $Revision: 27684 $ on $Date: 2014-08-11 01:21:35 -0700 (Mon, 11 Aug
2014) $
*/
#if defined(_WIN32) !defined(APIENTRY) !defined(__CYGWIN__)
!defined(__SCITECH_SNAP__)
@@ -53,7 +53,7 @@ extern C {
#define GLAPI extern
#endif
-#define GL_GLEXT_VERSION 20140725
+#define GL_GLEXT_VERSION 20140810
/* Generated C header for:
* API: gl
@@ -2575,10 +2575,279 @@ GLAPI void APIENTRY glBindVertexBuffers (GLuint first,
GLsizei count, const GLui
#endif
#endif /* GL_VERSION_4_4 */
+#ifndef GL_VERSION_4_5
+#define GL_VERSION_4_5 1
+#define GL_CONTEXT_LOST 0x0507
+#define GL_NEGATIVE_ONE_TO_ONE0x935E
+#define GL_ZERO_TO_ONE0x935F
+#define GL_CLIP_ORIGIN0x935C
+#define GL_CLIP_DEPTH_MODE0x935D
+#define GL_QUERY_WAIT_INVERTED0x8E17
+#define GL_QUERY_NO_WAIT_INVERTED 0x8E18
+#define GL_QUERY_BY_REGION_WAIT_INVERTED 0x8E19
+#define GL_QUERY_BY_REGION_NO_WAIT_INVERTED 0x8E1A
+#define GL_MAX_CULL_DISTANCES 0x82F9
+#define GL_MAX_COMBINED_CLIP_AND_CULL_DISTANCES 0x82FA
+#define GL_TEXTURE_TARGET 0x1006
+#define GL_QUERY_TARGET 0x82EA
+#define GL_TEXTURE_BINDING0x82EB
+#define GL_GUILTY_CONTEXT_RESET 0x8253
+#define GL_INNOCENT_CONTEXT_RESET 0x8254
+#define GL_UNKNOWN_CONTEXT_RESET 0x8255
+#define GL_RESET_NOTIFICATION_STRATEGY0x8256
+#define GL_LOSE_CONTEXT_ON_RESET 0x8252
+#define GL_NO_RESET_NOTIFICATION 0x8261
+#define GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT 0x0004
+#define GL_CONTEXT_RELEASE_BEHAVIOR 0x82FB
+#define GL_CONTEXT_RELEASE_BEHAVIOR_FLUSH 0x82FC
+typedef void (APIENTRYP PFNGLCLIPCONTROLPROC) (GLenum origin, GLenum depth);
+typedef void (APIENTRYP PFNGLCREATETRANSFORMFEEDBACKSPROC) (GLsizei n, GLuint
*ids);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERBASEPROC) (GLuint xfb,
GLuint index, GLuint buffer);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERRANGEPROC) (GLuint xfb,
GLuint index, GLuint buffer, GLintptr offset, GLsizei size);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKIVPROC) (GLuint xfb, GLenum
pname, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI_VPROC) (GLuint xfb, GLenum
pname, GLuint index, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI64_VPROC) (GLuint xfb,
GLenum pname, GLuint index, GLint64 *param);
+typedef void (APIENTRYP PFNGLCREATEBUFFERSPROC) (GLsizei n, GLuint *buffers);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSTORAGEPROC) (GLuint buffer, GLsizei
size, const void *data, GLbitfield flags);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERDATAPROC) (GLuint buffer, GLsizei
size, const void *data, GLenum usage);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSUBDATAPROC) (GLuint buffer, GLintptr
offset, GLsizei size, const void *data);
+typedef void (APIENTRYP PFNGLCOPYNAMEDBUFFERSUBDATAPROC) (GLuint readBuffer,
GLuint writeBuffer, GLintptr readOffset, GLintptr writeOffset, GLsizei size);
+typedef void (APIENTRYP PFNGLCLEARNAMEDBUFFERDATAPROC) (GLuint buffer, GLenum
internalformat, GLenum format, GLenum type, const void *data);
+typedef void (APIENTRYP PFNGLCLEARNAMEDBUFFERSUBDATAPROC) (GLuint buffer,
GLenum internalformat, GLintptr offset, GLsizei size, GLenum format, GLenum
type, const void *data);
+typedef void *(APIENTRYP PFNGLMAPNAMEDBUFFERPROC) (GLuint buffer, GLenum
access);
+typedef void *(APIENTRYP PFNGLMAPNAMEDBUFFERRANGEPROC) (GLuint buffer,
GLintptr offset, GLsizei length, GLbitfield access);
+typedef GLboolean (APIENTRYP PFNGLUNMAPNAMEDBUFFERPROC) (GLuint buffer);
+typedef void (APIENTRYP PFNGLFLUSHMAPPEDNAMEDBUFFERRANGEPROC) (GLuint buffer,
GLintptr offset, GLsizei length);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERPARAMETERIVPROC) (GLuint buffer,
GLenum pname, GLint *params);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERPARAMETERI64VPROC) (GLuint buffer,
GLenum pname, GLint64 *params);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERPOINTERVPROC) (GLuint buffer,
GLenum pname, void **params);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERSUBDATAPROC) (GLuint buffer,
GLintptr offset, GLsizei size, void *data);
+typedef void (APIENTRYP PFNGLCREATEFRAMEBUFFERSPROC) (GLsizei n, GLuint
*framebuffers);
+typedef void (APIENTRYP PFNGLNAMEDFRAMEBUFFERRENDERBUFFERPROC) (GLuint
framebuffer, GLenum attachment, GLenum renderbuffertarget, GLuint renderbuffer);
[Mesa-dev] Update the way we get descriptions about drirc options
Hello, Currently Mesa enables the user to tune some driver parameters via .drirc, a xml file. Driconf is a GUI app that allows the user to manipulate .drirc It uses the program xdriinfo to get info about the possible options. xdriinfo gives Driconf the driver name of the device used for rendering and then Driconf can call it again to get a xml description of the possible options for this driver. xdriinfo uses two functions to get these info: glXGetScreenDriver and glXGetDriverConfig Unfortunately it doesn't seem to work well with Wayland and XWayland. Also only the main device is detected with DRI3 DRI_PRIME (I didn't test DRI2 DRI_PRIME). I've begun to write a new gui app equivalent to Driconf, but that can also detect multiple gpus and displays gl info on them. Do you have suggestions on a new way to get the driver/driver's options info that would work with multiple gpus and Wayland ? My thoughts are that at the beginning of .drirc could be contained info about all drivers's options, and also info about what drivers would be loaded for the detected devices. Driconf and old Mesa would still be able to read the .drirc file, and would ignore the additional section. Yours, Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] mesa: update glext.h to version 20140810
Should you also update gl_mangle.h? (See
http://patchwork.freedesktop.org/patch/31518/ and
http://patchwork.freedesktop.org/patch/31519/)
On Tue, Aug 12, 2014 at 9:32 AM, Brian Paul bri...@vmware.com wrote:
This brings in the new OpenGL 4.5 features.
---
include/GL/glext.h | 380
+++-
1 file changed, 378 insertions(+), 2 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 5e67830..256ad35 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -33,7 +33,7 @@ extern C {
** used to make the header, and the header can be found at
** http://www.opengl.org/registry/
**
-** Khronos $Revision: 27498 $ on $Date: 2014-07-25 19:12:07 -0700 (Fri, 25
Jul 2014) $
+** Khronos $Revision: 27684 $ on $Date: 2014-08-11 01:21:35 -0700 (Mon, 11
Aug 2014) $
*/
#if defined(_WIN32) !defined(APIENTRY) !defined(__CYGWIN__)
!defined(__SCITECH_SNAP__)
@@ -53,7 +53,7 @@ extern C {
#define GLAPI extern
#endif
-#define GL_GLEXT_VERSION 20140725
+#define GL_GLEXT_VERSION 20140810
/* Generated C header for:
* API: gl
@@ -2575,10 +2575,279 @@ GLAPI void APIENTRY glBindVertexBuffers (GLuint
first, GLsizei count, const GLui
#endif
#endif /* GL_VERSION_4_4 */
+#ifndef GL_VERSION_4_5
+#define GL_VERSION_4_5 1
+#define GL_CONTEXT_LOST 0x0507
+#define GL_NEGATIVE_ONE_TO_ONE0x935E
+#define GL_ZERO_TO_ONE0x935F
+#define GL_CLIP_ORIGIN0x935C
+#define GL_CLIP_DEPTH_MODE0x935D
+#define GL_QUERY_WAIT_INVERTED0x8E17
+#define GL_QUERY_NO_WAIT_INVERTED 0x8E18
+#define GL_QUERY_BY_REGION_WAIT_INVERTED 0x8E19
+#define GL_QUERY_BY_REGION_NO_WAIT_INVERTED 0x8E1A
+#define GL_MAX_CULL_DISTANCES 0x82F9
+#define GL_MAX_COMBINED_CLIP_AND_CULL_DISTANCES 0x82FA
+#define GL_TEXTURE_TARGET 0x1006
+#define GL_QUERY_TARGET 0x82EA
+#define GL_TEXTURE_BINDING0x82EB
+#define GL_GUILTY_CONTEXT_RESET 0x8253
+#define GL_INNOCENT_CONTEXT_RESET 0x8254
+#define GL_UNKNOWN_CONTEXT_RESET 0x8255
+#define GL_RESET_NOTIFICATION_STRATEGY0x8256
+#define GL_LOSE_CONTEXT_ON_RESET 0x8252
+#define GL_NO_RESET_NOTIFICATION 0x8261
+#define GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT 0x0004
+#define GL_CONTEXT_RELEASE_BEHAVIOR 0x82FB
+#define GL_CONTEXT_RELEASE_BEHAVIOR_FLUSH 0x82FC
+typedef void (APIENTRYP PFNGLCLIPCONTROLPROC) (GLenum origin, GLenum depth);
+typedef void (APIENTRYP PFNGLCREATETRANSFORMFEEDBACKSPROC) (GLsizei n,
GLuint *ids);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERBASEPROC) (GLuint xfb,
GLuint index, GLuint buffer);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERRANGEPROC) (GLuint xfb,
GLuint index, GLuint buffer, GLintptr offset, GLsizei size);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKIVPROC) (GLuint xfb, GLenum
pname, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI_VPROC) (GLuint xfb,
GLenum pname, GLuint index, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI64_VPROC) (GLuint xfb,
GLenum pname, GLuint index, GLint64 *param);
+typedef void (APIENTRYP PFNGLCREATEBUFFERSPROC) (GLsizei n, GLuint *buffers);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSTORAGEPROC) (GLuint buffer, GLsizei
size, const void *data, GLbitfield flags);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERDATAPROC) (GLuint buffer, GLsizei
size, const void *data, GLenum usage);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSUBDATAPROC) (GLuint buffer,
GLintptr offset, GLsizei size, const void *data);
+typedef void (APIENTRYP PFNGLCOPYNAMEDBUFFERSUBDATAPROC) (GLuint readBuffer,
GLuint writeBuffer, GLintptr readOffset, GLintptr writeOffset, GLsizei size);
+typedef void (APIENTRYP PFNGLCLEARNAMEDBUFFERDATAPROC) (GLuint buffer,
GLenum internalformat, GLenum format, GLenum type, const void *data);
+typedef void (APIENTRYP PFNGLCLEARNAMEDBUFFERSUBDATAPROC) (GLuint buffer,
GLenum internalformat, GLintptr offset, GLsizei size, GLenum format, GLenum
type, const void *data);
+typedef void *(APIENTRYP PFNGLMAPNAMEDBUFFERPROC) (GLuint buffer, GLenum
access);
+typedef void *(APIENTRYP PFNGLMAPNAMEDBUFFERRANGEPROC) (GLuint buffer,
GLintptr offset, GLsizei length, GLbitfield access);
+typedef GLboolean (APIENTRYP PFNGLUNMAPNAMEDBUFFERPROC) (GLuint buffer);
+typedef void (APIENTRYP PFNGLFLUSHMAPPEDNAMEDBUFFERRANGEPROC) (GLuint
buffer, GLintptr offset, GLsizei length);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERPARAMETERIVPROC) (GLuint buffer,
GLenum pname, GLint *params);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERPARAMETERI64VPROC) (GLuint
buffer, GLenum pname, GLint64 *params);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERPOINTERVPROC) (GLuint buffer,
GLenum pname, void **params);
+typedef void (APIENTRYP PFNGLGETNAMEDBUFFERSUBDATAPROC)
Re: [Mesa-dev] [PATCH 1/3] mesa: update glext.h to version 20140810
Yeah, I always forget about that. I'll post a patch for that too. Thanks.
-Brian
On 08/12/2014 07:56 AM, Ilia Mirkin wrote:
Should you also update gl_mangle.h? (See
https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/31518/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=fu4vnjYSIvOUCGhfGsKhtICZpAq%2FrhLE8AV1DkGRdtw%3D%0As=290620b9efddad9c36da559b3d482a837869332fdc37216252cb5a35e9a5c823
and
https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/31519/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=fu4vnjYSIvOUCGhfGsKhtICZpAq%2FrhLE8AV1DkGRdtw%3D%0As=235d9e060593e7a620d40975122cc0bd344e305f08e0f02c3085f5a6d76dd17d)
On Tue, Aug 12, 2014 at 9:32 AM, Brian Paul bri...@vmware.com wrote:
This brings in the new OpenGL 4.5 features.
---
include/GL/glext.h | 380 +++-
1 file changed, 378 insertions(+), 2 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 5e67830..256ad35 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -33,7 +33,7 @@ extern C {
** used to make the header, and the header can be found at
**
https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=fu4vnjYSIvOUCGhfGsKhtICZpAq%2FrhLE8AV1DkGRdtw%3D%0As=9da128c5bec671df02074d1261c8053cc86e491e179ddf555d9828ec3ed284b8
**
-** Khronos $Revision: 27498 $ on $Date: 2014-07-25 19:12:07 -0700 (Fri, 25 Jul
2014) $
+** Khronos $Revision: 27684 $ on $Date: 2014-08-11 01:21:35 -0700 (Mon, 11 Aug
2014) $
*/
#if defined(_WIN32) !defined(APIENTRY) !defined(__CYGWIN__)
!defined(__SCITECH_SNAP__)
@@ -53,7 +53,7 @@ extern C {
#define GLAPI extern
#endif
-#define GL_GLEXT_VERSION 20140725
+#define GL_GLEXT_VERSION 20140810
/* Generated C header for:
* API: gl
@@ -2575,10 +2575,279 @@ GLAPI void APIENTRY glBindVertexBuffers (GLuint first,
GLsizei count, const GLui
#endif
#endif /* GL_VERSION_4_4 */
+#ifndef GL_VERSION_4_5
+#define GL_VERSION_4_5 1
+#define GL_CONTEXT_LOST 0x0507
+#define GL_NEGATIVE_ONE_TO_ONE0x935E
+#define GL_ZERO_TO_ONE0x935F
+#define GL_CLIP_ORIGIN0x935C
+#define GL_CLIP_DEPTH_MODE0x935D
+#define GL_QUERY_WAIT_INVERTED0x8E17
+#define GL_QUERY_NO_WAIT_INVERTED 0x8E18
+#define GL_QUERY_BY_REGION_WAIT_INVERTED 0x8E19
+#define GL_QUERY_BY_REGION_NO_WAIT_INVERTED 0x8E1A
+#define GL_MAX_CULL_DISTANCES 0x82F9
+#define GL_MAX_COMBINED_CLIP_AND_CULL_DISTANCES 0x82FA
+#define GL_TEXTURE_TARGET 0x1006
+#define GL_QUERY_TARGET 0x82EA
+#define GL_TEXTURE_BINDING0x82EB
+#define GL_GUILTY_CONTEXT_RESET 0x8253
+#define GL_INNOCENT_CONTEXT_RESET 0x8254
+#define GL_UNKNOWN_CONTEXT_RESET 0x8255
+#define GL_RESET_NOTIFICATION_STRATEGY0x8256
+#define GL_LOSE_CONTEXT_ON_RESET 0x8252
+#define GL_NO_RESET_NOTIFICATION 0x8261
+#define GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT 0x0004
+#define GL_CONTEXT_RELEASE_BEHAVIOR 0x82FB
+#define GL_CONTEXT_RELEASE_BEHAVIOR_FLUSH 0x82FC
+typedef void (APIENTRYP PFNGLCLIPCONTROLPROC) (GLenum origin, GLenum depth);
+typedef void (APIENTRYP PFNGLCREATETRANSFORMFEEDBACKSPROC) (GLsizei n, GLuint
*ids);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERBASEPROC) (GLuint xfb,
GLuint index, GLuint buffer);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERRANGEPROC) (GLuint xfb,
GLuint index, GLuint buffer, GLintptr offset, GLsizei size);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKIVPROC) (GLuint xfb, GLenum
pname, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI_VPROC) (GLuint xfb, GLenum
pname, GLuint index, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI64_VPROC) (GLuint xfb,
GLenum pname, GLuint index, GLint64 *param);
+typedef void (APIENTRYP PFNGLCREATEBUFFERSPROC) (GLsizei n, GLuint *buffers);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSTORAGEPROC) (GLuint buffer, GLsizei
size, const void *data, GLbitfield flags);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERDATAPROC) (GLuint buffer, GLsizei
size, const void *data, GLenum usage);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSUBDATAPROC) (GLuint buffer, GLintptr
offset, GLsizei size, const void *data);
+typedef void (APIENTRYP PFNGLCOPYNAMEDBUFFERSUBDATAPROC) (GLuint readBuffer,
GLuint writeBuffer, GLintptr readOffset, GLintptr writeOffset, GLsizei size);
+typedef void (APIENTRYP PFNGLCLEARNAMEDBUFFERDATAPROC) (GLuint buffer, GLenum
internalformat, GLenum format, GLenum type, const void *data);
+typedef void (APIENTRYP PFNGLCLEARNAMEDBUFFERSUBDATAPROC) (GLuint buffer,
GLenum internalformat, GLintptr offset, GLsizei size, GLenum format, GLenum
[Mesa-dev] [PATCH] mesa: regenerate gl_mangle.h
--- include/GL/gl_mangle.h | 139 1 file changed, 139 insertions(+) diff --git a/include/GL/gl_mangle.h b/include/GL/gl_mangle.h index b3a9c88..e04cf66 100644 --- a/include/GL/gl_mangle.h +++ b/include/GL/gl_mangle.h @@ -106,6 +106,7 @@ #define glBindTextureEXT MANGLE(BindTextureEXT) #define glBindTexture MANGLE(BindTexture) #define glBindTextures MANGLE(BindTextures) +#define glBindTextureUnit MANGLE(BindTextureUnit) #define glBindTextureUnitParameterEXT MANGLE(BindTextureUnitParameterEXT) #define glBindTransformFeedbackMANGLE(BindTransformFeedback) #define glBindTransformFeedbackNV MANGLE(BindTransformFeedbackNV) @@ -129,6 +130,7 @@ #define glBinormalPointerEXT MANGLE(BinormalPointerEXT) #define glBitmap MANGLE(Bitmap) #define glBitmapxOES MANGLE(BitmapxOES) +#define glBlendBarrierKHR MANGLE(BlendBarrierKHR) #define glBlendBarrierNV MANGLE(BlendBarrierNV) #define glBlendColorEXTMANGLE(BlendColorEXT) #define glBlendColor MANGLE(BlendColor) @@ -157,9 +159,11 @@ #define glBlendParameteriNVMANGLE(BlendParameteriNV) #define glBlitFramebufferEXT MANGLE(BlitFramebufferEXT) #define glBlitFramebuffer MANGLE(BlitFramebuffer) +#define glBlitNamedFramebuffer MANGLE(BlitNamedFramebuffer) #define glBufferAddressRangeNV MANGLE(BufferAddressRangeNV) #define glBufferDataARBMANGLE(BufferDataARB) #define glBufferData MANGLE(BufferData) +#define glBufferPageCommitmentARB MANGLE(BufferPageCommitmentARB) #define glBufferParameteriAPPLEMANGLE(BufferParameteriAPPLE) #define glBufferStorageMANGLE(BufferStorage) #define glBufferSubDataARB MANGLE(BufferSubDataARB) @@ -169,6 +173,7 @@ #define glCheckFramebufferStatusEXT MANGLE(CheckFramebufferStatusEXT) #define glCheckFramebufferStatus MANGLE(CheckFramebufferStatus) #define glCheckNamedFramebufferStatusEXT MANGLE(CheckNamedFramebufferStatusEXT) +#define glCheckNamedFramebufferStatus MANGLE(CheckNamedFramebufferStatus) #define glClampColorARBMANGLE(ClampColorARB) #define glClampColor MANGLE(ClampColor) #define glClearAccum MANGLE(ClearAccum) @@ -191,7 +196,13 @@ #define glClearIndex MANGLE(ClearIndex) #define glClearMANGLE(Clear) #define glClearNamedBufferDataEXT MANGLE(ClearNamedBufferDataEXT) +#define glClearNamedBufferData MANGLE(ClearNamedBufferData) #define glClearNamedBufferSubDataEXT MANGLE(ClearNamedBufferSubDataEXT) +#define glClearNamedBufferSubData MANGLE(ClearNamedBufferSubData) +#define glClearNamedFramebufferfi MANGLE(ClearNamedFramebufferfi) +#define glClearNamedFramebufferfv MANGLE(ClearNamedFramebufferfv) +#define glClearNamedFramebufferiv MANGLE(ClearNamedFramebufferiv) +#define glClearNamedFramebufferuiv MANGLE(ClearNamedFramebufferuiv) #define glClearStencil MANGLE(ClearStencil) #define glClearTexImageMANGLE(ClearTexImage) #define glClearTexSubImage MANGLE(ClearTexSubImage) @@ -200,6 +211,7 @@ #define glClientActiveVertexStreamATI MANGLE(ClientActiveVertexStreamATI) #define glClientAttribDefaultEXT MANGLE(ClientAttribDefaultEXT) #define glClientWaitSync MANGLE(ClientWaitSync) +#define glClipControl MANGLE(ClipControl) #define glClipPlanefOESMANGLE(ClipPlanefOES) #define glClipPlaneMANGLE(ClipPlane) #define glClipPlanexOESMANGLE(ClipPlanexOES) @@ -308,8 +320,11 @@ #define glCompressedTextureImage2DEXT MANGLE(CompressedTextureImage2DEXT) #define glCompressedTextureImage3DEXT MANGLE(CompressedTextureImage3DEXT) #define glCompressedTextureSubImage1DEXT MANGLE(CompressedTextureSubImage1DEXT) +#define glCompressedTextureSubImage1D MANGLE(CompressedTextureSubImage1D) #define glCompressedTextureSubImage2DEXT MANGLE(CompressedTextureSubImage2DEXT) +#define glCompressedTextureSubImage2D MANGLE(CompressedTextureSubImage2D) #define glCompressedTextureSubImage3DEXT MANGLE(CompressedTextureSubImage3DEXT) +#define glCompressedTextureSubImage3D MANGLE(CompressedTextureSubImage3D) #define glConvolutionFilter1DEXT MANGLE(ConvolutionFilter1DEXT) #define glConvolutionFilter1D MANGLE(ConvolutionFilter1D) #define glConvolutionFilter2DEXT MANGLE(ConvolutionFilter2DEXT) @@ -340,6 +355,7 @@ #define glCopyMultiTexSubImage1DEXT MANGLE(CopyMultiTexSubImage1DEXT) #define glCopyMultiTexSubImage2DEXT
Re: [Mesa-dev] [PATCH 1/3] mesa: update glext.h to version 20140810
Series is Reviewed-by: Ilia Mirkin imir...@alum.mit.edu
I'll drop my (hopefully identical) patches.
On Tue, Aug 12, 2014 at 10:02 AM, Brian Paul bri...@vmware.com wrote:
Yeah, I always forget about that. I'll post a patch for that too. Thanks.
-Brian
On 08/12/2014 07:56 AM, Ilia Mirkin wrote:
Should you also update gl_mangle.h? (See
https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/31518/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=fu4vnjYSIvOUCGhfGsKhtICZpAq%2FrhLE8AV1DkGRdtw%3D%0As=290620b9efddad9c36da559b3d482a837869332fdc37216252cb5a35e9a5c823
and
https://urldefense.proofpoint.com/v1/url?u=http://patchwork.freedesktop.org/patch/31519/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=fu4vnjYSIvOUCGhfGsKhtICZpAq%2FrhLE8AV1DkGRdtw%3D%0As=235d9e060593e7a620d40975122cc0bd344e305f08e0f02c3085f5a6d76dd17d)
On Tue, Aug 12, 2014 at 9:32 AM, Brian Paul bri...@vmware.com wrote:
This brings in the new OpenGL 4.5 features.
---
include/GL/glext.h | 380
+++-
1 file changed, 378 insertions(+), 2 deletions(-)
diff --git a/include/GL/glext.h b/include/GL/glext.h
index 5e67830..256ad35 100644
--- a/include/GL/glext.h
+++ b/include/GL/glext.h
@@ -33,7 +33,7 @@ extern C {
** used to make the header, and the header can be found at
**
https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0Am=fu4vnjYSIvOUCGhfGsKhtICZpAq%2FrhLE8AV1DkGRdtw%3D%0As=9da128c5bec671df02074d1261c8053cc86e491e179ddf555d9828ec3ed284b8
**
-** Khronos $Revision: 27498 $ on $Date: 2014-07-25 19:12:07 -0700 (Fri,
25 Jul 2014) $
+** Khronos $Revision: 27684 $ on $Date: 2014-08-11 01:21:35 -0700 (Mon,
11 Aug 2014) $
*/
#if defined(_WIN32) !defined(APIENTRY) !defined(__CYGWIN__)
!defined(__SCITECH_SNAP__)
@@ -53,7 +53,7 @@ extern C {
#define GLAPI extern
#endif
-#define GL_GLEXT_VERSION 20140725
+#define GL_GLEXT_VERSION 20140810
/* Generated C header for:
* API: gl
@@ -2575,10 +2575,279 @@ GLAPI void APIENTRY glBindVertexBuffers (GLuint
first, GLsizei count, const GLui
#endif
#endif /* GL_VERSION_4_4 */
+#ifndef GL_VERSION_4_5
+#define GL_VERSION_4_5 1
+#define GL_CONTEXT_LOST 0x0507
+#define GL_NEGATIVE_ONE_TO_ONE0x935E
+#define GL_ZERO_TO_ONE0x935F
+#define GL_CLIP_ORIGIN0x935C
+#define GL_CLIP_DEPTH_MODE0x935D
+#define GL_QUERY_WAIT_INVERTED0x8E17
+#define GL_QUERY_NO_WAIT_INVERTED 0x8E18
+#define GL_QUERY_BY_REGION_WAIT_INVERTED 0x8E19
+#define GL_QUERY_BY_REGION_NO_WAIT_INVERTED 0x8E1A
+#define GL_MAX_CULL_DISTANCES 0x82F9
+#define GL_MAX_COMBINED_CLIP_AND_CULL_DISTANCES 0x82FA
+#define GL_TEXTURE_TARGET 0x1006
+#define GL_QUERY_TARGET 0x82EA
+#define GL_TEXTURE_BINDING0x82EB
+#define GL_GUILTY_CONTEXT_RESET 0x8253
+#define GL_INNOCENT_CONTEXT_RESET 0x8254
+#define GL_UNKNOWN_CONTEXT_RESET 0x8255
+#define GL_RESET_NOTIFICATION_STRATEGY0x8256
+#define GL_LOSE_CONTEXT_ON_RESET 0x8252
+#define GL_NO_RESET_NOTIFICATION 0x8261
+#define GL_CONTEXT_FLAG_ROBUST_ACCESS_BIT 0x0004
+#define GL_CONTEXT_RELEASE_BEHAVIOR 0x82FB
+#define GL_CONTEXT_RELEASE_BEHAVIOR_FLUSH 0x82FC
+typedef void (APIENTRYP PFNGLCLIPCONTROLPROC) (GLenum origin, GLenum
depth);
+typedef void (APIENTRYP PFNGLCREATETRANSFORMFEEDBACKSPROC) (GLsizei n,
GLuint *ids);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERBASEPROC) (GLuint
xfb, GLuint index, GLuint buffer);
+typedef void (APIENTRYP PFNGLTRANSFORMFEEDBACKBUFFERRANGEPROC) (GLuint
xfb, GLuint index, GLuint buffer, GLintptr offset, GLsizei size);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKIVPROC) (GLuint xfb,
GLenum pname, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI_VPROC) (GLuint xfb,
GLenum pname, GLuint index, GLint *param);
+typedef void (APIENTRYP PFNGLGETTRANSFORMFEEDBACKI64_VPROC) (GLuint xfb,
GLenum pname, GLuint index, GLint64 *param);
+typedef void (APIENTRYP PFNGLCREATEBUFFERSPROC) (GLsizei n, GLuint
*buffers);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSTORAGEPROC) (GLuint buffer,
GLsizei size, const void *data, GLbitfield flags);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERDATAPROC) (GLuint buffer,
GLsizei size, const void *data, GLenum usage);
+typedef void (APIENTRYP PFNGLNAMEDBUFFERSUBDATAPROC) (GLuint buffer,
GLintptr offset, GLsizei size, const void *data);
+typedef void (APIENTRYP PFNGLCOPYNAMEDBUFFERSUBDATAPROC) (GLuint
readBuffer, GLuint writeBuffer, GLintptr readOffset, GLintptr writeOffset,
GLsizei size);
+typedef void (APIENTRYP
Re: [Mesa-dev] [PATCH 5/5] docs: add GL4.5 section, mark ARB_texture_barrier as done
On 08/11/2014 01:07 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of GL4.5? docs/GL3.txt | 16 1 file changed, 16 insertions(+) diff --git a/docs/GL3.txt b/docs/GL3.txt index 7f18cd7..f204652 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -183,5 +183,21 @@ GL 4.4, GLSL 4.40: GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0, r600, radeonsi) +GL 4.5, GLSL 4.50: + + GL_ARB_ES3_1_compatibility not started + GL_ARB_clip_control not started + GL_ARB_conditional_render_inverted not started + GL_ARB_cull_distance not started + GL_ARB_derivative_controlnot started + GL_ARB_direct_state_access not started + GL_ARB_get_texture_sub_image not started Just FYI: I started implementing the new glGetTextureSubImage functions for this extension. Not sure when I'll finish it though... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Update the way we get descriptions about drirc options
Please note that drirc can also contain options that apply to all drivers, not just one driver. I don't think the GUI has been updated to support that. Marek On Tue, Aug 12, 2014 at 3:50 PM, Axel Davy axel.d...@ens.fr wrote: Hello, Currently Mesa enables the user to tune some driver parameters via .drirc, a xml file. Driconf is a GUI app that allows the user to manipulate .drirc It uses the program xdriinfo to get info about the possible options. xdriinfo gives Driconf the driver name of the device used for rendering and then Driconf can call it again to get a xml description of the possible options for this driver. xdriinfo uses two functions to get these info: glXGetScreenDriver and glXGetDriverConfig Unfortunately it doesn't seem to work well with Wayland and XWayland. Also only the main device is detected with DRI3 DRI_PRIME (I didn't test DRI2 DRI_PRIME). I've begun to write a new gui app equivalent to Driconf, but that can also detect multiple gpus and displays gl info on them. Do you have suggestions on a new way to get the driver/driver's options info that would work with multiple gpus and Wayland ? My thoughts are that at the beginning of .drirc could be contained info about all drivers's options, and also info about what drivers would be loaded for the detected devices. Driconf and old Mesa would still be able to read the .drirc file, and would ignore the additional section. Yours, Axel Davy ___ 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] mesa/format_info: Add support for the BPTC layout
I'm not sure if we came to a decision about what to do with the
channel bits. I guess it's not really that important because probably
nothing uses it for compressed formats except to check for the
existence of the channels. Here is a v2 patch which picks 8/8/8/8 for
the RGBA formats and 16/16/16 for the half-float formats. Would that
be ok?
I guess we should pick a policy and make it consistent for the other
formats too but perhaps we can leave that to a later patch. It looks
like the NVidia approach might be to return a number of bits that you
would need to create a texture to represent the possible generated
values from the decompressor. However that doesn't quite add up for
the half-float formats because in that case you could accurately
represent the values with a half-float texture and only 16 bits.
If we wanted to pick that policy we would also have to change what we
return for the S3TC formats because they can also return 8 bits of
variance. The ETC2 formats already return 8.
- Neil
--- 8 --- (use git am --scissors to automatically chop here)
Adds the ‘bptc’ layout to get_channel_bits. The channel bits for BPTC depend
on the mode but as it only has to be an approximation this sets it to 8 for
the two UNORM formats and 16 for the two half-float formats. These represent
the minimum number of bits of variation that can be generated by the
interpolation of the two formats.
This doesn't quite match what we do for S3TC which only returns 4 even though
it can similarly generate 8 bits from the interpolation. However it does match
what we return for ETC2. For reference, NVidia seems to return 8 bits for the
UNORM formats and 32 bits for the half-float formats.
v2: Change the number of bits to 8/8/8/8 for the UNORM formats and 16/16/16
for the half-float formats.
---
src/mesa/main/format_info.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
index a0eecd3..7424fe0 100644
--- a/src/mesa/main/format_info.py
+++ b/src/mesa/main/format_info.py
@@ -127,6 +127,9 @@ def get_channel_bits(fmat, chan_name):
bits = 11 if fmat.name.endswith('11_EAC') else 8
return bits if fmat.has_channel(chan_name) else 0
+ elif fmat.layout == 'bptc':
+ bits = 16 if fmat.name.endswith('_FLOAT') else 8
+ return bits if fmat.has_channel(chan_name) else 0
else:
assert False
else:
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 80848] [dri3] Building mesa fails with dri3 enabled
https://bugs.freedesktop.org/show_bug.cgi?id=80848 Eero Tamminen eero.t.tammi...@intel.com changed: What|Removed |Added CC||eero.t.tammi...@intel.com --- Comment #23 from Eero Tamminen eero.t.tammi...@intel.com --- (In reply to comment #22) https://bugs.freedesktop.org/show_bug.cgi?id=50754 Thanks I'll look into it. Thanks, it's pretty embarrasing how long it's been unfixed. -- 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 01/12] i965: Assign PS kernel start pointers when we decide which kernels to use
On Monday, August 11, 2014 11:18:36 PM Ben Widawsky wrote:
On Mon, Aug 11, 2014 at 10:40:25PM -0700, Kenneth Graunke wrote:
On Monday, August 11, 2014 07:53:11 PM Ben Widawsky wrote:
On Mon, Aug 11, 2014 at 05:29:31PM -0700, Kristian Høgsberg wrote:
[snip]
diff --git a/src/mesa/drivers/dri/i965/gen8_ps_state.c
b/src/mesa/drivers/dri/i965/gen8_ps_state.c
index 3d6d7f0..f58d49c 100644
--- a/src/mesa/drivers/dri/i965/gen8_ps_state.c
+++ b/src/mesa/drivers/dri/i965/gen8_ps_state.c
@@ -134,7 +134,7 @@ static void
upload_ps_state(struct brw_context *brw)
{
struct gl_context *ctx = brw-ctx;
- uint32_t dw3 = 0, dw6 = 0, dw7 = 0;
+ uint32_t dw3 = 0, dw6 = 0, dw7 = 0, ksp0, ksp2 = 0;
Should ksp0 and ksp2 be uint64_t? I realize the current code is broken
anyway. (/me makes note for no reloc branch).
It's not necessary. The kernel start pointers are relative to Instruction
State Base Address, which we set to the start of a buffer that contains all
of the shader programs. That buffer isn't going to be bigger than 4GB, so
the offsets will always fit in 32 bits.
--Ken
I was mostly thinking of a future with the ability to OUT_BATCH64, or
OUT_BATCH_KERNEL the pointer (and as a readability thing). I agree it
doesn't have any real impact.
One of the paths I was considering with the no reloc thing was to always
set the state base addresses to be 0 (for everything), and in that case
the kernel start pointer very well could be 4GB. There are other ways
to solve that problem of course, but I felt compelled to justify.
Ah, true - for the no reloc case, that makes a lot of sense. There are a lot
of cases like this to fix up, though, so I'm in favor of punting that change to
after krh's patch series, though.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] docs: add GL4.5 section, mark ARB_texture_barrier as done
On Tue, Aug 12, 2014 at 10:38 AM, Brian Paul bri...@vmware.com wrote: On 08/11/2014 01:07 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of GL4.5? docs/GL3.txt | 16 1 file changed, 16 insertions(+) diff --git a/docs/GL3.txt b/docs/GL3.txt index 7f18cd7..f204652 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -183,5 +183,21 @@ GL 4.4, GLSL 4.40: GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0, r600, radeonsi) +GL 4.5, GLSL 4.50: + + GL_ARB_ES3_1_compatibility not started + GL_ARB_clip_control not started + GL_ARB_conditional_render_inverted not started + GL_ARB_cull_distance not started + GL_ARB_derivative_controlnot started + GL_ARB_direct_state_access not started + GL_ARB_get_texture_sub_image not started Just FYI: I started implementing the new glGetTextureSubImage functions for this extension. Not sure when I'll finish it though... Great, I've updated my local version of the change marking it as you having started it. Shouldn't be too much of a pain to pipe it through to gallium's -blit. (But then there's the question of whether Driver.GetTexImage should get replaced with GetTexSubImage which is a lot of updating of a lot of things...) Looks like there's been great interest in this patch... perhaps someone can also look at my v2 ARB_texture_gather patch :) -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] docs: now distributing the GL/glcorearb.h header
--- docs/relnotes/10.3.html |1 + 1 file changed, 1 insertion(+) diff --git a/docs/relnotes/10.3.html b/docs/relnotes/10.3.html index a1f2777..5aa37ac 100644 --- a/docs/relnotes/10.3.html +++ b/docs/relnotes/10.3.html @@ -63,6 +63,7 @@ Note: some of the new features are only available with certain drivers. liGL_OES_compressed_ETC1_RGB8_texture on nv30, nv50, nvc0, r300, r600, radeonsi, softpipe, llvmpipe/li liA new software rasterizer driver (kms_swrast_dri.so) that works with DRM drivers that don't have a full-fledged GEM (such as qxl or simpledrm)/li +liDistribute the Khronos GL/glcorearb.h header file. /ul -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gbm: Fix gallium build when X11 is in a non-system directory
On 09/08/14 19:10, Eric Anholt wrote: pipe-loader.h will include Xlib.h when HAVE_PIPE_LOADER_XLIB is set in the build. I really need to move all this mayhem (pipe-loader vs static targets) into one place. Reviewed-by: Emil Velikov emil.l.veli...@gmail.com --- src/gallium/state_trackers/gbm/Makefile.am | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/state_trackers/gbm/Makefile.am b/src/gallium/state_trackers/gbm/Makefile.am index 4d9f3fe..50995b3 100644 --- a/src/gallium/state_trackers/gbm/Makefile.am +++ b/src/gallium/state_trackers/gbm/Makefile.am @@ -25,6 +25,7 @@ include $(top_srcdir)/src/gallium/Automake.inc AM_CFLAGS = \ $(GALLIUM_CFLAGS) \ + $(X11_INCLUDES) \ $(VISIBILITY_CFLAGS) AM_CPPFLAGS = \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 06/12] i965: Add optimization pass to let us use the replicate data message
On Monday, August 11, 2014 05:29:36 PM Kristian Høgsberg wrote:
The data port has a SIMD16 'replicate data' message, which lets us write
the same color for all 16 pixels by sending the four floats in the
lower half of a register instead of sending 4 times 16 identical
component values in 8 registers.
The message comes with a lot of restrictions and could be made generally
useful by recognizing when those restriction are satisfied. For now,
this lets us enable the optimization when we know it's safe, but we don't
enable it by default. The optimization works for simple color clear shaders
only, but does recognized and support multiple render targets.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_defines.h | 1 +
src/mesa/drivers/dri/i965/brw_fs.cpp| 56
+
src/mesa/drivers/dri/i965/brw_fs.h | 4 ++
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 5 ++-
src/mesa/drivers/dri/i965/gen8_fs_generator.cpp | 5 ++-
6 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 7de9b64..6ab7713 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1033,6 +1033,7 @@ struct brw_context
bool has_negative_rhw_bug;
bool has_pln;
bool no_simd8;
+ bool use_rep_send;
/**
* Some versions of Gen hardware don't do centroid interpolation correctly
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index a519629..194d35f 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -850,6 +850,7 @@ enum opcode {
*/
FS_OPCODE_FB_WRITE = 128,
FS_OPCODE_BLORP_FB_WRITE,
+ FS_OPCODE_REP_FB_WRITE,
SHADER_OPCODE_RCP,
SHADER_OPCODE_RSQ,
SHADER_OPCODE_SQRT,
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 061c32d..640e222 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -2215,6 +2215,59 @@ fs_visitor::compute_to_mrf()
return progress;
}
+bool
+fs_visitor::try_rep_send()
+{
+ int i, count, step = dispatch_width / 8;
+ fs_inst *start = NULL;
+
+ count = 0;
+ foreach_in_list_safe(fs_inst, inst, this-instructions) {
+ if (count == 0)
+ start = inst;
+ if (inst-opcode == BRW_OPCODE_MOV
+ inst-dst.file == MRF
+ inst-dst.reg == start-dst.reg + step * count
+ inst-src[0].file == HW_REG
+ inst-src[0].reg_offset == start-src[0].reg_offset + count) {
+ if (count == 0)
+start = inst;
+ count++;
+ }
+
+ if (inst-opcode == FS_OPCODE_FB_WRITE
+ count == 4
+ (inst-base_mrf == start-dst.reg ||
+ (inst-base_mrf + 2 == start-dst.reg inst-header_present))) {
+ fs_inst *mov = MOV(start-dst, start-src[0]);
+
+ mov-dst.fixed_hw_reg =
+brw_vec4_reg(BRW_MESSAGE_REGISTER_FILE,
+ start-dst.reg, 0);
+ mov-dst.file = HW_REG;
+ mov-dst.type = mov-dst.fixed_hw_reg.type;
+
+ mov-src[0].fixed_hw_reg =
+brw_vec4_grf(mov-src[0].fixed_hw_reg.nr, 0);
+ mov-src[0].file = HW_REG;
+ mov-src[0].type = mov-src[0].fixed_hw_reg.type;
+ mov-force_writemask_all = true;
+ mov-dst.type = BRW_REGISTER_TYPE_F;
+
+ start-insert_before(mov);
+
+ for (i = 0; i 4; i++)
+mov-next-remove();
+
+ inst-opcode = FS_OPCODE_REP_FB_WRITE;
+ inst-mlen -= 4 * step - 1;
+ count = 0;
+ }
+ }
+
+ return true;
+}
+
I really prefer my version of this function:
http://cgit.freedesktop.org/~kwg/mesa/commit/?h=repdata-clears-v3id=b9bbf54b065fd5eab58367badc96cf997a521e7a
It seems more robust - it guards against predication and various cases when
this can't be used. It also handles immediate values. And it includes
comments.
One clever thing that you've done here is to run after converting UNIFORM
values to HW_REGs, so you can directly use brw_vec4_reg here, rather than
having to introduce a silly MOV_441 opcode like I did. That's pretty nice.
Branch with everything:
http://cgit.freedesktop.org/~kwg/mesa/log/?h=repdata-clears-v3
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] docs: add GL4.5 section, mark ARB_texture_barrier as done
On 08/12/2014 10:13 AM, Ilia Mirkin wrote: On Tue, Aug 12, 2014 at 10:38 AM, Brian Paul bri...@vmware.com wrote: On 08/11/2014 01:07 PM, Ilia Mirkin wrote: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of GL4.5? docs/GL3.txt | 16 1 file changed, 16 insertions(+) diff --git a/docs/GL3.txt b/docs/GL3.txt index 7f18cd7..f204652 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -183,5 +183,21 @@ GL 4.4, GLSL 4.40: GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0, r600, radeonsi) +GL 4.5, GLSL 4.50: + + GL_ARB_ES3_1_compatibility not started + GL_ARB_clip_control not started + GL_ARB_conditional_render_inverted not started + GL_ARB_cull_distance not started + GL_ARB_derivative_controlnot started + GL_ARB_direct_state_access not started + GL_ARB_get_texture_sub_image not started Just FYI: I started implementing the new glGetTextureSubImage functions for this extension. Not sure when I'll finish it though... Great, I've updated my local version of the change marking it as you having started it. Shouldn't be too much of a pain to pipe it through to gallium's -blit. (But then there's the question of whether Driver.GetTexImage should get replaced with GetTexSubImage which is a lot of updating of a lot of things...) Yeah, that's what I did. I'd rather have one driver.GetTexSubImage() function than keep GetTexImage() and have two. The changes aren't that bad. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 04/12] i965: Add a mechanism for sending native primitives into the driver
On Monday, August 11, 2014 05:29:34 PM Kristian Høgsberg wrote: The brw_draw_prims() function is the draw entry point into the driver, and takes struct _mesa_prim for input. We want to be able to feed native primitives into the driver, and to that end we introduce BRW_PRIM_OFFSET, which lets use describe geometry using the native GEN primitive types. Signed-off-by: Kristian Høgsberg k...@bitplanet.net --- src/mesa/drivers/dri/i965/brw_context.h | 2 +- src/mesa/drivers/dri/i965/brw_defines.h | 7 +++ src/mesa/drivers/dri/i965/brw_draw.c| 15 --- src/mesa/drivers/dri/i965/brw_vec4_gs.c | 3 ++- 4 files changed, 22 insertions(+), 5 deletions(-) Patches 3-4 are: Reviewed-by: Kenneth Graunke kenn...@whitecape.org signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965/fs: Remove FS_OPCODE_BLORP_FB_WRITE.
With a few tiny changes, we can just reuse the normal FB write handling.
I originally mistook the FS_OPCODE_BLORP_FB_WRITE opcode for the SIMD16
replicated data message used in certain BLORP color clears, when it was
actually just a normal SIMD16 message without a little bit of setup.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_blorp_blit.cpp| 8 ++--
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 3 ++-
src/mesa/drivers/dri/i965/brw_defines.h | 1 -
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 21 +
src/mesa/drivers/dri/i965/brw_shader.cpp| 2 --
5 files changed, 5 insertions(+), 30 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
index 92c92aa..3e384ed 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit.cpp
@@ -1734,11 +1734,7 @@ brw_blorp_blit_program::render_target_write()
/* If we may have killed pixels, then we need to send R0 and R1 in a header
* so that the render target knows which pixels we killed.
*/
- bool use_header = key-use_kill;
- if (use_header) {
- /* Copy R0/1 to MRF */
- emit_mov(retype(mrf_rt_write, BRW_REGISTER_TYPE_UD),
- retype(R0, BRW_REGISTER_TYPE_UD));
+ if (key-use_kill) {
mrf_offset += 2;
}
@@ -1755,7 +1751,7 @@ brw_blorp_blit_program::render_target_write()
mrf_rt_write,
base_mrf,
mrf_offset /* msg_length. TODO: Should be smaller for non-RGBA formats.
*/,
- use_header);
+ key-use_kill);
}
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
index 5a485df..c20a163 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -94,13 +94,14 @@ brw_blorp_eu_emitter::emit_render_target_write(const struct
brw_reg src0,
unsigned msg_length,
bool use_header)
{
- fs_inst *inst = new (mem_ctx) fs_inst(FS_OPCODE_BLORP_FB_WRITE);
+ fs_inst *inst = new (mem_ctx) fs_inst(FS_OPCODE_FB_WRITE);
inst-src[0] = src0;
inst-base_mrf = msg_reg_nr;
inst-mlen = msg_length;
inst-header_present = use_header;
inst-target = BRW_BLORP_RENDERBUFFER_BINDING_TABLE_INDEX;
+ inst-eot = true;
insts.push_tail(inst);
}
diff --git a/src/mesa/drivers/dri/i965/brw_defines.h
b/src/mesa/drivers/dri/i965/brw_defines.h
index 3564041..658d94d 100644
--- a/src/mesa/drivers/dri/i965/brw_defines.h
+++ b/src/mesa/drivers/dri/i965/brw_defines.h
@@ -842,7 +842,6 @@ enum opcode {
* instructions.
*/
FS_OPCODE_FB_WRITE = 128,
- FS_OPCODE_BLORP_FB_WRITE,
SHADER_OPCODE_RCP,
SHADER_OPCODE_RSQ,
SHADER_OPCODE_SQRT,
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index d3509a0..19f7ef8 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -186,7 +186,7 @@ fs_generator::generate_fb_write(fs_inst *inst)
brw_imm_ud(0x1 11));
}
-if (inst-target 0) {
+if (fp inst-target 0) {
/* Set the render target index for choosing BLEND_STATE. */
brw_MOV(p, retype(brw_vec1_reg(BRW_MESSAGE_REGISTER_FILE,
inst-base_mrf, 2),
@@ -231,21 +231,6 @@ fs_generator::generate_fb_write(fs_inst *inst)
}
}
-void
-fs_generator::generate_blorp_fb_write(fs_inst *inst)
-{
- brw_fb_WRITE(p,
-16 /* dispatch_width */,
-inst-base_mrf,
-brw_reg_from_fs_reg(inst-src[0]),
-BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD16_SINGLE_SOURCE,
-inst-target,
-inst-mlen,
-0,
-true,
-inst-header_present);
-}
-
/* Computes the integer pixel x,y values from the origin.
*
* This is the basis of gl_FragCoord computation, but is also used
@@ -1698,10 +1683,6 @@ fs_generator::generate_code(exec_list *instructions)
generate_fb_write(inst);
break;
- case FS_OPCODE_BLORP_FB_WRITE:
-generate_blorp_fb_write(inst);
-break;
-
case FS_OPCODE_MOV_DISPATCH_TO_FLAGS:
generate_mov_dispatch_to_flags(inst);
break;
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 0033135..e22d1f2 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -402,8 +402,6 @@ brw_instruction_name(enum opcode op)
switch (op) {
case FS_OPCODE_FB_WRITE:
return fb_write;
- case FS_OPCODE_BLORP_FB_WRITE:
- return blorp_fb_write;
case SHADER_OPCODE_RCP:
return rcp;
--
[Mesa-dev] [PATCH 2/2] i965/fs: Only emit FS_OPCODE_PLACEHOLDER_HALT if there are discards.
It's unnecessary, and makes pattern matching for simple clear programs more difficult. Signed-off-by: Kenneth Graunke kenn...@whitecape.org --- src/mesa/drivers/dri/i965/brw_fs.cpp | 3 ++- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp index 3aee822..e79dfc9 100644 --- a/src/mesa/drivers/dri/i965/brw_fs.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp @@ -3036,7 +3036,8 @@ fs_visitor::run() if (failed) return false; - emit(FS_OPCODE_PLACEHOLDER_HALT); + if (fp-UsesKill) + emit(FS_OPCODE_PLACEHOLDER_HALT); if (key-alpha_test_func) emit_alpha_test(); diff --git a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp index c16401b..3ed6e94 100644 --- a/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp +++ b/src/mesa/drivers/dri/i965/brw_fs_visitor.cpp @@ -2061,6 +2061,7 @@ fs_visitor::visit(ir_discard *ir) /* For performance, after a discard, jump to the end of the shader. * Only jump if all relevant channels have been discarded. */ + assert(fp-UsesKill); fs_inst *discard_jump = emit(FS_OPCODE_DISCARD_JUMP); discard_jump-flag_subreg = 1; -- 2.0.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2] mesa/format_info: Add support for the BPTC layout
Sorry, I didn't mean to make that much of a stink. Either's fine with me
as long as we're not doing 32 for half-float.
Reviewed-by: Jason Ekstrand jason.ekstr...@intel.com
On Tue, Aug 12, 2014 at 8:09 AM, Neil Roberts n...@linux.intel.com wrote:
I'm not sure if we came to a decision about what to do with the
channel bits. I guess it's not really that important because probably
nothing uses it for compressed formats except to check for the
existence of the channels. Here is a v2 patch which picks 8/8/8/8 for
the RGBA formats and 16/16/16 for the half-float formats. Would that
be ok?
I guess we should pick a policy and make it consistent for the other
formats too but perhaps we can leave that to a later patch. It looks
like the NVidia approach might be to return a number of bits that you
would need to create a texture to represent the possible generated
values from the decompressor. However that doesn't quite add up for
the half-float formats because in that case you could accurately
represent the values with a half-float texture and only 16 bits.
If we wanted to pick that policy we would also have to change what we
return for the S3TC formats because they can also return 8 bits of
variance. The ETC2 formats already return 8.
- Neil
--- 8 --- (use git am --scissors to automatically chop
here)
Adds the ‘bptc’ layout to get_channel_bits. The channel bits for BPTC
depend
on the mode but as it only has to be an approximation this sets it to 8 for
the two UNORM formats and 16 for the two half-float formats. These
represent
the minimum number of bits of variation that can be generated by the
interpolation of the two formats.
This doesn't quite match what we do for S3TC which only returns 4 even
though
it can similarly generate 8 bits from the interpolation. However it does
match
what we return for ETC2. For reference, NVidia seems to return 8 bits for
the
UNORM formats and 32 bits for the half-float formats.
v2: Change the number of bits to 8/8/8/8 for the UNORM formats and 16/16/16
for the half-float formats.
---
src/mesa/main/format_info.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/mesa/main/format_info.py b/src/mesa/main/format_info.py
index a0eecd3..7424fe0 100644
--- a/src/mesa/main/format_info.py
+++ b/src/mesa/main/format_info.py
@@ -127,6 +127,9 @@ def get_channel_bits(fmat, chan_name):
bits = 11 if fmat.name.endswith('11_EAC') else 8
return bits if fmat.has_channel(chan_name) else 0
+ elif fmat.layout == 'bptc':
+ bits = 16 if fmat.name.endswith('_FLOAT') else 8
+ return bits if fmat.has_channel(chan_name) else 0
else:
assert False
else:
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] i965/vec4: Set NoMask for GS_OPCODE_SET_VERTEX_COUNT on Gen8+.
Series is Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Store uniform constant values in a gl_constant_value instead of float
Hi,
Here is a replacement patch for the one to use memcpy when copying
uniform values into the batch buffer here:
http://lists.freedesktop.org/archives/mesa-dev/2014-August/065179.html
Eric Anholt suggested instead of using memcpy we should change the
type of the pointer to uint32_t. I started to implement that idea but
I found there were quite a few bits of debugging code that are trying
to print the values as floats. I thought it might be cleaner if we
make the pointers gl_constant_value instead because that will avoid
having ugly casts in this debugging code and also makes it more
obvious that the values are being overloaded.
This patch also ends up fixing a few other potential problems in
places where we are copying floatings for example when copying into
the pull params.
I've run the patch through all of the Piglit tests on Ivybridge with a
32-bit build and it doesn't cause any changes except to fix the five
test cases mentioned in the bug report.
- Neil
--- 8 --- (use git am --scissors to automatically chop here)
The brw_stage_prog_data struct previously contained an array of float pointers
to the values of parameters. These were then copied into a batch buffer to
upload the values using a regular assignment. However the float values were
also being overloaded to store integer values for integer uniforms. This can
break if x87 floating-point registers are used to do the assignment because
the fst instruction tries to fix up invalid float values. If an integer
constant happened to look like an invalid float value then it would get
altered when it was copied into the batch buffer.
This patch changes the pointers to be gl_constant_value instead so that the
assignment should end up copying without any alteration. This also makes it
more obvious that the values being stored here are overloaded for multiple
types.
There are some static asserts where the values are uploaded to ensure that the
size of gl_constant_value is the same as a float.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81150
---
src/mesa/drivers/dri/i965/brw_context.h | 5 +++--
src/mesa/drivers/dri/i965/brw_curbe.c| 22 --
src/mesa/drivers/dri/i965/brw_fs.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_vec4_gs.c | 4 ++--
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 13 -
src/mesa/drivers/dri/i965/brw_vec4_vp.cpp| 4 ++--
src/mesa/drivers/dri/i965/brw_vs.c | 6 --
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 ++
src/mesa/drivers/dri/i965/brw_wm.c | 5 +++--
src/mesa/drivers/dri/i965/gen6_vs_state.c| 8 +---
13 files changed, 55 insertions(+), 42 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 1bbcf46..157a605 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -41,6 +41,7 @@
#include main/mtypes.h
#include brw_structs.h
#include intel_aub.h
+#include program/prog_parameter.h
#ifdef __cplusplus
extern C {
@@ -309,8 +310,8 @@ struct brw_stage_prog_data {
* These must be the last fields of the struct (see
* brw_stage_prog_data_compare()).
*/
- const float **param;
- const float **pull_param;
+ const gl_constant_value **param;
+ const gl_constant_value **pull_param;
};
/* Data about a particular attempt to compile a program. Note that
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index 02eda5f..1a828ed 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -196,7 +196,7 @@ brw_upload_constant_buffer(struct brw_context *brw)
/* BRW_NEW_CURBE_OFFSETS */
const GLuint sz = brw-curbe.total_size;
const GLuint bufsz = sz * 16 * sizeof(GLfloat);
- GLfloat *buf;
+ gl_constant_value *buf;
GLuint i;
gl_clip_plane *clip_planes;
@@ -207,6 +207,8 @@ brw_upload_constant_buffer(struct brw_context *brw)
buf = intel_upload_space(brw, bufsz, 64,
brw-curbe.curbe_bo, brw-curbe.curbe_offset);
+ STATIC_ASSERT(sizeof(gl_constant_value) == sizeof(float));
+
/* fragment shader constants */
if (brw-curbe.wm_size) {
/* BRW_NEW_CURBE_OFFSETS */
@@ -226,10 +228,10 @@ brw_upload_constant_buffer(struct brw_context *brw)
/* If any planes are going this way, send them all this way:
*/
for (i = 0; i 6; i++) {
-buf[offset + i * 4 + 0] = fixed_plane[i][0];
-buf[offset + i * 4 + 1] = fixed_plane[i][1];
-buf[offset + i * 4 + 2] = fixed_plane[i][2];
-buf[offset + i * 4 + 3] = fixed_plane[i][3];
+buf[offset + i * 4 + 0].f =
Re: [Mesa-dev] [PATCH 2/2] docs: now distributing the GL/glcorearb.h header
Both are Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa: update wglext.h to version 20140810
These, plus the mangle regeneration are Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] gallium/r300: Fix a link error in the tests
The link error occurs because the static libraries are linked in the wrong order. This fixes it. Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82483 --- src/gallium/drivers/r300/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/r300/Makefile.am b/src/gallium/drivers/r300/Makefile.am index ae6e8d2..e74e445 100644 --- a/src/gallium/drivers/r300/Makefile.am +++ b/src/gallium/drivers/r300/Makefile.am @@ -18,8 +18,8 @@ check_PROGRAMS = r300_compiler_tests TESTS = r300_compiler_tests r300_compiler_tests_LDADD = libr300.la libr300-helper.la \ - $(top_builddir)/src/util/libmesautil.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(GALLIUM_COMMON_LIB_DEPS) r300_compiler_tests_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/drivers/r300/compiler -- 2.0.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Store uniform constant values in a gl_constant_value instead of float
This looks good to me. However I'm wondering if it would be better to
use a generic float/int union. I guess though these values actually
really are gl_constant_value type (as they come as gl params) so this
looks good.
Roland
Am 12.08.2014 20:04, schrieb Neil Roberts:
Hi,
Here is a replacement patch for the one to use memcpy when copying
uniform values into the batch buffer here:
https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/archives/mesa-dev/2014-August/065179.htmlk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=ncVDxLJN0VB1NhIOJ5egzyvs0mgOh%2BTUNiisFv%2BIDIk%3D%0As=f4b3fa9e5baf4d613e672b238b05ed84529aaa97eac86244a3325912d85b5e9d
Eric Anholt suggested instead of using memcpy we should change the
type of the pointer to uint32_t. I started to implement that idea but
I found there were quite a few bits of debugging code that are trying
to print the values as floats. I thought it might be cleaner if we
make the pointers gl_constant_value instead because that will avoid
having ugly casts in this debugging code and also makes it more
obvious that the values are being overloaded.
This patch also ends up fixing a few other potential problems in
places where we are copying floatings for example when copying into
the pull params.
I've run the patch through all of the Piglit tests on Ivybridge with a
32-bit build and it doesn't cause any changes except to fix the five
test cases mentioned in the bug report.
- Neil
--- 8 --- (use git am --scissors to automatically chop here)
The brw_stage_prog_data struct previously contained an array of float pointers
to the values of parameters. These were then copied into a batch buffer to
upload the values using a regular assignment. However the float values were
also being overloaded to store integer values for integer uniforms. This can
break if x87 floating-point registers are used to do the assignment because
the fst instruction tries to fix up invalid float values. If an integer
constant happened to look like an invalid float value then it would get
altered when it was copied into the batch buffer.
This patch changes the pointers to be gl_constant_value instead so that the
assignment should end up copying without any alteration. This also makes it
more obvious that the values being stored here are overloaded for multiple
types.
There are some static asserts where the values are uploaded to ensure that the
size of gl_constant_value is the same as a float.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D81150k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=ncVDxLJN0VB1NhIOJ5egzyvs0mgOh%2BTUNiisFv%2BIDIk%3D%0As=806b5a3faa9c146303663d1d35b76fc847fb83ba5f7f3adb2a238f2e1b64ec37
---
src/mesa/drivers/dri/i965/brw_context.h | 5 +++--
src/mesa/drivers/dri/i965/brw_curbe.c| 22 --
src/mesa/drivers/dri/i965/brw_fs.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 +++---
src/mesa/drivers/dri/i965/brw_vec4_gs.c | 4 ++--
src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 13 -
src/mesa/drivers/dri/i965/brw_vec4_vp.cpp| 4 ++--
src/mesa/drivers/dri/i965/brw_vs.c | 6 --
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 ++
src/mesa/drivers/dri/i965/brw_wm.c | 5 +++--
src/mesa/drivers/dri/i965/gen6_vs_state.c| 8 +---
13 files changed, 55 insertions(+), 42 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 1bbcf46..157a605 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -41,6 +41,7 @@
#include main/mtypes.h
#include brw_structs.h
#include intel_aub.h
+#include program/prog_parameter.h
#ifdef __cplusplus
extern C {
@@ -309,8 +310,8 @@ struct brw_stage_prog_data {
* These must be the last fields of the struct (see
* brw_stage_prog_data_compare()).
*/
- const float **param;
- const float **pull_param;
+ const gl_constant_value **param;
+ const gl_constant_value **pull_param;
};
/* Data about a particular attempt to compile a program. Note that
diff --git a/src/mesa/drivers/dri/i965/brw_curbe.c
b/src/mesa/drivers/dri/i965/brw_curbe.c
index 02eda5f..1a828ed 100644
--- a/src/mesa/drivers/dri/i965/brw_curbe.c
+++ b/src/mesa/drivers/dri/i965/brw_curbe.c
@@ -196,7 +196,7 @@ brw_upload_constant_buffer(struct brw_context *brw)
/* BRW_NEW_CURBE_OFFSETS */
const GLuint sz = brw-curbe.total_size;
const GLuint bufsz = sz * 16 * sizeof(GLfloat);
- GLfloat *buf;
+
Re: [Mesa-dev] [PATCH] gallium/r300: Fix a link error in the tests
On Tue, Aug 12, 2014 at 11:14:06AM -0700, Jason Ekstrand wrote: The link error occurs because the static libraries are linked in the wrong order. This fixes it. Reviewed-by: Tom Stellard thomas.stell...@amd.com Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82483 --- src/gallium/drivers/r300/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/drivers/r300/Makefile.am b/src/gallium/drivers/r300/Makefile.am index ae6e8d2..e74e445 100644 --- a/src/gallium/drivers/r300/Makefile.am +++ b/src/gallium/drivers/r300/Makefile.am @@ -18,8 +18,8 @@ check_PROGRAMS = r300_compiler_tests TESTS = r300_compiler_tests r300_compiler_tests_LDADD = libr300.la libr300-helper.la \ - $(top_builddir)/src/util/libmesautil.la \ $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/util/libmesautil.la \ $(GALLIUM_COMMON_LIB_DEPS) r300_compiler_tests_CPPFLAGS = \ -I$(top_srcdir)/src/gallium/drivers/r300/compiler -- 2.0.4 ___ 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] [Bug 82483] format_srgb.h:145: undefined reference to `util_format_srgb_to_linear_8unorm_table'
https://bugs.freedesktop.org/show_bug.cgi?id=82483 Jason Ekstrand ja...@jlekstrand.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Jason Ekstrand ja...@jlekstrand.net --- Fixed by 97d57f1142db2a11189a2c9a174f9f69fd5a298d -- 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] i965: Return NONE from brw_swap_cmod on unknown input.
On Mon, Aug 11, 2014 at 11:22 AM, Matt Turner matts...@gmail.com wrote:
Comparing ~0u with a packed enum (i.e., 1 byte) always evaluates to
false. Shouldn't gcc warn about this?
Reported-by: Connor Abbott cwabbo...@gmail.com
---
src/mesa/drivers/dri/i965/brw_eu.c | 2 +-
src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_eu.c
b/src/mesa/drivers/dri/i965/brw_eu.c
index b4d5d88..9905972 100644
--- a/src/mesa/drivers/dri/i965/brw_eu.c
+++ b/src/mesa/drivers/dri/i965/brw_eu.c
@@ -84,7 +84,7 @@ brw_swap_cmod(uint32_t cmod)
case BRW_CONDITIONAL_LE:
return BRW_CONDITIONAL_GE;
default:
- return ~0;
+ return BRW_CONDITIONAL_NONE;
}
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
index 0716202..498e078 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_copy_propagation.cpp
@@ -440,7 +440,7 @@ try_constant_propagate(struct brw_context *brw, fs_inst
*inst,
enum brw_conditional_mod new_cmod;
new_cmod = brw_swap_cmod(inst-conditional_mod);
-if (new_cmod != ~0u) {
+if (new_cmod != BRW_CONDITIONAL_NONE) {
/* Fit this constant in by swapping the operands and
* flipping the test
*/
diff --git a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
index 390448a..28f162d 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4_copy_propagation.cpp
@@ -165,7 +165,7 @@ try_constant_propagate(struct brw_context *brw,
vec4_instruction *inst,
enum brw_conditional_mod new_cmod;
new_cmod = brw_swap_cmod(inst-conditional_mod);
-if (new_cmod != ~0u) {
+if (new_cmod != BRW_CONDITIONAL_NONE) {
/* Fit this constant in by swapping the operands and
* flipping the test.
*/
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Reviewed-by: Connor Abbott cwabbo...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Second derivatives and ARB_derivative_control
Hello, I was looking at the ARB_derivative_control spec and it has this bit: It is typical to consider a 2x2 square of fragments or samples, and compute independent dFdxFine per row and independent dFdyFine per column, while computing only a single dFdxCoarse and a single dFdyCoarse for the entire 2x2 square. Thus, all second-order coarse derivatives, e.g., dFdxCoarse(dFdxCoarse(x)), may be 0, even for non-linear arguments. However, second-order fine derivatives, e.g., dFdxFine(dFdxFine(x)) will properly reflect the difference between the independent fine derivatives computed within the 2x2 square. The first bit makes sense -- only one dFdxFine value is computed per row. However then they go on to second derivatives... that can't possibly work, right? dFdyFine(dFdxFine(x)) would work, since each row would have a different dFdxFine(x) value, but not dFdxFine(dFdxFine(x)). Is this a spec bug, or is one supposed to reach outside of the current 2x2 square? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82327] FAIL: glcpp/tests/glcpp-test-cr-lf
https://bugs.freedesktop.org/show_bug.cgi?id=82327 --- Comment #2 from Vinson Lee v...@freedesktop.org --- mesa: ab66b196699b80cc32cf00fa7cd794cfa992cf3c (master 10.3.0-devel) glcpp-test-cr-lf fails on FreeBSD. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82159] No rule to make target `../../../../src/mesa/libmesa.la', needed by `collision'.
https://bugs.freedesktop.org/show_bug.cgi?id=82159 Vinson Lee v...@freedesktop.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vinson Lee v...@freedesktop.org --- commit 1d47f67455d76e5b76c935df6d30b1748e81744d Author: Jason Ekstrand jason.ekstr...@intel.com Date: Mon Aug 4 16:45:27 2014 -0700 util/tests/hash_table: Link against libmesautil instead of libmesa Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82159 Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com Reviewed-by: Emil Velikov emil.l.veli...@gmail.com -- 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] Second derivatives and ARB_derivative_control
On Tue, Aug 12, 2014 at 3:08 PM, Ilia Mirkin imir...@alum.mit.edu wrote: Hello, I was looking at the ARB_derivative_control spec and it has this bit: It is typical to consider a 2x2 square of fragments or samples, and compute independent dFdxFine per row and independent dFdyFine per column, while computing only a single dFdxCoarse and a single dFdyCoarse for the entire 2x2 square. Thus, all second-order coarse derivatives, e.g., dFdxCoarse(dFdxCoarse(x)), may be 0, even for non-linear arguments. However, second-order fine derivatives, e.g., dFdxFine(dFdxFine(x)) will properly reflect the difference between the independent fine derivatives computed within the 2x2 square. The first bit makes sense -- only one dFdxFine value is computed per row. However then they go on to second derivatives... that can't possibly work, right? dFdyFine(dFdxFine(x)) would work, since each row would have a different dFdxFine(x) value, but not dFdxFine(dFdxFine(x)). Is this a spec bug, or is one supposed to reach outside of the current 2x2 square? Aha, noticed this at the bottom of the spec: 2. Define higher-order derivatives? Currently we say they are undefined, but don't see why they can't say more (like coarse is 0, and fine might be something you'd expect). dFdxFine(dFdyFine(a)) should work dFdxCoarse(dFdyCoarse(a)) should work or be 0 Generally, the descriptive part of the derivative section may need slight tweaking, based on the decisions made. Resolution: Yes, be more specific about how higher-order derivitives behave. See the changes to the descriptive part of section 8.13.1. So I guess it's a typo earlier in the spec to say that dFdxFine(dFdxFine(x)) should work. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Store uniform constant values in a gl_constant_value instead of float
On Tuesday, August 12, 2014 07:04:23 PM Neil Roberts wrote: Hi, Here is a replacement patch for the one to use memcpy when copying uniform values into the batch buffer here: http://lists.freedesktop.org/archives/mesa-dev/2014-August/065179.html Eric Anholt suggested instead of using memcpy we should change the type of the pointer to uint32_t. I started to implement that idea but I found there were quite a few bits of debugging code that are trying to print the values as floats. I thought it might be cleaner if we make the pointers gl_constant_value instead because that will avoid having ugly casts in this debugging code and also makes it more obvious that the values are being overloaded. This patch also ends up fixing a few other potential problems in places where we are copying floatings for example when copying into the pull params. I've run the patch through all of the Piglit tests on Ivybridge with a 32-bit build and it doesn't cause any changes except to fix the five test cases mentioned in the bug report. - Neil --- 8 --- (use git am --scissors to automatically chop here) The brw_stage_prog_data struct previously contained an array of float pointers to the values of parameters. These were then copied into a batch buffer to upload the values using a regular assignment. However the float values were also being overloaded to store integer values for integer uniforms. This can break if x87 floating-point registers are used to do the assignment because the fst instruction tries to fix up invalid float values. If an integer constant happened to look like an invalid float value then it would get altered when it was copied into the batch buffer. This patch changes the pointers to be gl_constant_value instead so that the assignment should end up copying without any alteration. This also makes it more obvious that the values being stored here are overloaded for multiple types. There are some static asserts where the values are uploaded to ensure that the size of gl_constant_value is the same as a float. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81150 --- src/mesa/drivers/dri/i965/brw_context.h | 5 +++-- src/mesa/drivers/dri/i965/brw_curbe.c| 22 -- src/mesa/drivers/dri/i965/brw_fs.cpp | 6 +++--- src/mesa/drivers/dri/i965/brw_fs_fp.cpp | 2 +- src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 6 +++--- src/mesa/drivers/dri/i965/brw_vec4.cpp | 6 +++--- src/mesa/drivers/dri/i965/brw_vec4_gs.c | 4 ++-- src/mesa/drivers/dri/i965/brw_vec4_visitor.cpp | 13 - src/mesa/drivers/dri/i965/brw_vec4_vp.cpp| 4 ++-- src/mesa/drivers/dri/i965/brw_vs.c | 6 -- src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 ++ src/mesa/drivers/dri/i965/brw_wm.c | 5 +++-- src/mesa/drivers/dri/i965/gen6_vs_state.c| 8 +--- 13 files changed, 55 insertions(+), 42 deletions(-) Reviewed-by: Kenneth Graunke kenn...@whitecape.org signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 10/19] i965/gen6 depth surface: calculate minimum array element being rendered
On Friday, August 01, 2014 12:43:38 PM Jordan Justen wrote:
On Fri, Aug 1, 2014 at 2:44 AM, Pohjolainen, Topi
topi.pohjolai...@intel.com wrote:
On Fri, Aug 01, 2014 at 12:53:40AM -0700, Jordan Justen wrote:
(a23cfb8 for gen6)
In layered rendering this will be 0. Otherwise it will be the
selected slice.
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
---
src/mesa/drivers/dri/i965/gen6_blorp.cpp | 3 +++
src/mesa/drivers/dri/i965/gen6_depth_state.c | 10 ++
2 files changed, 13 insertions(+)
diff --git a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
index 131c4aa..ff1732d 100644
--- a/src/mesa/drivers/dri/i965/gen6_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen6_blorp.cpp
@@ -793,6 +793,7 @@ gen6_blorp_emit_depth_stencil_config(struct
brw_context *brw,
uint32_t tile_mask_x, tile_mask_y;
uint32_t surftype;
unsigned int depth = MAX2(params-depth.mt-logical_depth0, 1);
+ unsigned int min_array_element;
GLenum gl_target = params-depth.mt-target;
unsigned int lod;
@@ -818,6 +819,8 @@ gen6_blorp_emit_depth_stencil_config(struct
brw_context *brw,
NULL,
tile_mask_x, tile_mask_y);
+ min_array_element = params-depth.layer;
This could be slightly simpler:
const unsigned min_array_element = params-depth.layer;
+
lod = params-depth.level - params-depth.mt-first_level;
/* 3DSTATE_DEPTH_BUFFER */
diff --git a/src/mesa/drivers/dri/i965/gen6_depth_state.c
b/src/mesa/drivers/dri/i965/gen6_depth_state.c
index 1f36ed8..5e3981c 100644
--- a/src/mesa/drivers/dri/i965/gen6_depth_state.c
+++ b/src/mesa/drivers/dri/i965/gen6_depth_state.c
@@ -48,6 +48,7 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
struct gl_framebuffer *fb = ctx-DrawBuffer;
uint32_t surftype;
unsigned int depth = 1;
+ unsigned int min_array_element;
GLenum gl_target = GL_TEXTURE_2D;
unsigned int lod;
const struct intel_renderbuffer *irb = NULL;
@@ -100,6 +101,15 @@ gen6_emit_depth_stencil_hiz(struct brw_context *brw,
break;
}
+ if (fb-MaxNumLayers 0 || !irb) {
+ min_array_element = 0;
+ } else if (irb-mt-num_samples 1) {
+ /* Convert physical layer to logical layer. */
+ min_array_element = irb-mt_layer / irb-mt-num_samples;
I still don't understand this. This would be needed only for surfaces were
samples indices are in their own layers. On gen6 this is never the case as
all the surfaces are interleaved (i.e., samples are in the same physical
layer). Moreover, this is true also on gen7 for depth surfaces - and hence
I'm also questioning the existing logic in the gen7 specific path.
I looked again, and I think gen7/gen8 does not divide by num_samples
for depth state. (Chris changed this in 77d55ef4.) It does in
gen7_wm_surface_state.c.
A piglit run verifies that this works for gen6:
const unsigned min_array_element = irb ? irb-mt_layer : 0;
This matches gen7 gen8 for depth state, so I'll change to this.
Would that get an r-b from you for this patch?
That would get a R-b from me.
But delving further into the divide by num_samples question,
git grep -C5 mt_layer = src/mesa/drivers/dri/i965
turned up some interesting results.
intel_fbo.c:
irb-mt_layer = layer_multiplier * layer;
(For gen7+ UMS/CMS layer_multiplier = mt-num_samples)
intel_fbo.h:
* Note: for a 2D multisample array texture on Gen7+ using
* INTEL_MSAA_LAYOUT_UMS or INTEL_MSAA_LAYOUT_CMS, mt_layer is the physical
* layer holding sample 0. So, for example, if mt-num_samples == 4, then
* logical layer n corresponds to mt_layer == 4*n.
intel_mipmap_tree.c:compute_msaa_layout always returns IMS for depth,
so that explains why in all cases we don't divide by num_samples for
depth.
It might be better to make a helper routine that adjusts layer based
on the msaa layout type. Basically if UMS/CMS, divide by num_samples.
Right now there is a lot of code path knowledge in this calculation.
For instance:
* on depth paths we are using IMS, so don't divide
* on gen6 we only use IMS for color, so don't divide
* on gen7/8 color, we are using UMS/CMS, so divide
-Jordan
I like that idea. You could probably do it as a follow-up, if you like.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 14/19] i965: Change mipmap array_spacing_lod0 to array_layout (enum)
On Friday, August 01, 2014 12:53:44 AM Jordan Justen wrote:
We will want to setup gen6 separate stencil and hiz miptrees in a
layout that is similar to array_spacing_lod0. This is needed because
gen6 hiz and stencil only support a single mip-level.
In both use cases (gen7+ LOD0 spacing gen6 separate stencil/hiz),
the array slices will be packed at each LOD without reserving extra
space for LODs within each array slice.
So, we generalize the name of this field and add comments to indicate
the old and new uses.
Motivation for the gen6 change comes from the PRM:
PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
to [DevSNB]:
The separate stencil buffer does not support mip mapping, thus the
storage for LODs other than LOD 0 is not needed.
PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
[DevSNB]: The hierarchical depth buffer does not support the LOD
field, it is assumed by hardware to be zero. A separate
hierarachical depth buffer is required for each LOD used, and the
corresponding buffer’s state delivered to hardware each time a new
depth buffer state with modified LOD is delivered.
v2:
* Rename array_spacing_lod0 to non_mip_arrays
v3:
* Instead, replace array_spacing_lod0 with array_layout enum
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_blorp.h | 10 ++---
src/mesa/drivers/dri/i965/brw_tex_layout.c| 2 +-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 6 ++---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 27
++-
7 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index b57721c..6b161c9 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -82,7 +82,7 @@ brw_blorp_surface_info::set(struct brw_context *brw,
{
brw_blorp_mip_info::set(mt, level, layer);
this-num_samples = mt-num_samples;
- this-array_spacing_lod0 = mt-array_spacing_lod0;
+ this-array_layout = mt-array_layout;
this-map_stencil_as_y_tiled = false;
this-msaa_layout = mt-msaa_layout;
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 683f09e..a301724 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -150,10 +150,14 @@ public:
unsigned num_samples;
- /* Setting this flag indicates that the surface should be set up in
-* ARYSPC_LOD0 mode. Ignored prior to Gen7.
+ /**
+* Indicates if we use the standard miptree layout
(ALL_LOD_IN_EACH_SLICE),
+* or if we tightly pack array slices at each LOD
(ALL_SLICES_AT_EACH_LOD).
+*
+* If ALL_SLICES_AT_EACH_LOD is set, then ARYSPC_LOD0 can be used. Ignored
+* prior to Gen7.
*/
- bool array_spacing_lod0;
+ enum miptree_array_layout array_layout;
/**
* Format that should be used when setting up the surface state for this
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 76044b2..1ed62a6 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -241,7 +241,7 @@ brw_miptree_layout_texture_array(struct brw_context *brw,
h0 = ALIGN(mt-physical_height0, mt-align_h);
h1 = ALIGN(minify(mt-physical_height0, 1), mt-align_h);
- if (mt-array_spacing_lod0)
+ if (mt-array_layout == ALL_SLICES_AT_EACH_LOD)
mt-qpitch = h0;
else
mt-qpitch = (h0 + h1 + (brw-gen = 7 ? 12 : 11) * mt-align_h);
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 0ad570b..fee25f7 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -169,7 +169,7 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
if (surface-mt-align_w == 8)
surf[0] |= GEN7_SURFACE_HALIGN_8;
- if (surface-array_spacing_lod0)
+ if (surface-array_layout == ALL_SLICES_AT_EACH_LOD)
surf[0] |= GEN7_SURFACE_ARYSPC_LOD0;
else
surf[0] |= GEN7_SURFACE_ARYSPC_FULL;
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 01120af..a11106f 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@ -315,7 +315,7 @@ gen7_update_texture_surface(struct gl_context *ctx,
uint32_t effective_depth = (tObj-Immutable tObj-Target !=
GL_TEXTURE_3D)
?
Re: [Mesa-dev] [PATCH v3 14/19] i965: Change mipmap array_spacing_lod0 to array_layout (enum)
On Tuesday, August 12, 2014 02:06:31 PM Kenneth Graunke wrote:
On Friday, August 01, 2014 12:53:44 AM Jordan Justen wrote:
We will want to setup gen6 separate stencil and hiz miptrees in a
layout that is similar to array_spacing_lod0. This is needed because
gen6 hiz and stencil only support a single mip-level.
In both use cases (gen7+ LOD0 spacing gen6 separate stencil/hiz),
the array slices will be packed at each LOD without reserving extra
space for LODs within each array slice.
So, we generalize the name of this field and add comments to indicate
the old and new uses.
Motivation for the gen6 change comes from the PRM:
PRM Volume 1, Part 1, 7.18.3.7.2 For separate stencil buffer [DevILK]
to [DevSNB]:
The separate stencil buffer does not support mip mapping, thus the
storage for LODs other than LOD 0 is not needed.
PRM Volume 2, Part 1, 7.5.3 Hierarchical Depth Buffer
[DevSNB]: The hierarchical depth buffer does not support the LOD
field, it is assumed by hardware to be zero. A separate
hierarachical depth buffer is required for each LOD used, and the
corresponding buffer’s state delivered to hardware each time a new
depth buffer state with modified LOD is delivered.
v2:
* Rename array_spacing_lod0 to non_mip_arrays
v3:
* Instead, replace array_spacing_lod0 with array_layout enum
Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
Reviewed-by: Topi Pohjolainen topi.pohjolai...@intel.com
---
src/mesa/drivers/dri/i965/brw_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_blorp.h | 10 ++---
src/mesa/drivers/dri/i965/brw_tex_layout.c| 2 +-
src/mesa/drivers/dri/i965/gen7_blorp.cpp | 2 +-
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 6 ++---
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 9
src/mesa/drivers/dri/i965/intel_mipmap_tree.h | 27
++-
7 files changed, 39 insertions(+), 19 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.cpp
b/src/mesa/drivers/dri/i965/brw_blorp.cpp
index b57721c..6b161c9 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp.cpp
@@ -82,7 +82,7 @@ brw_blorp_surface_info::set(struct brw_context *brw,
{
brw_blorp_mip_info::set(mt, level, layer);
this-num_samples = mt-num_samples;
- this-array_spacing_lod0 = mt-array_spacing_lod0;
+ this-array_layout = mt-array_layout;
this-map_stencil_as_y_tiled = false;
this-msaa_layout = mt-msaa_layout;
diff --git a/src/mesa/drivers/dri/i965/brw_blorp.h
b/src/mesa/drivers/dri/i965/brw_blorp.h
index 683f09e..a301724 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp.h
+++ b/src/mesa/drivers/dri/i965/brw_blorp.h
@@ -150,10 +150,14 @@ public:
unsigned num_samples;
- /* Setting this flag indicates that the surface should be set up in
-* ARYSPC_LOD0 mode. Ignored prior to Gen7.
+ /**
+* Indicates if we use the standard miptree layout
(ALL_LOD_IN_EACH_SLICE),
+* or if we tightly pack array slices at each LOD
(ALL_SLICES_AT_EACH_LOD).
+*
+* If ALL_SLICES_AT_EACH_LOD is set, then ARYSPC_LOD0 can be used.
Ignored
+* prior to Gen7.
*/
- bool array_spacing_lod0;
+ enum miptree_array_layout array_layout;
/**
* Format that should be used when setting up the surface state for this
diff --git a/src/mesa/drivers/dri/i965/brw_tex_layout.c
b/src/mesa/drivers/dri/i965/brw_tex_layout.c
index 76044b2..1ed62a6 100644
--- a/src/mesa/drivers/dri/i965/brw_tex_layout.c
+++ b/src/mesa/drivers/dri/i965/brw_tex_layout.c
@@ -241,7 +241,7 @@ brw_miptree_layout_texture_array(struct brw_context
*brw,
h0 = ALIGN(mt-physical_height0, mt-align_h);
h1 = ALIGN(minify(mt-physical_height0, 1), mt-align_h);
- if (mt-array_spacing_lod0)
+ if (mt-array_layout == ALL_SLICES_AT_EACH_LOD)
mt-qpitch = h0;
else
mt-qpitch = (h0 + h1 + (brw-gen = 7 ? 12 : 11) * mt-align_h);
diff --git a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
index 0ad570b..fee25f7 100644
--- a/src/mesa/drivers/dri/i965/gen7_blorp.cpp
+++ b/src/mesa/drivers/dri/i965/gen7_blorp.cpp
@@ -169,7 +169,7 @@ gen7_blorp_emit_surface_state(struct brw_context *brw,
if (surface-mt-align_w == 8)
surf[0] |= GEN7_SURFACE_HALIGN_8;
- if (surface-array_spacing_lod0)
+ if (surface-array_layout == ALL_SLICES_AT_EACH_LOD)
surf[0] |= GEN7_SURFACE_ARYSPC_LOD0;
else
surf[0] |= GEN7_SURFACE_ARYSPC_FULL;
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 01120af..a11106f 100644
--- a/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/gen7_wm_surface_state.c
@@
Re: [Mesa-dev] [PATCH v3 16/19] i965: Support array_layout == ALL_SLICES_AT_EACH_LOD for multiple LODs
On Friday, August 01, 2014 12:53:46 AM Jordan Justen wrote: Previously array_layout ALL_SLICES_AT_EACH_LOD was only used for array spacing lod0 on gen7+ and therefore was only used with a single mip level. gen6 separate stencil hiz only support LOD0, so we need to allocate the miptree similar to gen7+ array spacing lod0, except we also need space for multiple mip levels. (Since OpenGL stencil and depth support multiple LODs.) The miptree is allocated with tightly packed array slice spacing, but we still also pack the miplevels into the region similar to a normal multi mip level packing. A 2D Array texture with 2 slices and multiple LODs would look somewhat like this: +--+ | | | | +--+ | | | | +--+ +---+ +-+ | | +-+ +---+ +-+ | | : +---+ It'd be great to include this diagram in the comment for the ALL_SLICES_AT_EACH_LOD enum value definition. It might also be worth mentioning that this is not a hardware layout - the hardware only sees one particular miplevel's array slices, and thinks LOD = 0, treating as a non-mipmapped surface. This trick simply allows us to store multiple array textures in a single BO. Patches 1-12 are: Reviewed-by: Kenneth Graunke kenn...@whitecape.org Patches 13-19 are: Acked-by: Kenneth Graunke kenn...@whitecape.org I've looked them over, and I think they're doing the right thing, but I haven't invested the time to try and untangle it completely. Assuming there are no regressions on Gen7 (IVB, BYT, HSW, whatever you have handy), then I'd say go ahead and push this series. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: guard better when building with sse4.1 optimisations
On Fri, Aug 1, 2014 at 9:06 AM, Emil Velikov emil.l.veli...@gmail.com wrote:
When the compiler is not capable/does not accept -msse4.1 while the target
has the instruction set we'll blow up as _mesa_streaming_load_memcpy is
going to be undefined.
To make sure that never happens, wrap the runtime cpu check+caller in an
ifdef thus do not compile that hunk of the code.
Fix the android build by enabling the optimisation and adding the define
where applicable.
Cc: Matt Turner matts...@gmail.com
Cc: Adrian Negreanu adrian.m.negre...@intel.com
Cc: 10.1 10.2 mesa-sta...@lists.freedesktop.org
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
Hi Matt,
I believe this is what you had in mind with your earlier comment -
avoid calling intel_miptree_map_movntdqa, when compiler does not support
-msse4.1, otherwise we end up with garbage output and/or locked up GPU.
Andrian,
Any chance you can give this patch/the series a test ? Things seems to
build fine in here but I'm a bit short on a Intel GPU.
-Emil
configure.ac | 3 +++
src/mesa/Android.libmesa_dricore.mk | 1 +
src/mesa/drivers/dri/i965/Android.mk | 5 +
src/mesa/drivers/dri/i965/intel_mipmap_tree.c | 2 ++
4 files changed, 11 insertions(+)
diff --git a/configure.ac b/configure.ac
index 698cd8d..d045619 100644
--- a/configure.ac
+++ b/configure.ac
@@ -238,6 +238,9 @@ dnl
dnl Optional flags, check for compiler support
dnl
AX_CHECK_COMPILE_FLAG([-msse4.1], [SSE41_SUPPORTED=1], [SSE41_SUPPORTED=0])
+if test x$SSE41_SUPPORTED = x1; then
+DEFINES=$DEFINES -DUSE_SSE41
+endif
AM_CONDITIONAL([SSE41_SUPPORTED], [test x$SSE41_SUPPORTED = x1])
dnl
diff --git a/src/mesa/Android.libmesa_dricore.mk
b/src/mesa/Android.libmesa_dricore.mk
index 217f649..28d6feb 100644
--- a/src/mesa/Android.libmesa_dricore.mk
+++ b/src/mesa/Android.libmesa_dricore.mk
@@ -50,6 +50,7 @@ endif # MESA_ENABLE_ASM
ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
LOCAL_SRC_FILES += \
$(SRCDIR)main/streaming-load-memcpy.c
+LOCAL_CFLAGS := -msse4.1
endif
LOCAL_C_INCLUDES := \
diff --git a/src/mesa/drivers/dri/i965/Android.mk
b/src/mesa/drivers/dri/i965/Android.mk
index 7e3fd65..2c6446f 100644
--- a/src/mesa/drivers/dri/i965/Android.mk
+++ b/src/mesa/drivers/dri/i965/Android.mk
@@ -35,6 +35,11 @@ include $(LOCAL_PATH)/Makefile.sources
LOCAL_CFLAGS := \
$(MESA_DRI_CFLAGS)
+ifeq ($(ARCH_X86_HAVE_SSE4_1),true)
+LOCAL_CFLAGS += \
+ -DUSE_SSE41
+endif
+
LOCAL_C_INCLUDES := \
$(i965_INCLUDES) \
$(MESA_DRI_C_INCLUDES) \
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index b36ffc7..1691b15 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -2270,8 +2270,10 @@ intel_miptree_map(struct brw_context *brw,
mt-bo-size = brw-max_gtt_map_object_size) {
assert(can_blit_slice(mt, level, slice));
intel_miptree_map_blit(brw, mt, map, level, slice);
+#if defined(USE_SSE41)
} else if (!(mode GL_MAP_WRITE_BIT) !mt-compressed
cpu_has_sse4_1) {
intel_miptree_map_movntdqa(brw, mt, map, level, slice);
+#endif
I think we should wrap the definitions of intel_miptree_map_movntdqa
and intel_miptree_unmap_movntdqa in #if defined(USE_SSE41) as well.
Other than that,
Reviewed-by: Matt Turner matts...@gmail.com
Thanks for handling this!
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: guard better when building with sse4.1 optimisations
On Tue, Aug 12, 2014 at 2:52 PM, Matt Turner matts...@gmail.com wrote:
diff --git a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
index b36ffc7..1691b15 100644
--- a/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
+++ b/src/mesa/drivers/dri/i965/intel_mipmap_tree.c
@@ -2270,8 +2270,10 @@ intel_miptree_map(struct brw_context *brw,
mt-bo-size = brw-max_gtt_map_object_size) {
assert(can_blit_slice(mt, level, slice));
intel_miptree_map_blit(brw, mt, map, level, slice);
+#if defined(USE_SSE41)
} else if (!(mode GL_MAP_WRITE_BIT) !mt-compressed
cpu_has_sse4_1) {
intel_miptree_map_movntdqa(brw, mt, map, level, slice);
+#endif
I think we should wrap the definitions of intel_miptree_map_movntdqa
and intel_miptree_unmap_movntdqa in #if defined(USE_SSE41) as well.
And of course wrap the call to intel_miptree_unmap_movntdqa as well.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/9] glsl: Fix directory handling in optimization-test
On Tue, Jul 29, 2014 at 2:36 AM, Petri Latvala petri.latv...@intel.com wrote:
optimization-test loops over directories that contain a file named
create_test_cases.py. For each occurrence, it enters the directory
that contains the file and executes it, and is then supposed to return
to the previous directory.
The name .. was hardcoded in the script, and should be
../.. instead. Hardcoding that is finicky too, so wrap the directory change
and script execution in a subshell instead.
In case of errors executing create_test_cases.py, exit with status 1
to make the test run communicate failure properly.
Signed-off-by: Petri Latvala petri.latv...@intel.com
---
src/glsl/tests/optimization-test | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glsl/tests/optimization-test
b/src/glsl/tests/optimization-test
index 26a51be..12ecc5e 100755
--- a/src/glsl/tests/optimization-test
+++ b/src/glsl/tests/optimization-test
@@ -12,7 +12,7 @@ pass=0
echo == Generating tests ==
for dir in tests/*/; do
if [ -e ${dir}create_test_cases.py ]; then
-cd $dir; $PYTHON2 create_test_cases.py; cd ..
+(cd $dir; $PYTHON2 create_test_cases.py) || exit 1
fi
echo $dir
done
--
2.0.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Whoops... I don't know much bash scripting so I'm glad you fixed up
what I wrote. I can't review this properly for the same reason, but it
at least it gets an
Acked-by: Connor Abbott cwabbo...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] [rfc] docs/GL3.txt: add GLES 3.1 section
On Sun, Aug 10, 2014 at 4:06 PM, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This just cherry-pick the extensions into a list for GLES 3.1 I'm not actually sure if this list if complete or correct, maybe someone else can tell me what I missed, and I'm not 100% sure on multi_draw_indirect. Signed-off-by: Dave Airlie airl...@redhat.com --- docs/GL3.txt | 17 + 1 file changed, 17 insertions(+) diff --git a/docs/GL3.txt b/docs/GL3.txt index e241257..534b088 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -191,6 +191,23 @@ GL 4.4: GL_ARB_texture_stencil8 not started GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0, r600, radeonsi) +These are the extensions cherry-picked to make GLES 3.1 +GLES3.1: Remove this line? + GLSL ES 3.1 not started + GL_ARB_arrays_of_arrays started (Timothy) + GL_ARB_compute_shaderstarted (currently stalled) + GL_ARB_explicit_uniform_location DONE (all drivers that support GLSL) + GL_ARB_framebuffer_no_attachmentsnot started + GL_ARB_multi_draw_indirect DONE (i965, nvc0, radeonsi, softpipe, llvmpipe) I don't see this in ES 3.1. I looked for its new procedures' names and didn't see any of them. + GL_ARB_program_interface_query not started + GL_ARB_shader_atomic_countersDONE (i965) + GL_ARB_shader_image_load_store in progress (curro) + GL_ARB_shader_storage_buffer_object not started + GL_ARB_shader_subroutine not started This one isn't in ES 3.1. The GLSL ES 3.1 spec lists 'subroutine' as a keyword reserved for future use. Also, there are - GS5 Packing/bitfield/conversion functions DONE (i965, nvc0, r600) - GL_EXT_shader_integer_mix DONE (i965, ...) Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 5/5] docs: add GL4.5 section, mark ARB_texture_barrier as done
Reviewed-by: Chris Forbes chr...@ijw.co.nz On Tue, Aug 12, 2014 at 7:07 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Not 100% sure about the KHR_robust_buffer_access_behavior -- is that part of GL4.5? docs/GL3.txt | 16 1 file changed, 16 insertions(+) diff --git a/docs/GL3.txt b/docs/GL3.txt index 7f18cd7..f204652 100644 --- a/docs/GL3.txt +++ b/docs/GL3.txt @@ -183,5 +183,21 @@ GL 4.4, GLSL 4.40: GL_ARB_vertex_type_10f_11f_11f_rev DONE (i965, nv50, nvc0, r600, radeonsi) +GL 4.5, GLSL 4.50: + + GL_ARB_ES3_1_compatibility not started + GL_ARB_clip_control not started + GL_ARB_conditional_render_inverted not started + GL_ARB_cull_distance not started + GL_ARB_derivative_controlnot started + GL_ARB_direct_state_access not started + GL_ARB_get_texture_sub_image not started + GL_ARB_shader_texture_image_samples not started + GL_ARB_texture_barrier DONE (nv50, nvc0, r300, r600, radeonsi) + GL_KHR_context_flush_control not started + GL_KHR_robust_buffer_access_behavior not started + GL_KHR_robustnessnot started + + More info about these features and the work involved can be found at http://dri.freedesktop.org/wiki/MissingFunctionality -- 1.8.5.5 ___ 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] [Bug 41700] Gallium won't build with --enable-32-bit on a 64-bit system
https://bugs.freedesktop.org/show_bug.cgi?id=41700 Bug 41700 depends on bug 50754, which changed state. Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for automake https://bugs.freedesktop.org/show_bug.cgi?id=50754 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- 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 45466] Updated configure.ac check for llvm-config to use 32 version when appropriate
https://bugs.freedesktop.org/show_bug.cgi?id=45466 Bug 45466 depends on bug 50754, which changed state. Bug 50754 Summary: Building 32 bit mesa on 64 bit OS fails since change for automake https://bugs.freedesktop.org/show_bug.cgi?id=50754 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED -- 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 50754] Building 32 bit mesa on 64 bit OS fails since change for automake
https://bugs.freedesktop.org/show_bug.cgi?id=50754 Emil Velikov emil.l.veli...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #28 from Emil Velikov emil.l.veli...@gmail.com --- Thanks for the patch Alexandre, and sorry for the delay - it went under my radar. Pushed to master commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03 Author: Alexandre Demers alexandre.f.dem...@gmail.com Date: Fri Nov 22 20:06:20 2013 -0500 configure: Fix --enable-XX-bit flags by moving LT_INIT where it should Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS. LT_INIT needs them as they are expected to be used all along the compilation when the macro runs its tests to determine among other things the host type. For info, see http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html -- 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 82534] New: src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 Priority: medium Bug ID: 82534 Keywords: regression CC: emil.l.veli...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02 Severity: blocker Classification: Unclassified OS: Windows (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: 52901ec2615761390f5ef97b11516dae330d27d1 (master 10.3.0-devel) Archiving build\windows-x86-debug\egl\main\egl.lib ... src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02 -- 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 82536] New: u_current.h:72: undefined reference to `__imp__glapi_Dispatch'
https://bugs.freedesktop.org/show_bug.cgi?id=82536 Priority: medium Bug ID: 82536 Keywords: bisected, regression CC: alexandre.f.dem...@gmail.com, emil.l.veli...@gmail.com, lem...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: u_current.h:72: undefined reference to `__imp__glapi_Dispatch' Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa mesa: 52901ec2615761390f5ef97b11516dae330d27d1 (master 10.3.0-devel) MinGW build error CCLD libglapi.la .libs/entry.o: In function `u_current_get_table': src/mapi/shared-glapi/../../../src/mapi/u_current.h:72: undefined reference to `__imp__glapi_Dispatch' 2af28040d639dddbb7c258981a00eaf3dfcbcf03 is the first bad commit commit 2af28040d639dddbb7c258981a00eaf3dfcbcf03 Author: Alexandre Demers alexandre.f.dem...@gmail.com Date: Fri Nov 22 20:06:20 2013 -0500 configure: Fix --enable-XX-bit flags by moving LT_INIT where it should Moving LT_INIT after setting completely (AM_)C(XX)FLAGS and LDFLAGS. LT_INIT needs them as they are expected to be used all along the compilation when the macro runs its tests to determine among other things the host type. For info, see http://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50754 Signed-off-by: Alexandre Demers alexandre.f.dem...@gmail.com Tested-by: Tapani Palli lem...@gmail.com Reviewed-by: Emil Velikov emil.l.veli...@gmail.com :100644 100644 cd02babd67350dba02874e6c598da2b3b99724f5 b27cfb3f41b4c348406cc83d1030da103d7095bb Mconfigure.ac bisect run success -- 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] radeonsi: implement BPTC texture support
Passes all piglit tests.
v2: rebased
---
src/gallium/drivers/radeonsi/si_state.c | 20
1 file changed, 20 insertions(+)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 6e9a60a..4f7adea 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -1102,6 +1102,22 @@ static uint32_t si_translate_texformat(struct
pipe_screen *screen,
}
}
+ if (desc-layout == UTIL_FORMAT_LAYOUT_BPTC) {
+ if (!enable_s3tc)
+ goto out_unknown;
+
+ switch (format) {
+ case PIPE_FORMAT_BPTC_RGBA_UNORM:
+ case PIPE_FORMAT_BPTC_SRGBA:
+ return V_008F14_IMG_DATA_FORMAT_BC7;
+ case PIPE_FORMAT_BPTC_RGB_FLOAT:
+ case PIPE_FORMAT_BPTC_RGB_UFLOAT:
+ return V_008F14_IMG_DATA_FORMAT_BC6;
+ default:
+ goto out_unknown;
+ }
+ }
+
if (desc-layout == UTIL_FORMAT_LAYOUT_SUBSAMPLED) {
switch (format) {
case PIPE_FORMAT_R8G8_B8G8_UNORM:
@@ -2467,12 +2483,16 @@ static struct pipe_sampler_view
*si_create_sampler_view(struct pipe_context *ctx
case PIPE_FORMAT_DXT1_SRGBA:
case PIPE_FORMAT_DXT3_SRGBA:
case PIPE_FORMAT_DXT5_SRGBA:
+ case PIPE_FORMAT_BPTC_SRGBA:
num_format =
V_008F14_IMG_NUM_FORMAT_SRGB;
break;
case PIPE_FORMAT_RGTC1_SNORM:
case PIPE_FORMAT_LATC1_SNORM:
case PIPE_FORMAT_RGTC2_SNORM:
case PIPE_FORMAT_LATC2_SNORM:
+ /* implies float, so use SNORM/UNORM to
determine
+ whether data is signed or not */
+ case PIPE_FORMAT_BPTC_RGB_FLOAT:
num_format =
V_008F14_IMG_NUM_FORMAT_SNORM;
break;
default:
--
1.9.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- It smells like msvc/scons issue, but it could easily be a bug on our end as well. GCC builds it like a champ :) Can you let me know the version of msvc, python and scons that you're using ? -- 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 82536] u_current.h:72: undefined reference to `__imp__glapi_Dispatch'
https://bugs.freedesktop.org/show_bug.cgi?id=82536 --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- Vinson if this report is automated can you add an option to provide the configure parameters by default ? Is this the original mingw or mingw-w64, which version ? Thanks -- 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 82534] src\egl\main\eglapi.h : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2E02
https://bugs.freedesktop.org/show_bug.cgi?id=82534 --- Comment #2 from Vinson Lee v...@freedesktop.org --- MSVC 2012 Python 2.7.8 SCons 2.3.0 -- 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 82538] New: Super Maryo Chronicles fails with st/mesa assertion failure
https://bugs.freedesktop.org/show_bug.cgi?id=82538 Priority: medium Bug ID: 82538 Assignee: mesa-dev@lists.freedesktop.org Summary: Super Maryo Chronicles fails with st/mesa assertion failure Severity: normal Classification: Unclassified OS: All Reporter: mic...@daenzer.net Hardware: Other Status: NEW Version: git Component: Mesa core Product: Mesa Super Maryo Chronicles (smc) fails to start up on radeonsi with this assertion failure: ../../../src/mesa/state_tracker/st_atom_array.c:417:setup_interleaved_attribs: Assertion `array-_ElementSize == _mesa_bytes_per_vertex_attrib(array-Size, array-Type)' failed. Program received signal SIGTRAP, Trace/breakpoint trap. 0x7fffe881bb86 in _debug_assert_fail (expr=expr@entry=0x7fffe8b605b0 array-_ElementSize == _mesa_bytes_per_vertex_attrib(array-Size, array-Type), file=file@entry=0x7fffe8b604d8 ../../../src/mesa/state_tracker/st_atom_array.c, line=line@entry=417, function=function@entry=0x7fffe8b60710 __func__.35322 setup_interleaved_attribs) at ../../../../src/gallium/auxiliary/util/u_debug.c:309 309 os_abort(); (gdb) bt #0 0x7fffe881bb86 in _debug_assert_fail (expr=expr@entry=0x7fffe8b605b0 array-_ElementSize == _mesa_bytes_per_vertex_attrib(array-Size, array-Type), file=file@entry=0x7fffe8b604d8 ../../../src/mesa/state_tracker/st_atom_array.c, line=line@entry=417, function=function@entry=0x7fffe8b60710 __func__.35322 setup_interleaved_attribs) at ../../../../src/gallium/auxiliary/util/u_debug.c:309 #1 0x7fffe866d8f6 in setup_interleaved_attribs (vpv=0xf97870, velements=0x7fffcf10, vbuffer=0x7fffd110, arrays=0x986de0, vp=0xf9b590) at ../../../src/mesa/state_tracker/st_atom_array.c:416 #2 update_array (st=0x9059c0) at ../../../src/mesa/state_tracker/st_atom_array.c:566 #3 0x7fffe866cdb1 in st_validate_state (st=st@entry=0x9059c0) at ../../../src/mesa/state_tracker/st_atom.c:213 #4 0x7fffe8677691 in st_Clear (ctx=0x9d74a0, mask=18) at ../../../src/mesa/state_tracker/st_cb_clear.c:449 [...] This doesn't seem to happen with Mesa 10.2.4. -- 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 82536] u_current.h:72: undefined reference to `__imp__glapi_Dispatch'
https://bugs.freedesktop.org/show_bug.cgi?id=82536 --- Comment #2 from Vinson Lee v...@freedesktop.org --- ./autogen.sh --enable-debug --enable-texture-float \ --host=x86_64-w64-mingw32 \ --disable-glx \ --disable-dri \ --disable-egl \ --enable-static \ --disable-gallium-llvm \ --with-dri-drivers=swrast \ --with-gallium-drivers=swrast,svga gmake $ x86_64-w64-mingw32-gcc --version x86_64-w64-mingw32-gcc (GCC) 4.8.3 20140522 (Fedora MinGW 4.8.3-1.fc20) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- 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 81680] [r600g] Firefox crashes with hardware acceleration turned on
https://bugs.freedesktop.org/show_bug.cgi?id=81680
--- Comment #18 from Michel Dänzer mic...@daenzer.net ---
(In reply to comment #17)
But when crash after firefox closing happend I still could not run bt ('no
stack' reply on my 'bt' try):
[...]
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
Continuing.
I think this is the crash, so you should run 'bt full' here instead of
'continue'.
[Inferior 1 (process 4417) exited with code 013]
The program is not being run.
No stack.
There is no stack because the process terminated.
--
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 82539] New: vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 Priority: medium Bug ID: 82539 Keywords: regression CC: emil.l.veli...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: 52901ec2615761390f5ef97b11516dae330d27d1 (master 10.3.0-devel) $ ./autogen.sh --disable-dri --disable-egl --disable-gallium-llvm --with-dri-drivers=swrast --with-gallium-drivers=svga,swrast $ make [...] CC vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory -- 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 82539] vmw_screen_dri.lo In file included from vmw_screen_dri.c:41: vmwgfx_drm.h:32:17: error: drm.h: No such file or directory
https://bugs.freedesktop.org/show_bug.cgi?id=82539 --- Comment #1 from Emil Velikov emil.l.veli...@gmail.com --- The only recent commit remotely possible of doing this is fd7da27a43182169e6306d9df39e7e9498e38d28. Can you please confirm ? Where is drm.h located on your system ? Does libdrm.pc point to it ? -- 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] Mesa (master): mesa/formats: Add layout and swizzle information
Am 06.08.2014 11:28, schrieb Michel Dänzer: On 06.08.2014 03:08, Jason Ekstrand wrote: Module: Mesa Branch: master Commit: 850fb0d1dca616179d3239a7b7bd94fe1979604c URL: https://urldefense.proofpoint.com/v1/url?u=http://cgit.freedesktop.org/mesa/mesa/commit/?id%3D850fb0d1dca616179d3239a7b7bd94fe1979604ck=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=F4msKE2WxRzA%2BwN%2B25muztFm5TSPwE8HKJfWfR2NgfY%3D%0Am=M3mfjwgruJzPHL55%2BrGtDjCQ6DTQMURIoUjKbv00MIU%3D%0As=af10bfc26af3611fea43b64de32c55e38bc2721b145a63dcde3f0085fcd850d7 Author: Jason Ekstrand jason.ekstr...@intel.com Date: Thu Jul 10 23:59:42 2014 -0700 mesa/formats: Add layout and swizzle information v2: Move the MESA_FORMAT_SWIZZLE enum to the top of the file Signed-off-by: Jason Ekstrand jason.ekstr...@intel.com Reviewed-by: Brian Paul bri...@vmware.com As of this commit, ~20 depth/stencil related piglit tests have regressed with the radeonsi driver compared to before your changes. See below for an example failure of the draw-pixels test. There's actually more breakage due to this at least in gallium based drivers though unfortunately there's no piglit test catching it (conform drawpix does). I'm not sure if this is along similar lines to the issues with stencil index, but drawpixel with GL_COLOR_INDEX data is busted - it'll actually report a mesa implementation error because the COLOR_INDEX_DATA is passed through to the texstore functions, and the new texstore_swizzle() function can't handle this. Backtrace from the error looks like this: #0 get_map_idx (value=6400) at src/mesa/main/texstore.c:245 #1 0x73ee0f56 in compute_component_mapping (inFormat=6400, outFormat=6408, map=0x7fffb310 @\263\377\377\377\177) at src/mesa/main/texstore.c:264 #2 0x73ee4312 in texstore_swizzle (ctx=0x77fd3010, dims=2, baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM, dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40, srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980, srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1529 #3 0x73ee4cc6 in texstore_rgba (ctx=0x77fd3010, dims=2, baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM, dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40, srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980, srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1730 #4 0x73ee5190 in _mesa_texstore (ctx=0x77fd3010, dims=2, baseInternalFormat=6408, dstFormat=MESA_FORMAT_R8G8B8A8_UNORM, dstRowStride=192, dstSlices=0x7fffb4a0, srcWidth=40, srcHeight=40, srcDepth=1, srcFormat=6400, srcType=5121, srcAddr=0x8aa980, srcPacking=0x7fffb590) at src/mesa/main/texstore.c:1871 #5 0x740876c2 in make_texture (st=0x8367d0, width=40, height=40, format=6400, type=5121, unpack=0x7fffb590, pixels=0x8aa980) at src/mesa/state_tracker/st_cb_drawpixels.c:540 #6 0x740895ee in st_DrawPixels (ctx=0x77fd3010, x=0, y=0, width=40, height=40, format=6400, type=5121, unpack=0x7fffb590, pixels=0x8aa980) at src/mesa/state_tracker/st_cb_drawpixels.c:1170 #7 0x73f7cfb2 in _mesa_DrawPixels (width=40, height=40, format=6400, type=5121, pixels=0x8aa980) at src/mesa/main/drawpix.c:162 I can't quite see if that is even supposed to work or if the state tracker needs to handle it (it used to work at least somehow), though quickly disabling texstore_swizzle() does fix it (doesn't help all that much though since the test will then later complain about other cases though maybe these are due to the different snorm formulas, as it happens with GL_BYTE/GL_RGB type/format). Any ideas? Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 82477] [softpipe] piglit fp-long-alu regression
https://bugs.freedesktop.org/show_bug.cgi?id=82477 --- Comment #2 from Kenneth Graunke kenn...@whitecape.org --- That sounds pretty easy to fix, but we could also just disable the Mesa IR optimizer for ARB_fragment_programs. Notably, in my commit, I measured gains for ARB_vp, but only losses from enabling it in ARB_fp... -- 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] i965/fs: Drop do dual source blending generator parameter.
When dual source blending, the visitor already stores a flag in
brw_wm_prog_data (dual_src_blend) for the state upload code to use.
The generator also receives this, so there's no need to pass an
additional flag.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_fs.cpp| 2 +-
src/mesa/drivers/dri/i965/brw_fs.h | 2 --
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 4 +---
4 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
index 5a485df..24358a8 100644
--- a/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
+++ b/src/mesa/drivers/dri/i965/brw_blorp_blit_eu.cpp
@@ -31,7 +31,7 @@ brw_blorp_eu_emitter::brw_blorp_eu_emitter(struct brw_context
*brw,
generator(brw, mem_ctx,
rzalloc(mem_ctx, struct brw_wm_prog_key),
rzalloc(mem_ctx, struct brw_wm_prog_data),
- NULL, NULL, false, false, debug_flag)
+ NULL, NULL, false, debug_flag)
{
}
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index cc5ec16..8405502 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -3245,7 +3245,7 @@ brw_wm_fs_emit(struct brw_context *brw,
}
const unsigned *assembly = NULL;
- fs_generator g(brw, mem_ctx, key, prog_data, prog, fp, v.do_dual_src,
+ fs_generator g(brw, mem_ctx, key, prog_data, prog, fp,
v.runtime_check_aads_emit, INTEL_DEBUG DEBUG_WM);
assembly = g.generate_assembly(v.instructions, simd16_instructions,
final_assembly_size);
diff --git a/src/mesa/drivers/dri/i965/brw_fs.h
b/src/mesa/drivers/dri/i965/brw_fs.h
index e7a82c4..5cad504 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.h
+++ b/src/mesa/drivers/dri/i965/brw_fs.h
@@ -573,7 +573,6 @@ public:
struct brw_wm_prog_data *prog_data,
struct gl_shader_program *prog,
struct gl_fragment_program *fp,
-bool dual_source_output,
bool runtime_check_aads_emit,
bool debug_flag);
~fs_generator();
@@ -684,7 +683,6 @@ private:
unsigned dispatch_width; /** 8 or 16 */
exec_list discard_halt_patches;
- bool dual_source_output;
bool runtime_check_aads_emit;
const bool debug_flag;
void *mem_ctx;
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 208b54f..9e260a7 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -42,12 +42,10 @@ fs_generator::fs_generator(struct brw_context *brw,
struct brw_wm_prog_data *prog_data,
struct gl_shader_program *prog,
struct gl_fragment_program *fp,
- bool dual_source_output,
bool runtime_check_aads_emit,
bool debug_flag)
: brw(brw), key(key), prog_data(prog_data), prog(prog), fp(fp),
- dual_source_output(dual_source_output),
runtime_check_aads_emit(runtime_check_aads_emit), debug_flag(debug_flag),
mem_ctx(mem_ctx)
{
@@ -117,7 +115,7 @@ fs_generator::fire_fb_write(fs_inst *inst,
brw_pop_insn_state(p);
}
- if (this-dual_source_output)
+ if (prog_data-dual_src_blend)
msg_control =
BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD8_DUAL_SOURCE_SUBSPAN01;
else if (dispatch_width == 16)
msg_control = BRW_DATAPORT_RENDER_TARGET_WRITE_SIMD16_SINGLE_SOURCE;
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Enable INTDIV in SIMD16 mode.
All we need to do is decompose this to two SIMD8 instructions, like we
do in many other cases. We even already have code for that.
I apparently just botched this last time I tried, and it was easy.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 4 ++--
2 files changed, 2 insertions(+), 14 deletions(-)
From looking at the docs, it appears that INTDIV doesn't support source
modifiers...on any generation. I don't think we enforce that today...
Passes Piglit on Haswell; I haven't tried other generations.
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 8405502..35ada42 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1404,18 +1404,6 @@ fs_visitor::emit_math(enum opcode opcode, fs_reg dst,
fs_reg src0, fs_reg src1)
int base_mrf = 2;
fs_inst *inst;
- switch (opcode) {
- case SHADER_OPCODE_INT_QUOTIENT:
- case SHADER_OPCODE_INT_REMAINDER:
- if (brw-gen = 7)
-no16(SIMD16 INTDIV unsupported\n);
- break;
- case SHADER_OPCODE_POW:
- break;
- default:
- unreachable(not reached: unsupported binary math opcode.);
- }
-
if (brw-gen = 8) {
inst = emit(opcode, dst, src0, src1);
} else if (brw-gen = 6) {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 9e260a7..1190f1f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1620,9 +1620,9 @@ fs_generator::generate_code(exec_list *instructions)
case SHADER_OPCODE_INT_REMAINDER:
case SHADER_OPCODE_POW:
assert(brw-gen 6 || inst-mlen == 0);
-if (brw-gen = 7) {
+if (brw-gen = 7 inst-opcode == SHADER_OPCODE_POW) {
gen6_math(p, dst, brw_math_function(inst-opcode), src[0], src[1]);
-} else if (brw-gen == 6) {
+} else if (brw-gen = 6) {
generate_math_gen6(inst, dst, src[0], src[1]);
} else {
generate_math_gen4(inst, dst, src[0]);
--
2.0.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: Enable INTDIV in SIMD16 mode.
On Tue, Aug 12, 2014 at 9:55 PM, Kenneth Graunke kenn...@whitecape.org wrote:
All we need to do is decompose this to two SIMD8 instructions, like we
do in many other cases. We even already have code for that.
I apparently just botched this last time I tried, and it was easy.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 12
src/mesa/drivers/dri/i965/brw_fs_generator.cpp | 4 ++--
2 files changed, 2 insertions(+), 14 deletions(-)
From looking at the docs, it appears that INTDIV doesn't support source
modifiers...on any generation. I don't think we enforce that today...
Passes Piglit on Haswell; I haven't tried other generations.
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 8405502..35ada42 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1404,18 +1404,6 @@ fs_visitor::emit_math(enum opcode opcode, fs_reg dst,
fs_reg src0, fs_reg src1)
int base_mrf = 2;
fs_inst *inst;
- switch (opcode) {
- case SHADER_OPCODE_INT_QUOTIENT:
- case SHADER_OPCODE_INT_REMAINDER:
- if (brw-gen = 7)
-no16(SIMD16 INTDIV unsupported\n);
- break;
- case SHADER_OPCODE_POW:
- break;
- default:
- unreachable(not reached: unsupported binary math opcode.);
- }
-
if (brw-gen = 8) {
inst = emit(opcode, dst, src0, src1);
} else if (brw-gen = 6) {
diff --git a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
index 9e260a7..1190f1f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_generator.cpp
@@ -1620,9 +1620,9 @@ fs_generator::generate_code(exec_list *instructions)
case SHADER_OPCODE_INT_REMAINDER:
case SHADER_OPCODE_POW:
assert(brw-gen 6 || inst-mlen == 0);
-if (brw-gen = 7) {
+if (brw-gen = 7 inst-opcode == SHADER_OPCODE_POW) {
gen6_math(p, dst, brw_math_function(inst-opcode), src[0],
src[1]);
-} else if (brw-gen == 6) {
+} else if (brw-gen = 6) {
generate_math_gen6(inst, dst, src[0], src[1]);
} else {
generate_math_gen4(inst, dst, src[0]);
--
I'd completely forgotten that Sandybridge can't do compressed math instructions.
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965/fs: Drop do dual source blending generator parameter.
Reviewed-by: Matt Turner matts...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] egl_dri2: fix EXT_image_dma_buf_import fds
Hi,
2014-08-08 16:28 GMT+02:00 Pekka Paalanen ppaala...@gmail.com:
From: Pekka Paalanen pekka.paala...@collabora.co.uk
The EGL_EXT_image_dma_buf_import specification was revised (according to
its revision history) on Dec 5th, 2013, for EGL to not take ownership of
the file descriptors.
Do not close the file descriptors passed in to eglCreateImageKHR with
EGL_LINUX_DMA_BUF_EXT target.
It is assumed, that the drivers, which ultimately process the file
descriptors, do not close or modify them in any way either. This avoids
the need to dup(), as it seems we would only need to just close the
dup'd file descriptors right after.
Since this was a so radical change, shouldn't have change the API
string name instead to EXT_image_dma_buf_import2 for instance?
Anyway, could you please point to the following bug in your patch?
https://bugs.freedesktop.org/show_bug.cgi?id=76188
Thanks.
the corresponding Piglit fix has already been sent to the piglit mailing
list. Both this and that need to be applied to not regress Mesa' piglit run
by one test (ext_image_dma_buf_import-ownership_transfer).
This patch fixes my test case on heavily modified Weston.
Thanks,
pq
---
src/egl/drivers/dri2/egl_dri2.c | 37 ++---
1 file changed, 6 insertions(+), 31 deletions(-)
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c
index 5602ec3..cd85fd3 100644
--- a/src/egl/drivers/dri2/egl_dri2.c
+++ b/src/egl/drivers/dri2/egl_dri2.c
@@ -1678,36 +1678,13 @@ dri2_check_dma_buf_format(const _EGLImageAttribs
*attrs)
/**
* The spec says:
*
- * If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target,
- * the EGL takes ownership of the file descriptor and is responsible for
- * closing it, which it may do at any time while the EGLDisplay is
- * initialized.
+ * If eglCreateImageKHR is successful for a EGL_LINUX_DMA_BUF_EXT target,
the
+ * EGL will take a reference to the dma_buf(s) which it will release at any
+ * time while the EGLDisplay is initialized. It is the responsibility of the
+ * application to close the dma_buf file descriptors.
+ *
+ * Therefore we must never close or otherwise modify the file descriptors.
*/
-static void
-dri2_take_dma_buf_ownership(const int *fds, unsigned num_fds)
-{
- int already_closed[num_fds];
- unsigned num_closed = 0;
- unsigned i, j;
-
- for (i = 0; i num_fds; ++i) {
- /**
- * The same file descriptor can be referenced multiple times in case
more
- * than one plane is found in the same buffer, just with a different
- * offset.
- */
- for (j = 0; j num_closed; ++j) {
- if (already_closed[j] == fds[i])
-break;
- }
-
- if (j == num_closed) {
- close(fds[i]);
- already_closed[num_closed++] = fds[i];
- }
- }
-}
-
static _EGLImage *
dri2_create_image_dma_buf(_EGLDisplay *disp, _EGLContext *ctx,
EGLClientBuffer buffer, const EGLint *attr_list)
@@ -1770,8 +1747,6 @@ dri2_create_image_dma_buf(_EGLDisplay *disp,
_EGLContext *ctx,
return EGL_NO_IMAGE_KHR;
res = dri2_create_image_from_dri(disp, dri_image);
- if (res)
- dri2_take_dma_buf_ownership(fds, num_fds);
return res;
}
--
1.8.5.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Regards,
--
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
