[Mesa-dev] nouveau: xvmc on nv43
Hello Ilia,
I was your last commit which fixing xvmc support for nv30 hw in mesa git tree.
Maybe you can help me. I have graphics card nvidia geforce 6600 gt (nv43 chip)
According to wiki page http://nouveau.freedesktop.org/wiki/FeatureMatrix/ xvmc
support for nv43 is already done. When I start xvmcinfo it print:
$ ./xvmcinfo
Xv version 2.2
XvMC version 1.1
screen number 0
info for adaptor 0 [NV40 texture adapter]
number of XvMC surface types: 2
info about surface 0:
max_width=2048
max_height=2048
subpicture_max_width=2048
subpicture_max_height=2048
chroma_format:
XVMC_CHROMA_FORMAT_420
mc_type:
format : MPEG2
accelaration start from : IDCT
flags:
XVMC_BACKEND_SUBPICTURE XVMC_SUBPICTURE_INDEPENDENT_SCALING
info about surface 1:
max_width=2048
max_height=2048
subpicture_max_width=2048
subpicture_max_height=2048
chroma_format:
XVMC_CHROMA_FORMAT_422
mc_type:
format : MPEG2
accelaration start from : IDCT
flags:
XVMC_BACKEND_SUBPICTURE XVMC_SUBPICTURE_INDEPENDENT_SCALING
info for adaptor 1 [NV40 high quality adapter]
number of XvMC surface types: 0
info for adaptor 2 [NV Video Blitter]
number of XvMC surface types: 0
So some xvmc support is there (via nouveau xvmc library). But when I tried to
use mpeg2play_accel testing application (or mplayer) it crash. Here is gdb
backtrace from coredump file:
(gdb) bt
#0 0x in ?? ()
#1 0x7fca300cd345 in XvMCCreateContext (dpy=0xbefd00, port=63,
surface_type_id=842094169, width=720, height=480, flags=1, context=0x60dee0)
at context.c:248
#2 0x0040941f in init_display () at display.c:270
#3 0x00402f0c in initdecoder () at mpeg2dec.c:211
#4 0x00402b57 in main (argc=2, argv=0x7fff94c89f10) at mpeg2dec.c:121
(gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0x7fca300cd345 in XvMCCreateContext (dpy=0xbefd00, port=63,
surface_type_id=842094169, width=720, height=480, flags=1, context=0x60dee0)
at context.c:248
found_port = true
scrn = 0
chroma_format = 1
mc_type = 65538
surface_flags = 6
subpic_max_w = 2048
subpic_max_h = 2048
ret = 0
vscreen = 0xbf13f0
pipe = 0xc191e0
context_priv = 0xbfead0
csc = {{0, 0, 0, 0}, {-2.02570359e-26, 4.59163468e-41, 5.89217978e-39,
0}, {-2.02575536e-26, 4.59163468e-41, 8.44951942e-10, 4.5842078e-41}}
#2 0x0040941f in init_display () at display.c:270
surface_type_id = 842094169
result = 0
i = 4204800
color = 0
root = 652
#3 0x00402f0c in initdecoder () at mpeg2dec.c:211
i = 640
blk_cnt_tab = {6, 8, 12}
#4 0x00402b57 in main (argc=2, argv=0x7fff94c89f10) at mpeg2dec.c:121
first = 1
framenum = 0
runtime = 0
tstart = {tv_sec = 140735689563912, tv_usec = 4236512}
tstop = {tv_sec = 0, tv_usec = 4204800}
It looks like that in mesa code is calling pipe-create_video_decoder(...) but
create_video_decoder is NULL and then it crash.
(gdb) print *pipe
$1 = {screen = 0xbffa50, priv = 0xbf13f0, draw = 0x0, destroy = 0x7fca300d00a0
nv30_context_destroy, draw_vbo = 0x7fca300da250 nv30_draw_vbo,
render_condition = 0x7fca300dd760 nv40_query_render_condition,
create_query = 0x7fca300dd510 nv30_query_create,
destroy_query = 0x7fca300dd500 nv30_query_destroy, begin_query =
0x7fca300dd890 nv30_query_begin, end_query = 0x7fca300dd670
nv30_query_end,
get_query_result = 0x7fca300dd410 nv30_query_result, create_blend_state =
0x7fca300d47f0 nv30_blend_state_create,
bind_blend_state = 0x7fca300d3da0 nv30_blend_state_bind,
delete_blend_state = 0x7fca300d4160 nv30_blend_state_delete,
create_sampler_state = 0x7fca300d69f0 nv30_sampler_state_create,
bind_fragment_sampler_states = 0x7fca300d72a0
nv30_fragtex_sampler_states_bind,
bind_vertex_sampler_states = 0x7fca300d79a0
nv40_verttex_sampler_states_bind, bind_geometry_sampler_states = 0,
bind_compute_sampler_states = 0,
delete_sampler_state = 0x7fca300d69e0 nv30_sampler_state_delete,
create_rasterizer_state = 0x7fca300d44a0 nv30_rasterizer_state_create,
bind_rasterizer_state = 0x7fca300d3db0 nv30_rasterizer_state_bind,
delete_rasterizer_state = 0x7fca300d4150 nv30_rasterizer_state_delete,
create_depth_stencil_alpha_state = 0x7fca300d4170 nv30_zsa_state_create,
bind_depth_stencil_alpha_state = 0x7fca300d3dc0 nv30_zsa_state_bind,
delete_depth_stencil_alpha_state = 0x7fca300d4140 nv30_zsa_state_delete,
create_fs_state = 0x7fca300d7cb0 nv30_fp_state_create,
bind_fs_state = 0x7fca300d7c40 nv30_fp_state_bind, delete_fs_state =
0x7fca300d7c50 nv30_fp_state_delete,
Re: [Mesa-dev] nouveau: xvmc on nv43
On Friday 16 August 2013 16:34:43 you wrote:
On Fri, Aug 16, 2013 at 5:40 AM, Pali Rohár
pali.ro...@gmail.com wrote:
Hello Ilia,
I was your last commit which fixing xvmc support for nv30 hw
in mesa git tree. Maybe you can help me. I have graphics
card nvidia geforce 6600 gt (nv43 chip) According to wiki
page http://nouveau.freedesktop.org/wiki/FeatureMatrix/
xvmc
support for nv43 is already done. When I start xvmcinfo it
print:
FTR, an individual with a NV43 AGP had trouble with it. See
http://nouveau.freedesktop.org/wiki/VideoAcceleration/ for a
few more details. Note that if you're using a recent kernel,
you need 3.11-rc4 or later (nouveau/master is fine too, of
course), as support got broken at some point.
Ok, I'm using kernel 3.8 from ubuntu. Will try 3.11 if something
change. Also I have PCI-E card, not AGP.
$ ./xvmcinfo
Huh, never heard of that. No gentoo ebuild either.
You can download it from:
http://www.mythtv.org/wiki/XvMC#Checking_your_installation
or from:
http://svnweb.freebsd.org/ports/head/x11/xvmcinfo/files/
Xv version 2.2
XvMC version 1.1
screen number 0
info for adaptor 0 [NV40 texture adapter]
number of XvMC surface types: 2
info about surface 0:
max_width=2048
max_height=2048
subpicture_max_width=2048
subpicture_max_height=2048
chroma_format:
XVMC_CHROMA_FORMAT_420
mc_type:
format : MPEG2
accelaration start from : IDCT
flags:
XVMC_BACKEND_SUBPICTURE
XVMC_SUBPICTURE_INDEPENDENT_SCALING
info about surface 1:
max_width=2048
max_height=2048
subpicture_max_width=2048
subpicture_max_height=2048
chroma_format:
XVMC_CHROMA_FORMAT_422
mc_type:
format : MPEG2
accelaration start from : IDCT
flags:
XVMC_BACKEND_SUBPICTURE
XVMC_SUBPICTURE_INDEPENDENT_SCALING
info for adaptor 1 [NV40 high quality adapter]
number of XvMC surface types: 0
info for adaptor 2 [NV Video Blitter]
number of XvMC surface types: 0
This actually doesn't (necessarily) have anything to do with
reality. It's reported entirely by X, which has little to do
with actual XvMC operation.
It calling some XvMC functions. At least this means that X has
XvMC support for screen.
So some xvmc support is there (via nouveau xvmc library).
But when I tried to use mpeg2play_accel testing application
(or mplayer) it crash. Here is gdb backtrace from coredump
file:
(gdb) bt
#0 0x in ?? ()
#1 0x7fca300cd345 in XvMCCreateContext (dpy=0xbefd00,
port=63, surface_type_id=842094169, width=720, height=480,
flags=1, context=0x60dee0)
at context.c:248
#2 0x0040941f in init_display () at display.c:270
#3 0x00402f0c in initdecoder () at mpeg2dec.c:211
#4 0x00402b57 in main (argc=2, argv=0x7fff94c89f10)
at mpeg2dec.c:121 (gdb) bt full
#0 0x in ?? ()
No symbol table info available.
#1 0x7fca300cd345 in XvMCCreateContext (dpy=0xbefd00,
port=63, surface_type_id=842094169, width=720, height=480,
flags=1, context=0x60dee0)
at context.c:248
found_port = true
scrn = 0
chroma_format = 1
mc_type = 65538
surface_flags = 6
subpic_max_w = 2048
subpic_max_h = 2048
ret = 0
vscreen = 0xbf13f0
pipe = 0xc191e0
context_priv = 0xbfead0
csc = {{0, 0, 0, 0}, {-2.02570359e-26,
4.59163468e-41, 5.89217978e-39,
0}, {-2.02575536e-26, 4.59163468e-41, 8.44951942e-10,
4.5842078e-41}} #2 0x0040941f in init_display ()
at display.c:270
surface_type_id = 842094169
result = 0
i = 4204800
color = 0
root = 652
#3 0x00402f0c in initdecoder () at mpeg2dec.c:211
i = 640
blk_cnt_tab = {6, 8, 12}
#4 0x00402b57 in main (argc=2, argv=0x7fff94c89f10)
at mpeg2dec.c:121
first = 1
framenum = 0
runtime = 0
tstart = {tv_sec = 140735689563912, tv_usec =
4236512} tstop = {tv_sec = 0, tv_usec = 4204800}
It looks like that in mesa code is calling
pipe-create_video_decoder(...) but create_video_decoder is
NULL and then it crash.
(gdb) print *pipe
$1 = {screen = 0xbffa50, priv = 0xbf13f0, draw = 0x0,
destroy = 0x7fca300d00a0 nv30_context_destroy, draw_vbo =
0x7fca300da250 nv30_draw_vbo,
render_condition = 0x7fca300dd760
nv40_query_render_condition,
create_query = 0x7fca300dd510
[Mesa-dev] nouveau: nv43: Kwin from KDE 4.8 not working
Hello, with last mesa from master, kwin not rendering correctly. It render some random colors and after some time rendering is freezed. Keyboard, mouse working fine I'm able to write something in opened xterm. When I disable compositing (with keyboard shortcut) then rendering working fine and I can see what I wrote to xterm. I run git bisect and found that commit which caused this regression is: 35840ab189595b817fa8b1a1df8cc92474a7c38d st/dri: implement MSAA for GLX/DRI2 framebuffers Author: Marek Olšák 2012-12-03 05:36:08 Committer: Marek Olšák 2012-12-07 14:19:29 Reviewed-by: Brian Paul Above problem with kwin is only on nouveau nv43 (geforce 6600 gt). On another machine with radeon r600 driver it is not reproducable (also from mesa master) with same KDE/KWin version. I found some reported bugs, but I'm not sure if this is same: https://bugs.freedesktop.org/show_bug.cgi?id=58925 https://bugs.kde.org/show_bug.cgi?id=300475 At least upgrading KDE to new version 4.11 and manually choose use opengl 1.3 in kwin systemsettings solving this problem. With opengl 2.1 problem is still there. Do you have any idea where can be problem? Fact is that mesa from commit before 35840ab189595b817fa8b1a1df8cc92474a7c38d working fine without problems on nv43. -- Pali Rohár pali.ro...@gmail.com 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] r600g/sb: Initialize cf_node::bc.
On 08/19/2013 01:35 AM, Vinson Lee wrote:
Fixes Uninitialized pointer field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/drivers/r600/sb/sb_ir.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_ir.h
b/src/gallium/drivers/r600/sb/sb_ir.h
index c838f62..b696e77 100644
--- a/src/gallium/drivers/r600/sb/sb_ir.h
+++ b/src/gallium/drivers/r600/sb/sb_ir.h
@@ -962,8 +962,8 @@ public:
class cf_node : public container_node {
protected:
- cf_node() : container_node(NT_OP, NST_CF_INST), jump_target(),
- jump_after_target() {};
+ cf_node() : container_node(NT_OP, NST_CF_INST), bc(),
+ jump_target(), jump_after_target() {};
Hi, Vinson,
IIRC I switched the initialization of bc struct from constructor
initializer list to explicit memset due to reported issues with older
gcc versions, it failed to initialize the struct properly. See commit
41005d.
Constructors of cf_node (as well as fetch_node, alu_node) are protected
and called only by helper functions (create_cf, create_fetch,
create_alu) in friend class r600_sb::shader that create nodes in pool,
memset for bc is called right after constructor in these functions, so
actually bc is always initialized. I don't remember why I didn't use
memset in constructor body though, maybe moving memset there would
silence Coverity?
Vadim
public:
bc_cf bc;
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH v2 1/6] i965: Use SURF_INDEX_DRAW() for drawbuffer binding table indices.
SURF_INDEX_DRAW() has been the identity function since the dawn of time,
and both the shader code and binding table upload code relied on that,
simply using X rather than SURF_INDEX_DRAW(X).
Even if that continues to be true, using the macro clarifies the code.
The comment about draw buffers needing to be first in order for
headerless render target writes to work turned out to be wrong; with
this change, SURF_INDEX_DRAW can be changed to arbitrary indices and
everything continues working.
The confusion was over the Render Target Index field in the FB write
message header. If it were a binding table index, then RT 0 would have
to be at index 0 for headerless FB writes to work. However, it's
actually an index into the blend state table, so there's no problem.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
Cc: Paul Berry stereotype...@gmail.com
---
src/mesa/drivers/dri/i965/brw_context.h | 4
src/mesa/drivers/dri/i965/brw_fs_emit.cpp | 2 +-
src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 12 ++--
src/mesa/drivers/dri/i965/gen7_wm_surface_state.c | 14 --
4 files changed, 15 insertions(+), 17 deletions(-)
In order to fix the comment as Paul requested, I had to do some digging.
The end result was discovering that the comment was entirely wrong - the
only reason SURF_INDEX_DRAW had to be the identity function was that we
weren't calling it. With that fixed, it can be arbitrary, so there's
no need for the comment at all.
I did try totally scrambling the order of the binding table indexes
after applying the patch, and there were no Piglit regressions on IVB.
So I'm confident that it works (at least on Gen7+).
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index acd8e3f..e0deee0 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -602,10 +602,6 @@ struct brw_vs_prog_data {
*| : | : |
*| 63 | SOL Binding 63 |
*+-+-+
- *
- * Note that nothing actually uses the SURF_INDEX_DRAW macro, so it has to be
- * the identity function or things will break. We do want to keep draw buffers
- * first so we can use headerless render target writes for RT 0.
*/
#define SURF_INDEX_DRAW(d) (d)
#define SURF_INDEX_FRAG_CONST_BUFFER (BRW_MAX_DRAW_BUFFERS + 1)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
index 4225922..b90cf0f 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_emit.cpp
@@ -170,7 +170,7 @@ fs_generator::generate_fb_write(fs_inst *inst)
inst-base_mrf,
implied_header,
msg_control,
- inst-target,
+ SURF_INDEX_DRAW(inst-target),
inst-mlen,
0,
eot,
diff --git a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
index 8847f91..16579f9 100644
--- a/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_wm_surface_state.c
@@ -533,8 +533,8 @@ brw_update_null_renderbuffer_surface(struct brw_context
*brw, unsigned int unit)
/* _NEW_BUFFERS */
const struct gl_framebuffer *fb = ctx-DrawBuffer;
- surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
- 6 * 4, 32, brw-wm.surf_offset[unit]);
+ surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 6 * 4, 32,
+ brw-wm.surf_offset[SURF_INDEX_DRAW(unit)]);
if (fb-Visual.samples 1) {
/* On Gen6, null render targets seem to cause GPU hangs when
@@ -587,7 +587,7 @@ brw_update_null_renderbuffer_surface(struct brw_context
*brw, unsigned int unit)
if (bo) {
drm_intel_bo_emit_reloc(brw-batch.bo,
- brw-wm.surf_offset[unit] + 4,
+ brw-wm.surf_offset[SURF_INDEX_DRAW(unit)] + 4,
bo, 0,
I915_GEM_DOMAIN_RENDER, I915_GEM_DOMAIN_RENDER);
}
@@ -635,8 +635,8 @@ brw_update_renderbuffer_surface(struct brw_context *brw,
region = irb-mt-region;
- surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE,
- 6 * 4, 32, brw-wm.surf_offset[unit]);
+ surf = brw_state_batch(brw, AUB_TRACE_SURFACE_STATE, 6 * 4, 32,
+ brw-wm.surf_offset[SURF_INDEX_DRAW(unit)]);
format = brw-render_target_format[rb_format];
if (unlikely(!brw-format_supported_as_render_target[rb_format])) {
@@ -692,7 +692,7 @@ brw_update_renderbuffer_surface(struct brw_context *brw,
}
drm_intel_bo_emit_reloc(brw-batch.bo,
- brw-wm.surf_offset[unit] + 4,
+ brw-wm.surf_offset[SURF_INDEX_DRAW(unit)] + 4,
region-bo,
surf[1]
Re: [Mesa-dev] [PATCH] r600g/sb: Move memsets of member structs to within constructor bodies.
On 08/19/2013 11:50 AM, Vinson Lee wrote:
Silences Uninitialized pointer field defects reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
Reviewed-by: Vadim Girlin vadimgir...@gmail.com
---
src/gallium/drivers/r600/sb/sb_ir.h | 6 +++---
src/gallium/drivers/r600/sb/sb_shader.cpp | 3 ---
2 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/src/gallium/drivers/r600/sb/sb_ir.h
b/src/gallium/drivers/r600/sb/sb_ir.h
index c838f62..a74d6cb 100644
--- a/src/gallium/drivers/r600/sb/sb_ir.h
+++ b/src/gallium/drivers/r600/sb/sb_ir.h
@@ -963,7 +963,7 @@ public:
class cf_node : public container_node {
protected:
cf_node() : container_node(NT_OP, NST_CF_INST), jump_target(),
- jump_after_target() {};
+ jump_after_target() { memset(bc, 0, sizeof(bc_cf)); };
public:
bc_cf bc;
@@ -982,7 +982,7 @@ public:
class alu_node : public node {
protected:
- alu_node() : node(NT_OP, NST_ALU_INST) {};
+ alu_node() : node(NT_OP, NST_ALU_INST) { memset(bc, 0,
sizeof(bc_alu)); };
public:
bc_alu bc;
@@ -1028,7 +1028,7 @@ public:
class fetch_node : public node {
protected:
- fetch_node() : node(NT_OP, NST_FETCH_INST) {};
+ fetch_node() : node(NT_OP, NST_FETCH_INST) { memset(bc, 0,
sizeof(bc_fetch)); };
public:
bc_fetch bc;
diff --git a/src/gallium/drivers/r600/sb/sb_shader.cpp
b/src/gallium/drivers/r600/sb/sb_shader.cpp
index 9fc47ae..98e52b1 100644
--- a/src/gallium/drivers/r600/sb/sb_shader.cpp
+++ b/src/gallium/drivers/r600/sb/sb_shader.cpp
@@ -260,7 +260,6 @@ node* shader::create_node(node_type nt, node_subtype nst,
node_flags flags) {
alu_node* shader::create_alu() {
alu_node* n = new (pool.allocate(sizeof(alu_node))) alu_node();
- memset(n-bc, 0, sizeof(bc_alu));
all_nodes.push_back(n);
return n;
}
@@ -281,7 +280,6 @@ alu_packed_node* shader::create_alu_packed() {
cf_node* shader::create_cf() {
cf_node* n = new (pool.allocate(sizeof(cf_node))) cf_node();
- memset(n-bc, 0, sizeof(bc_cf));
n-bc.barrier = 1;
all_nodes.push_back(n);
return n;
@@ -289,7 +287,6 @@ cf_node* shader::create_cf() {
fetch_node* shader::create_fetch() {
fetch_node* n = new (pool.allocate(sizeof(fetch_node))) fetch_node();
- memset(n-bc, 0, sizeof(bc_fetch));
all_nodes.push_back(n);
return n;
}
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 9.2 branch created
On 2013-07-19 02:46 +0200, Ian Romanick wrote: The 9.2 branch is now live. From this point on, the branch will be treated just like any other stable release branch. Please remember to CC any patches destined for the release to mesa-stable. The current target date for the release is August 22nd. We'll start having release candidates weekly starting August 1st. No you didn't, there has not been a single release candidate for 9.2 yet. What's going on? Cheers, Sven ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] gallivm: do clamping of border color correctly for all formats
Looks alright to me.
I just wonder if it would be possible to factor this logic into a separate
function somehow.
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Turns out it is actually very complicated to figure out what a format really
is wrt range, as using channel information for determining unorm/snorm etc.
doesn't work for a bunch of cases - namely compressed, subsampled, other.
Also while here add clamping for uint/sint as well - d3d10 doesn't actually
need this (can only use ld with these formats hence no border) and we could
do this outside the shader for GL easily (due to the fixed texture/sampler
relation) do it here do just so I can forget about it.
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 162
++---
1 file changed, 144 insertions(+), 18 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index 76de006..f61c6c5 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -42,6 +42,7 @@
#include util/u_math.h
#include util/u_format.h
#include util/u_cpu_detect.h
+#include util/u_format_rgb9e5.h
#include lp_bld_debug.h
#include lp_bld_type.h
#include lp_bld_const.h
@@ -206,33 +207,158 @@ lp_build_sample_texel_soa(struct
lp_build_sample_context *bld,
lp_build_const_int32(bld-gallivm, chan));
LLVMValueRef border_chan_vec =
lp_build_broadcast_scalar(bld-float_vec_bld, border_chan);
+LLVMValueRef min_clamp = NULL;
+LLVMValueRef max_clamp = NULL;
if (!bld-texel_type.floating) {
border_chan_vec = LLVMBuildBitCast(builder, border_chan_vec,
bld-texel_bld.vec_type,
);
}
-else {
- /*
-* For normalized format need to clamp border color
(technically
-* probably should also quantize the data). Really sucks
doing this
-* here but can't avoid at least for now since this is part
of
-* sampler state and texture format is part of sampler_view
state.
-*/
+/*
+ * For normalized format need to clamp border color (technically
+ * probably should also quantize the data). Really sucks doing
this
+ * here but can't avoid at least for now since this is part of
+ * sampler state and texture format is part of sampler_view
state.
+ * (Could definitely do it outside per-sample loop but llvm
should
+ * take care of that.)
+ * GL expects also expects clamping for uint/sint formats too so
+ * do that as well (d3d10 can't end up here with uint/sint since
it
+ * only supports them with ld).
+ */
+if (format_desc-layout == UTIL_FORMAT_LAYOUT_PLAIN) {
unsigned chan_type = format_desc-channel[chan_s].type;
unsigned chan_norm = format_desc-channel[chan_s].normalized;
- if (chan_type == UTIL_FORMAT_TYPE_SIGNED chan_norm) {
- LLVMValueRef clamp_min;
- clamp_min = lp_build_const_vec(bld-gallivm,
bld-texel_type, -1.0F);
- border_chan_vec = lp_build_clamp(bld-texel_bld,
border_chan_vec,
- clamp_min,
- bld-texel_bld.one);
+ unsigned pure_int =
format_desc-channel[chan_s].pure_integer;
+ if (chan_type == UTIL_FORMAT_TYPE_SIGNED) {
+ if (chan_norm) {
+ min_clamp = lp_build_const_vec(bld-gallivm,
bld-texel_type, -1.0F);
+ max_clamp = bld-texel_bld.one;
+ }
+ else if (pure_int) {
+ /*
+ * Border color was stored as int, hence need min/max
clamp
+ * only if chan has less than 32 bits..
+ */
+ unsigned chan_size = format_desc-channel[chan_s].size
32;
+ if (chan_size 32) {
+min_clamp = lp_build_const_int_vec(bld-gallivm,
bld-texel_type,
+ 0 - (1
(chan_size - 1)));
+max_clamp = lp_build_const_int_vec(bld-gallivm,
bld-texel_type,
+ (1 (chan_size
- 1)) - 1);
+ }
+ }
+ /* TODO: no idea about non-pure, non-normalized! */
}
- else if (chan_type == UTIL_FORMAT_TYPE_UNSIGNED chan_norm)
[Mesa-dev] [PATCH] nv30: add forgotten PIPE_CAP_CUBE_MAP_ARRAY cap to list
Signed-off-by: Ilia Mirkin imir...@alum.mit.edu --- Silences a warning about unrecognized param when in debug mode. src/gallium/drivers/nv30/nv30_screen.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/drivers/nv30/nv30_screen.c b/src/gallium/drivers/nv30/nv30_screen.c index 40e8b5f..39e64ce 100644 --- a/src/gallium/drivers/nv30/nv30_screen.c +++ b/src/gallium/drivers/nv30/nv30_screen.c @@ -113,6 +113,7 @@ nv30_screen_get_param(struct pipe_screen *pscreen, enum pipe_cap param) case PIPE_CAP_TEXTURE_BARRIER: case PIPE_CAP_SEAMLESS_CUBE_MAP: case PIPE_CAP_SEAMLESS_CUBE_MAP_PER_TEXTURE: + case PIPE_CAP_CUBE_MAP_ARRAY: case PIPE_CAP_VERTEX_COLOR_UNCLAMPED: case PIPE_CAP_QUADS_FOLLOW_PROVOKING_VERTEX_CONVENTION: case PIPE_CAP_MIXED_COLORBUFFER_FORMATS: -- 1.8.1.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 29024] gallium build failure: can't find llvm headers
https://bugs.freedesktop.org/show_bug.cgi?id=29024 Laurent carlier lordhea...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Laurent carlier lordhea...@gmail.com --- Old and surely 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 37862] Mesa 7.11-devel implementation error: _mesa_texstore_null() is called
https://bugs.freedesktop.org/show_bug.cgi?id=37862 Laurent carlier lordhea...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Laurent carlier lordhea...@gmail.com --- Old and surely fixed some time ago -- 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] gallivm: do clamping of border color correctly for all formats
Am 19.08.2013 12:45, schrieb Jose Fonseca:
Looks alright to me.
I just wonder if it would be possible to factor this logic into a separate
function somehow.
Initially I wanted to factor out the logic for figuring out if
snorm/unorm clamping is necessary, because coord clamping for shadow ref
requires the same logic. However, I had to ditch that idea because some
of the formats require some specialized clamps essentially, and also
it's not really worth it for that because while shdaodw ref clamping
requires the same logic, only very very few formats are allowed there
hence none of the complicated logic is necessary there.
Could however still easily do a clamp_select_border_color function, or
alternatively could move the border color computation outside the fetch
loop and just precalculate it somewhere at the beginning
(build_sample_common), storing the clamped border color in the sample
build context, which would only leave the per-channel logic of doing
clamp/application of border color in fetch. Not sure though what's better.
Roland
Jose
- Original Message -
From: Roland Scheidegger srol...@vmware.com
Turns out it is actually very complicated to figure out what a format really
is wrt range, as using channel information for determining unorm/snorm etc.
doesn't work for a bunch of cases - namely compressed, subsampled, other.
Also while here add clamping for uint/sint as well - d3d10 doesn't actually
need this (can only use ld with these formats hence no border) and we could
do this outside the shader for GL easily (due to the fixed texture/sampler
relation) do it here do just so I can forget about it.
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 162
++---
1 file changed, 144 insertions(+), 18 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index 76de006..f61c6c5 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -42,6 +42,7 @@
#include util/u_math.h
#include util/u_format.h
#include util/u_cpu_detect.h
+#include util/u_format_rgb9e5.h
#include lp_bld_debug.h
#include lp_bld_type.h
#include lp_bld_const.h
@@ -206,33 +207,158 @@ lp_build_sample_texel_soa(struct
lp_build_sample_context *bld,
lp_build_const_int32(bld-gallivm, chan));
LLVMValueRef border_chan_vec =
lp_build_broadcast_scalar(bld-float_vec_bld, border_chan);
+LLVMValueRef min_clamp = NULL;
+LLVMValueRef max_clamp = NULL;
if (!bld-texel_type.floating) {
border_chan_vec = LLVMBuildBitCast(builder, border_chan_vec,
bld-texel_bld.vec_type,
);
}
-else {
- /*
-* For normalized format need to clamp border color
(technically
-* probably should also quantize the data). Really sucks
doing this
-* here but can't avoid at least for now since this is part
of
-* sampler state and texture format is part of sampler_view
state.
-*/
+/*
+ * For normalized format need to clamp border color (technically
+ * probably should also quantize the data). Really sucks doing
this
+ * here but can't avoid at least for now since this is part of
+ * sampler state and texture format is part of sampler_view
state.
+ * (Could definitely do it outside per-sample loop but llvm
should
+ * take care of that.)
+ * GL expects also expects clamping for uint/sint formats too so
+ * do that as well (d3d10 can't end up here with uint/sint since
it
+ * only supports them with ld).
+ */
+if (format_desc-layout == UTIL_FORMAT_LAYOUT_PLAIN) {
unsigned chan_type = format_desc-channel[chan_s].type;
unsigned chan_norm = format_desc-channel[chan_s].normalized;
- if (chan_type == UTIL_FORMAT_TYPE_SIGNED chan_norm) {
- LLVMValueRef clamp_min;
- clamp_min = lp_build_const_vec(bld-gallivm,
bld-texel_type, -1.0F);
- border_chan_vec = lp_build_clamp(bld-texel_bld,
border_chan_vec,
- clamp_min,
- bld-texel_bld.one);
+ unsigned pure_int =
format_desc-channel[chan_s].pure_integer;
+ if (chan_type == UTIL_FORMAT_TYPE_SIGNED) {
+ if (chan_norm) {
+ min_clamp = lp_build_const_vec(bld-gallivm,
bld-texel_type, -1.0F);
+ max_clamp = bld-texel_bld.one;
+
[Mesa-dev] [PATCH 2/2] radeonsi: Always pre-load separate VGPRs for centroid vs. center interpolation
From: Michel Dänzer michel.daen...@amd.com The LLVM R600 backend currently always uses separate VGPRs for these. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68162 (Centroid interpolation is identical to center interpolation without multisampling, so the shader hardware was only pre-loading one set of interpolation coefficients, and the pixel shader code was using uninitialized values as the centroid interpolation coefficients) Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Michel Dänzer michel.daen...@amd.com --- src/gallium/drivers/radeonsi/si_state_draw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c b/src/gallium/drivers/radeonsi/si_state_draw.c index 7ecaf77..15cb87f 100644 --- a/src/gallium/drivers/radeonsi/si_state_draw.c +++ b/src/gallium/drivers/radeonsi/si_state_draw.c @@ -183,7 +183,8 @@ static void si_pipe_shader_ps(struct pipe_context *ctx, struct si_pipe_shader *s exports_ps = 2; } - spi_ps_in_control = S_0286D8_NUM_INTERP(shader-shader.ninterp); + spi_ps_in_control = S_0286D8_NUM_INTERP(shader-shader.ninterp) | + S_0286D8_BC_OPTIMIZE_DISABLE(1); si_pm4_set_reg(pm4, R_0286E0_SPI_BARYC_CNTL, spi_baryc_cntl); spi_ps_input_ena = shader-spi_ps_input_ena; -- 1.8.4.rc3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] radeonsi: Fix SPI_BARYC_CNTL register initialization
From: Michel Dänzer michel.daen...@amd.com
The centroid / center interpolation related bits have different meanings
as of SI.
Fixes 7 centroid interpolation related piglit tests.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
src/gallium/drivers/radeonsi/si_state_draw.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index f0f2734..7ecaf77 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -123,9 +123,7 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
struct si_pm4_state *pm4;
unsigned i, exports_ps, num_cout, spi_ps_in_control, db_shader_control;
unsigned num_sgprs, num_user_sgprs;
- boolean have_linear = FALSE, have_centroid = FALSE, have_perspective =
FALSE;
- unsigned fragcoord_interp_mode = 0;
- unsigned spi_baryc_cntl, spi_ps_input_ena, spi_shader_z_format;
+ unsigned spi_baryc_cntl = 0, spi_ps_input_ena, spi_shader_z_format;
uint64_t va;
si_pm4_delete_state(rctx, ps, shader-pm4);
@@ -143,27 +141,19 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
switch (shader-shader.input[i].name) {
case TGSI_SEMANTIC_POSITION:
if (shader-shader.input[i].centroid) {
- /* fragcoord_interp_mode will be written to
-* SPI_BARYC_CNTL.POS_FLOAT_LOCATION
+ /* SPI_BARYC_CNTL.POS_FLOAT_LOCATION
* Possible vaules:
* 0 - Position = pixel center (default)
* 1 - Position = pixel centroid
* 2 - Position = iterated sample number XXX:
*What does this mean?
*/
- fragcoord_interp_mode = 1;
+ spi_baryc_cntl |=
S_0286E0_POS_FLOAT_LOCATION(1);
}
/* Fall through */
case TGSI_SEMANTIC_FACE:
continue;
}
-
- if (shader-shader.input[i].interpolate ==
TGSI_INTERPOLATE_LINEAR)
- have_linear = TRUE;
- if (shader-shader.input[i].interpolate ==
TGSI_INTERPOLATE_PERSPECTIVE)
- have_perspective = TRUE;
- if (shader-shader.input[i].centroid)
- have_centroid = TRUE;
}
for (i = 0; i shader-shader.noutput; i++) {
@@ -195,15 +185,6 @@ static void si_pipe_shader_ps(struct pipe_context *ctx,
struct si_pipe_shader *s
spi_ps_in_control = S_0286D8_NUM_INTERP(shader-shader.ninterp);
- spi_baryc_cntl = 0;
- if (have_perspective)
- spi_baryc_cntl |= have_centroid ?
- S_0286E0_PERSP_CENTROID_CNTL(1) :
S_0286E0_PERSP_CENTER_CNTL(1);
- if (have_linear)
- spi_baryc_cntl |= have_centroid ?
- S_0286E0_LINEAR_CENTROID_CNTL(1) :
S_0286E0_LINEAR_CENTER_CNTL(1);
- spi_baryc_cntl |= S_0286E0_POS_FLOAT_LOCATION(fragcoord_interp_mode);
-
si_pm4_set_reg(pm4, R_0286E0_SPI_BARYC_CNTL, spi_baryc_cntl);
spi_ps_input_ena = shader-spi_ps_input_ena;
/* we need to enable at least one of them, otherwise we hang the GPU */
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] radeonsi: Always pre-load separate VGPRs for centroid vs. center interpolation
Le lundi 19 août 2013 16:08:57 Michel Dänzer a écrit : From: Michel Dänzer michel.daen...@amd.com The LLVM R600 backend currently always uses separate VGPRs for these. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68162 (Centroid interpolation is identical to center interpolation without multisampling, so the shader hardware was only pre-loading one set of interpolation coefficients, and the pixel shader code was using uninitialized values as the centroid interpolation coefficients) Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Michel Dänzer michel.daen...@amd.com --- Tested both patches, and they are fixing Portal, Counter Strike:Source, Half Life 2 -- Laurent Carlier ArchLinux Developer http://www.archlinux.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 2/7] st/vdpau: exit gracefully if we fail to create video buffer
On 19/08/13 09:08, Christian König wrote: Am 18.08.2013 14:20, schrieb Emil Velikov: On 18/08/13 12:31, Christian König wrote: Am 17.08.2013 23:51, schrieb Emil Velikov: Otherwise we risk causing memory corruption. v2: forgot the mutex_unlock() Signed-off-by: Emil Velikov emil.l.veli...@gmail.com NAK. Failing is actually not correct here, cause we can still make it work by allocating the video buffer later on decoding or uploading of image data. Let me see if I get this right The API dictates that one can create a surface and there is no guarantee that a video buffer will be associated with it, is that correct ? Actually the API doesn't dictates anything about this (late vs. early allocation of buffers), it's more like I want to give the driver control over this. Makes sense, thanks for the information. Afaics after creating such a surface anyone can call vlVdpVideoSurfaceGetBitsYCbCr() thus getting a NO_IMPLEMENTATION, but then again who in their right mind would want to do that :) Returning NO_IMPLEMENTATION in case a surface doesn't have a backing store yet probably isn't such a good idea. Just clearing the destination buffers to black in vlVdpVideoSurfaceGetBitsYCbCr sound like the valid response to this. If you don't mind I'll leave this exercise for a later moment. Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] auxiliary/vl and st/vdpau, xvmc trivial fixes and cleanups v2
Diff to previous version patch 1,3,4,5,7 - annotate patches with Reviewed-by tags patch 2 - rework completely as per Christian's comments patch 6 - resolve merge conflicts on top of master Patches are also available at guthub for those interested https://github.com/evelikov/Mesa/commits/vl-cleanups-v2 Cheers, Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/7] vdpau/vl 422 chroma width/height mix up
From: Andy Furniss adf.li...@gmail.com
I was looking into some minor 422 issues/discrepencies I noticed long
ago using vdpau on my rv790.
I noticed that there is code that is halving height rather than width -
422 is full height AFAIK.
Making the changes below doesn't actually make any noticable difference
to what I was looking into.
Maybe there are more but here's three I've found so far
Reviewed-by: Christian König christian.koe...@amd.com
---
src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 4 ++--
src/gallium/auxiliary/vl/vl_video_buffer.c | 2 +-
src/gallium/state_trackers/vdpau/surface.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
index b60b22f..5782f62 100644
--- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
+++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c
@@ -1053,8 +1053,8 @@ vl_create_mpeg12_decoder(struct pipe_context *context,
dec-chroma_height = dec-base.height / 2;
dec-num_blocks = dec-num_blocks * 2;
} else if (dec-base.chroma_format == PIPE_VIDEO_CHROMA_FORMAT_422) {
- dec-chroma_width = dec-base.width;
- dec-chroma_height = dec-base.height / 2;
+ dec-chroma_width = dec-base.width / 2;
+ dec-chroma_height = dec-base.height;
dec-num_blocks = dec-num_blocks * 2 + dec-num_blocks;
} else {
dec-chroma_width = dec-base.width;
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index f0ba389..3b599fc 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -240,7 +240,7 @@ vl_video_buffer_template(struct pipe_resource *templ,
templ-width0 /= 2;
templ-height0 /= 2;
} else if (tmpl-chroma_format == PIPE_VIDEO_CHROMA_FORMAT_422) {
- templ-height0 /= 2;
+ templ-width0 /= 2;
}
}
}
diff --git a/src/gallium/state_trackers/vdpau/surface.c
b/src/gallium/state_trackers/vdpau/surface.c
index a26f9b6..ab4d725 100644
--- a/src/gallium/state_trackers/vdpau/surface.c
+++ b/src/gallium/state_trackers/vdpau/surface.c
@@ -174,7 +174,7 @@ vlVdpVideoSurfaceSize(vlVdpSurface *p_surf, int component,
*width /= 2;
*height /= 2;
} else if (p_surf-templat.chroma_format ==
PIPE_VIDEO_CHROMA_FORMAT_422) {
- *height /= 2;
+ *width /= 2;
}
}
if (p_surf-templat.interlaced)
--
1.8.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/7] st/vdpau: don't try to create video buffer when the format is FORMAT_NONE
Not seen in the wild yet, but seems like a reasonable thing to do. [suggested by Christian] Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/gallium/state_trackers/vdpau/surface.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/vdpau/surface.c b/src/gallium/state_trackers/vdpau/surface.c index ab4d725..8e39d68 100644 --- a/src/gallium/state_trackers/vdpau/surface.c +++ b/src/gallium/state_trackers/vdpau/surface.c @@ -88,7 +88,10 @@ vlVdpVideoSurfaceCreate(VdpDevice device, VdpChromaType chroma_type, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_PREFERS_INTERLACED ); - p_surf-video_buffer = pipe-create_video_buffer(pipe, p_surf-templat); + if (p_surf-templat.buffer_format != PIPE_FORMAT_NONE) + p_surf-video_buffer = pipe-create_video_buffer(pipe, p_surf-templat); + + /* do not mandate early allocation of a video buffer */ vlVdpVideoSurfaceClear(p_surf); pipe_mutex_unlock(dev-mutex); -- 1.8.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/7] st/xvmc: exit gracefully if we fail to create video buffer
Free any allocated memory and return BadAlloc if create_video_buffer()
has failed to create a buffer.
Reviewed-by: Christian König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/state_trackers/xvmc/surface.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/gallium/state_trackers/xvmc/surface.c
b/src/gallium/state_trackers/xvmc/surface.c
index 2e67612..13f337c 100644
--- a/src/gallium/state_trackers/xvmc/surface.c
+++ b/src/gallium/state_trackers/xvmc/surface.c
@@ -193,6 +193,10 @@ Status XvMCCreateSurface(Display *dpy, XvMCContext
*context, XvMCSurface *surfac
);
surface_priv-video_buffer = pipe-create_video_buffer(pipe, tmpl);
+ if (!surface_priv-video_buffer) {
+ FREE(surface_priv);
+ return BadAlloc;
+ }
surface_priv-context = context;
surface-surface_id = XAllocID(dpy);
--
1.8.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/7] vl/buffer: add sanity check after CALLOC_STRUCT
Check if we have successfully allocated memory. Reviewed-by: Christian König christian.koe...@amd.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/gallium/auxiliary/vl/vl_video_buffer.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c b/src/gallium/auxiliary/vl/vl_video_buffer.c index 3b599fc..e2cac0a 100644 --- a/src/gallium/auxiliary/vl/vl_video_buffer.c +++ b/src/gallium/auxiliary/vl/vl_video_buffer.c @@ -492,6 +492,8 @@ vl_video_buffer_create_ex2(struct pipe_context *pipe, unsigned i; buffer = CALLOC_STRUCT(vl_video_buffer); + if (!buffer) + return NULL; buffer-base = *tmpl; buffer-base.context = pipe; -- 1.8.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/7] vl/idct: cleanup all idct buffers
Code should loop through and cleanup the three (VL_NUM_COMPONENTS) idct buffers, rather than doing the first one three times. Reviewed-by: Christian König christian.koe...@amd.com Signed-off-by: Emil Velikov emil.l.veli...@gmail.com --- src/gallium/auxiliary/vl/vl_mpeg12_decoder.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c index 5782f62..f838e74 100644 --- a/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c +++ b/src/gallium/auxiliary/vl/vl_mpeg12_decoder.c @@ -198,7 +198,7 @@ cleanup_idct_buffer(struct vl_mpeg12_buffer *buf) assert(buf); for (i = 0; i 3; ++i) - vl_idct_cleanup_buffer(buf-idct[0]); + vl_idct_cleanup_buffer(buf-idct[i]); } static bool -- 1.8.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 6/7] st/vdpau: drop unnecessary variable prof
Any decent compiler will do this for us, although doing this
will make grepping through the code alot easier.
v2: In both mixer and query interface
v3: rebase
Reviewed-by: Christian König christian.koe...@amd.com [v1]
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/state_trackers/vdpau/mixer.c | 7 ---
src/gallium/state_trackers/vdpau/query.c | 7 ---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/src/gallium/state_trackers/vdpau/mixer.c
b/src/gallium/state_trackers/vdpau/mixer.c
index 18439a7..8476329 100644
--- a/src/gallium/state_trackers/vdpau/mixer.c
+++ b/src/gallium/state_trackers/vdpau/mixer.c
@@ -50,7 +50,6 @@ vlVdpVideoMixerCreate(VdpDevice device,
VdpStatus ret;
struct pipe_screen *screen;
unsigned max_width, max_height, i;
- enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN;
vlVdpDevice *dev = vlGetDataHTAB(device);
if (!dev)
@@ -132,8 +131,10 @@ vlVdpVideoMixerCreate(VdpDevice device,
VDPAU_MSG(VDPAU_WARN, [VDPAU] Max layers 4 not supported\n,
vmixer-max_layers);
goto no_params;
}
- max_width = screen-get_video_param(screen, prof,
PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_MAX_WIDTH);
- max_height = screen-get_video_param(screen, prof,
PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_MAX_HEIGHT);
+ max_width = screen-get_video_param(screen, PIPE_VIDEO_PROFILE_UNKNOWN,
+ PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
PIPE_VIDEO_CAP_MAX_WIDTH);
+ max_height = screen-get_video_param(screen, PIPE_VIDEO_PROFILE_UNKNOWN,
+PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
PIPE_VIDEO_CAP_MAX_HEIGHT);
if (vmixer-video_width 48 ||
vmixer-video_width max_width) {
VDPAU_MSG(VDPAU_WARN, [VDPAU] 48 %u %u not valid for width\n,
vmixer-video_width, max_width);
diff --git a/src/gallium/state_trackers/vdpau/query.c
b/src/gallium/state_trackers/vdpau/query.c
index 8c1b27f..72b1fe9 100644
--- a/src/gallium/state_trackers/vdpau/query.c
+++ b/src/gallium/state_trackers/vdpau/query.c
@@ -506,7 +506,6 @@ vlVdpVideoMixerQueryParameterValueRange(VdpDevice device,
VdpVideoMixerParameter
{
vlVdpDevice *dev = vlGetDataHTAB(device);
struct pipe_screen *screen;
- enum pipe_video_profile prof = PIPE_VIDEO_PROFILE_UNKNOWN;
if (!dev)
return VDP_STATUS_INVALID_HANDLE;
@@ -518,12 +517,14 @@ vlVdpVideoMixerQueryParameterValueRange(VdpDevice device,
VdpVideoMixerParameter
switch (parameter) {
case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_WIDTH:
*(uint32_t*)min_value = 48;
- *(uint32_t*)max_value = screen-get_video_param(screen, prof,
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+ *(uint32_t*)max_value = screen-get_video_param(screen,
PIPE_VIDEO_PROFILE_UNKNOWN,
+
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
PIPE_VIDEO_CAP_MAX_WIDTH);
break;
case VDP_VIDEO_MIXER_PARAMETER_VIDEO_SURFACE_HEIGHT:
*(uint32_t*)min_value = 48;
- *(uint32_t*)max_value = screen-get_video_param(screen, prof,
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
+ *(uint32_t*)max_value = screen-get_video_param(screen,
PIPE_VIDEO_PROFILE_UNKNOWN,
+
PIPE_VIDEO_ENTRYPOINT_BITSTREAM,
PIPE_VIDEO_CAP_MAX_HEIGHT);
break;
--
1.8.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 7/7] vl/buffers: consistent use on VL_MAX_SURFACES
Reviewed-by: Christian König christian.koe...@amd.com
Signed-off-by: Emil Velikov emil.l.veli...@gmail.com
---
src/gallium/auxiliary/vl/vl_video_buffer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/gallium/auxiliary/vl/vl_video_buffer.c
b/src/gallium/auxiliary/vl/vl_video_buffer.c
index e2cac0a..d2e9a04 100644
--- a/src/gallium/auxiliary/vl/vl_video_buffer.c
+++ b/src/gallium/auxiliary/vl/vl_video_buffer.c
@@ -259,7 +259,7 @@ vl_video_buffer_destroy(struct pipe_video_buffer *buffer)
pipe_resource_reference(buf-resources[i], NULL);
}
- for (i = 0; i VL_NUM_COMPONENTS * 2; ++i)
+ for (i = 0; i VL_MAX_SURFACES; ++i)
pipe_surface_reference(buf-surfaces[i], NULL);
vl_video_buffer_set_associated_data(buffer, NULL, NULL, NULL);
@@ -365,7 +365,7 @@ vl_video_buffer_surfaces(struct pipe_video_buffer *buffer)
array_size = buffer-interlaced ? 2 : 1;
for (i = 0, surf = 0; i VL_NUM_COMPONENTS; ++i) {
for (j = 0; j array_size; ++j, ++surf) {
- assert(surf (VL_NUM_COMPONENTS * 2));
+ assert(surf VL_MAX_SURFACES);
if (!buf-resources[i]) {
pipe_surface_reference(buf-surfaces[surf], NULL);
@@ -386,7 +386,7 @@ vl_video_buffer_surfaces(struct pipe_video_buffer *buffer)
return buf-surfaces;
error:
- for (i = 0; i (VL_NUM_COMPONENTS * 2); ++i )
+ for (i = 0; i VL_MAX_SURFACES; ++i )
pipe_surface_reference(buf-surfaces[i], NULL);
return NULL;
--
1.8.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/7] st/vdpau: don't try to create video buffer when the format is FORMAT_NONE
On 19/08/13 17:09, Christian König wrote: Am 19.08.2013 18:00, schrieb Emil Velikov: Not seen in the wild yet, but seems like a reasonable thing to do. [suggested by Christian] Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Reviewed-by: Christian König christian.koe...@amd.com Do you have commit access? And by the way I have enough on my to do list for the VDPAU state tracker if you're bored. I do not have commit access, so please feel free to push if things look good. Bug in the nouveau vdpau driver hinted me to look this way, although I would not mind doing a few more things when I have some time (after 27 August). Cheers, Emil Cheers, Christian. --- src/gallium/state_trackers/vdpau/surface.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/gallium/state_trackers/vdpau/surface.c b/src/gallium/state_trackers/vdpau/surface.c index ab4d725..8e39d68 100644 --- a/src/gallium/state_trackers/vdpau/surface.c +++ b/src/gallium/state_trackers/vdpau/surface.c @@ -88,7 +88,10 @@ vlVdpVideoSurfaceCreate(VdpDevice device, VdpChromaType chroma_type, PIPE_VIDEO_ENTRYPOINT_BITSTREAM, PIPE_VIDEO_CAP_PREFERS_INTERLACED ); - p_surf-video_buffer = pipe-create_video_buffer(pipe, p_surf-templat); + if (p_surf-templat.buffer_format != PIPE_FORMAT_NONE) + p_surf-video_buffer = pipe-create_video_buffer(pipe, p_surf-templat); + + /* do not mandate early allocation of a video buffer */ vlVdpVideoSurfaceClear(p_surf); pipe_mutex_unlock(dev-mutex); ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/1] mesa: Properly set the fog scale (gl_Fog.scale) to +INF when fog start and end are equal.
On 08/17/2013 11:42 AM, Henri Verbeet wrote:
This was originally introduced by commit
ba47aabc9868b410cdfe3bc8b6d25a44a598cba2, but unfortunately the commit message
doesn't go into much detail about why +INF would be a problem here. I don't
see anything in the spec that would allow 1.0f here.
A similar issue exists for STATE_FOG_PARAMS_OPTIMIZED, but allowing infinity
there would potentially introduce NaNs where they shouldn't exist, depending
on the values of fog end and the fog coord. Since STATE_FOG_PARAMS_OPTIMIZED
is only used for fixed function (including ARB_fragment_program with fog
option), and the calculation there probably isn't very stable to begin with
when fog start and end are close together, it seems best to just leave it
alone.
This fixes a couple of Wine D3D tests. No piglit changes on Cayman.
Signed-off-by: Henri Verbeet hverb...@gmail.com
---
src/mesa/program/prog_statevars.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index f6073be..657c6e6 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -256,8 +256,7 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index state[],
value[0] = ctx-Fog.Density;
value[1] = ctx-Fog.Start;
value[2] = ctx-Fog.End;
- value[3] = (ctx-Fog.End == ctx-Fog.Start)
- ? 1.0f : (GLfloat)(1.0 / (ctx-Fog.End - ctx-Fog.Start));
+ value[3] = (GLfloat)(1.0 / (ctx-Fog.End - ctx-Fog.Start));
return;
case STATE_CLIPPLANE:
{
I tested conform with this change and didn't see any regressions.
However, let's simply put 'f' on the 1.0 and remove the cast:
value[3] = 1.0f / (ctx-Fog.End - ctx-Fog.Start);
Tested-by: Brian Paul bri...@vmware.com
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 58925] compis/kwin crashes on nouveau due to msaa
https://bugs.freedesktop.org/show_bug.cgi?id=58925 Fabio Pedretti fabio@libero.it changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org CC||fabio@libero.it, ||mar...@gmail.com Product|DRI |Mesa Version|XOrg CVS|git Component|libGL |Mesa core -- 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 68262] wayland-drm.c:110:3: error: implicit declaration of function 'wl_resource_create'
https://bugs.freedesktop.org/show_bug.cgi?id=68262 Fabio Pedretti fabio@libero.it changed: What|Removed |Added CC||conselv...@gmail.com, ||k...@bitplanet.net -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] glsl: Use alignment of container record for its first field
On 17 August 2013 00:37, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com The first field of a record in a UBO has the aligment of the record itself. Fixes piglit vs-struct-pad, fs-struct-pad, and (with the patch posted to the piglit list that extends the test) layout-std140. NOTE: The bit of strangeness with the version of visit_field without the record_type poitner is because that method is pure virtual in the base class. The original implementation of the class did this to ensure derived classes remembered to implement that flavor. Now they can implement either flavor but not both. I don't know a C++ way to enforce that. Signed-off-by: Ian Romanick ian.d.roman...@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68195 Series is: Reviewed-by: Paul Berry stereotype...@gmail.com My gut tells me there is some way to rewrite this code to more closely follow the algorihtm described in the spec. But I'm having trouble fleshing that out into a concrete proposal :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glsl: don't eliminate texcoords that can be set by GL_COORD_REPLACE
Hi Ian,
In case you're interested, I have noticed we have no piglit tests for
GL_ARB_base_instance. For example, baseinstance shouldn't affect
gl_InstanceID, which is currently broken in radeonsi.
Marek
On Sun, Aug 18, 2013 at 5:23 AM, Ian Romanick i...@freedesktop.org wrote:
On 08/09/2013 01:40 PM, Marek Olšák wrote:
Tested by examining generated TGSI shaders from piglit/glsl-routing.
Cc: mesa-sta...@lists.freedesktop.org
This patch was in my review-queue, and I forgot about it. Sorry. :(
Reviewed-by: Ian Romanick ian.d.roman...@intel.com
Since this also fixes an application, do you have any idea what could be
done to make a piglit test to reproduce the failure? We have some folks
writing piglit tests for us this summer, and this sounds like a good one for
them. :)
---
src/glsl/ir_optimization.h | 2 +-
src/glsl/linker.cpp| 6 +++---
src/glsl/opt_dead_builtin_varyings.cpp | 27 +++
3 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index a61227b..b79c2b7 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -77,7 +77,7 @@ bool do_copy_propagation(exec_list *instructions);
bool do_copy_propagation_elements(exec_list *instructions);
bool do_constant_propagation(exec_list *instructions);
void do_dead_builtin_varyings(struct gl_context *ctx,
- exec_list *producer, exec_list *consumer,
+ gl_shader *producer, gl_shader *consumer,
unsigned num_tfeedback_decls,
class tfeedback_decl *tfeedback_decls);
bool do_dead_code(exec_list *instructions, bool
uniform_locations_assigned);
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index d36f627..f87ae0e 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -2091,7 +2091,7 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
goto done;
}
- do_dead_builtin_varyings(ctx, sh-ir, NULL,
+ do_dead_builtin_varyings(ctx, sh, NULL,
num_tfeedback_decls, tfeedback_decls);
demote_shader_inputs_and_outputs(sh, ir_var_shader_out);
@@ -2106,7 +2106,7 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
*/
gl_shader *const sh = prog-_LinkedShaders[first];
- do_dead_builtin_varyings(ctx, NULL, sh-ir,
+ do_dead_builtin_varyings(ctx, NULL, sh,
num_tfeedback_decls, tfeedback_decls);
demote_shader_inputs_and_outputs(sh, ir_var_shader_in);
@@ -2130,7 +2130,7 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
tfeedback_decls, gs_input_vertices))
goto done;
- do_dead_builtin_varyings(ctx, sh_i-ir, sh_next-ir,
+ do_dead_builtin_varyings(ctx, sh_i, sh_next,
next == MESA_SHADER_FRAGMENT ? num_tfeedback_decls : 0,
tfeedback_decls);
diff --git a/src/glsl/opt_dead_builtin_varyings.cpp
b/src/glsl/opt_dead_builtin_varyings.cpp
index 2e813d2..6745d5c 100644
--- a/src/glsl/opt_dead_builtin_varyings.cpp
+++ b/src/glsl/opt_dead_builtin_varyings.cpp
@@ -409,7 +409,7 @@ lower_texcoord_array(exec_list *ir, const
varying_info_visitor *info)
void
do_dead_builtin_varyings(struct gl_context *ctx,
- exec_list *producer, exec_list *consumer,
+ gl_shader *producer, gl_shader *consumer,
unsigned num_tfeedback_decls,
tfeedback_decl *tfeedback_decls)
{
@@ -431,44 +431,55 @@ do_dead_builtin_varyings(struct gl_context *ctx,
varying_info_visitor consumer_info(ir_var_shader_in);
if (producer) {
- producer_info.get(producer, num_tfeedback_decls, tfeedback_decls);
+ producer_info.get(producer-ir, num_tfeedback_decls,
tfeedback_decls);
if (!consumer) {
/* At least eliminate unused gl_TexCoord elements. */
if (producer_info.lower_texcoord_array) {
-lower_texcoord_array(producer, producer_info);
+lower_texcoord_array(producer-ir, producer_info);
}
return;
}
}
if (consumer) {
- consumer_info.get(consumer, 0, NULL);
+ consumer_info.get(consumer-ir, 0, NULL);
if (!producer) {
/* At least eliminate unused gl_TexCoord elements. */
if (consumer_info.lower_texcoord_array) {
-lower_texcoord_array(consumer, consumer_info);
+lower_texcoord_array(consumer-ir, consumer_info);
}
return;
}
}
- /* Eliminate the varyings unused by the other shader. */
+ /* Eliminate the outputs unused by the consumer. */
if
[Mesa-dev] [Bug 68296] New: Using old viewport value after a window resize (content is clipped)
https://bugs.freedesktop.org/show_bug.cgi?id=68296 Priority: medium Bug ID: 68296 Assignee: mesa-dev@lists.freedesktop.org Summary: Using old viewport value after a window resize (content is clipped) Severity: normal Classification: Unclassified OS: Linux (All) Reporter: antogno...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa Created attachment 84295 -- https://bugs.freedesktop.org/attachment.cgi?id=84295action=edit Sample code that reproduces the problem. In the attached sample code, a window is created with 100x100. However, after resizing it with i keyboard input to 200x200, changing the viewport (with glViewport), and drawing its content again, the content is clipped with the old 100x100 size. Uncommenting line 48 will remove the bug, as if it was causing mesa to flush the viewport size. I noticed this on EFL (Enlightenment Foundation Libraries), both on GL X11 and Wayland EGL backends. This bug only happens on mesa from git, it seems that there's no bug on 9.1.6. I checked bug #29984, it's similar, but I still have the problem. Running on Fedora 19. -- 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 2/2] mesa: Never advertise _S3TC compressed formats
From: Ian Romanick ian.d.roman...@intel.com
The NVIDIA driver doesn't expose them, and piglit's
arb_texture_compression-invalid-formats expects them to not be there.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: 9.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/texcompress.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index 334ea40..e71d0c4 100644
--- a/src/mesa/main/texcompress.c
+++ b/src/mesa/main/texcompress.c
@@ -264,18 +264,6 @@ _mesa_get_compressed_formats(struct gl_context *ctx, GLint
*formats)
n += 3;
}
}
- if (_mesa_is_desktop_gl(ctx)
-ctx-Extensions.ANGLE_texture_compression_dxt) {
- if (formats) {
- formats[n++] = GL_RGB_S3TC;
- formats[n++] = GL_RGB4_S3TC;
- formats[n++] = GL_RGBA_S3TC;
- formats[n++] = GL_RGBA4_S3TC;
- }
- else {
- n += 4;
- }
- }
/* The GL_OES_compressed_ETC1_RGB8_texture spec says:
*
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] mesa: Only advertise GL_ETC1_RGB8_OES in ES contexts
From: Ian Romanick ian.d.roman...@intel.com
There is no extension for this format in desktop GL, so an application
can't give the format back to glCompressedTexImage2D.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: 9.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/texcompress.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index 5885944..334ea40 100644
--- a/src/mesa/main/texcompress.c
+++ b/src/mesa/main/texcompress.c
@@ -277,7 +277,15 @@ _mesa_get_compressed_formats(struct gl_context *ctx, GLint
*formats)
}
}
- if (ctx-Extensions.OES_compressed_ETC1_RGB8_texture) {
+ /* The GL_OES_compressed_ETC1_RGB8_texture spec says:
+*
+* New State
+*
+* The queries for NUM_COMPRESSED_TEXTURE_FORMATS and
+* COMPRESSED_TEXTURE_FORMATS include ETC1_RGB8_OES.
+*/
+ if (_mesa_is_gles(ctx)
+ctx-Extensions.OES_compressed_ETC1_RGB8_texture) {
if (formats) {
formats[n++] = GL_ETC1_RGB8_OES;
}
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 68297] New: Mesa tries to detect AVX support and fails horribly
https://bugs.freedesktop.org/show_bug.cgi?id=68297 Priority: medium Bug ID: 68297 Assignee: mesa-dev@lists.freedesktop.org Summary: Mesa tries to detect AVX support and fails horribly Severity: major Classification: Unclassified OS: Linux (All) Reporter: delr...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa src/gallium/auxiliary/util/u_cpu_detect.c: util_cpu_caps.has_avx= ((regs2[2] 28) 1) // AVX This is wrong. To check for AVX support, you need to: 1. Check if the AVX bit is set in cpuid (DONE) 2. Check if the XSAVE bit is set in cpuid (NOT DONE) 3. Check if xgetbv with ecx=0 XFEATURE_ENABLED_MASK == XFEATURE_ENABLED_MASK (NOT DONE) See, for example: https://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/X86/X86Subtarget.cpp?r1=180991r2=180990pathrev=180991 https://code.google.com/p/dolphin-emu/source/detail?r=377202b9f6154ae56c5b2f0a45e235ceaeb6da9c Intel have some reference material about that but software.intel.com seems to be down at the moment. When trying to run llvmpipe on a machine with hardware AVX support but no kernel support for it, it currently SIGILLs. -- 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] Mesa 9.2 release candidate 1
Mesa 9.2 release candidate 1 is now available for testing. The tag in the GIT repository for Mesa 9.2-rc1 is 'mesa-9.2-rc1'. Mesa 9.2 release candidate 1 is available for download at ftp://freedesktop.org/pub/mesa/9.2/ md5sums: 866e9a1b3ce72b822671ee8106821aec MesaLib-9.2.0-rc1.tar.bz2 4506de8ad53e8dc16ba10508e1b9783b MesaLib-9.2.0-rc1.tar.gz d4f91a3982bed348291c69c92d883acc MesaLib-9.2.0-rc1.zip I have verified building from the .tar.bz2 file by doing: tar -xjf Mesa-9.2.0-rc1.tar.bz2 cd Mesa-9.2.0-rc1 ./configure --enable-gallium-llvm --with-llvm-shared-libs make -j6 make install I have also verified that I pushed the tag. I had originally intended to start doing RCs several weeks ago. However, basically, I forgot. The 9.2 release is scheduled for this Thursday. If folks would like to delay the due to the non-availability of RCs, please speak up. I'd rather not, but, since I fell down on the job, I won't argue if others would like a delay. Thanks to Sven Joachim for reminding me. :) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: Never advertise _S3TC compressed formats
On Mon, Aug 19, 2013 at 4:38 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
The NVIDIA driver doesn't expose them, and piglit's
arb_texture_compression-invalid-formats expects them to not be there.
Signed-off-by: Ian Romanick ian.d.roman...@intel.com
Cc: 9.2 mesa-sta...@lists.freedesktop.org
---
src/mesa/main/texcompress.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/mesa/main/texcompress.c b/src/mesa/main/texcompress.c
index 334ea40..e71d0c4 100644
--- a/src/mesa/main/texcompress.c
+++ b/src/mesa/main/texcompress.c
@@ -264,18 +264,6 @@ _mesa_get_compressed_formats(struct gl_context *ctx,
GLint *formats)
n += 3;
}
}
- if (_mesa_is_desktop_gl(ctx)
-ctx-Extensions.ANGLE_texture_compression_dxt) {
- if (formats) {
- formats[n++] = GL_RGB_S3TC;
- formats[n++] = GL_RGB4_S3TC;
- formats[n++] = GL_RGBA_S3TC;
- formats[n++] = GL_RGBA4_S3TC;
- }
- else {
- n += 4;
- }
- }
/* The GL_OES_compressed_ETC1_RGB8_texture spec says:
*
--
1.8.1.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Both patches are:
Reviewed-by: Anuj Phogat anuj.pho...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/3] util: add avx2 and xop detection to cpu detection code
From: Roland Scheidegger srol...@vmware.com
Going to need this soon (not going to bother with avx2 intrinsics at this time
but don't want to do workarounds for true vector shifts if llvm itself can use
them just fine and won't need the gazillion instruction emulation).
Not really tested other than my cpu returns 0 for these features...
(I have no idea if llvm actually would emit avx2/xop instructions neither...)
---
src/gallium/auxiliary/gallivm/lp_bld_init.c | 11 --
src/gallium/auxiliary/util/u_cpu_detect.c | 48 +++
src/gallium/auxiliary/util/u_cpu_detect.h |2 ++
3 files changed, 59 insertions(+), 2 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
index 61eadb8..61b561f 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_init.c
@@ -461,12 +461,15 @@ lp_build_init(void)
lp_native_vector_width);
if (lp_native_vector_width = 128) {
- /* Hide AVX support, as often LLVM AVX instrinsics are only guarded by
+ /* Hide AVX support, as often LLVM AVX intrinsics are only guarded by
* util_cpu_caps.has_avx predicate, and lack the
* lp_native_vector_width 128 predicate. And also to ensure a more
* consistent behavior, allowing one to test SSE2 on AVX machines.
+ * XXX: should not play games with util_cpu_caps directly as it might
+ * get used for other things outside llvm too.
*/
util_cpu_caps.has_avx = 0;
+ util_cpu_caps.has_avx2 = 0;
}
if (!HAVE_AVX) {
@@ -476,13 +479,17 @@ lp_build_init(void)
* omit it unnecessarily on amd cpus, see above).
*/
util_cpu_caps.has_f16c = 0;
+ util_cpu_caps.has_xop = 0;
}
#ifdef PIPE_ARCH_PPC_64
/* Set the NJ bit in VSCR to 0 so denormalized values are handled as
-* specified by IEEE standard (PowerISA 2.06 - Section 6.3). This garantees
+* specified by IEEE standard (PowerISA 2.06 - Section 6.3). This guarantees
* that some rounding and half-float to float handling does not round
* incorrectly to 0.
+* XXX: should eventually follow same logic on all platforms.
+* Right now denorms get explicitly disabled (but elsewhere) for x86,
+* whereas ppc64 explicitly enables them...
*/
if (util_cpu_caps.has_altivec) {
unsigned short mask[] = { 0x, 0x, 0x, 0x,
diff --git a/src/gallium/auxiliary/util/u_cpu_detect.c
b/src/gallium/auxiliary/util/u_cpu_detect.c
index 87ad780..2ff40bb 100644
--- a/src/gallium/auxiliary/util/u_cpu_detect.c
+++ b/src/gallium/auxiliary/util/u_cpu_detect.c
@@ -212,6 +212,44 @@ cpuid(uint32_t ax, uint32_t *p)
#endif
}
+/**
+ * @sa cpuid.h included in gcc-4.4 onwards.
+ * @sa http://msdn.microsoft.com/en-us/library/hskdteyh%28v=vs.90%29.aspx
+ */
+static INLINE void
+cpuid_count(uint32_t ax, uint32_t cx, uint32_t *p)
+{
+#if (defined(PIPE_CC_GCC) || defined(PIPE_CC_SUNPRO)) defined(PIPE_ARCH_X86)
+ __asm __volatile (
+ xchgl %%ebx, %1\n\t
+ cpuid\n\t
+ xchgl %%ebx, %1
+ : =a (p[0]),
+ =S (p[1]),
+ =c (p[2]),
+ =d (p[3])
+ : 0 (ax), 2 (cx)
+ );
+#elif (defined(PIPE_CC_GCC) || defined(PIPE_CC_SUNPRO))
defined(PIPE_ARCH_X86_64)
+ __asm __volatile (
+ cpuid\n\t
+ : =a (p[0]),
+ =b (p[1]),
+ =c (p[2]),
+ =d (p[3])
+ : 0 (ax), 2 (cx)
+ );
+#elif defined(PIPE_CC_MSVC)
+ __cpuidex(p, ax, cx);
+#else
+ p[0] = 0;
+ p[1] = 0;
+ p[2] = 0;
+ p[3] = 0;
+#endif
+}
+
+
static INLINE uint64_t xgetbv(void)
{
#if defined(PIPE_CC_GCC)
@@ -341,6 +379,11 @@ util_cpu_detect(void)
if (cacheline 0)
util_cpu_caps.cacheline = cacheline;
}
+ if (util_cpu_caps.has_avx regs[0] = 0x0007) {
+ uint32_t regs7[4];
+ cpuid_count(0x0007, 0x, regs7);
+ util_cpu_caps.has_avx2 = (regs7[1] 5) 1;
+ }
if (regs[1] == 0x756e6547 regs[2] == 0x6c65746e regs[3] ==
0x49656e69) {
/* GenuineIntel */
@@ -357,6 +400,9 @@ util_cpu_detect(void)
util_cpu_caps.has_mmx2 |= (regs2[3] 22) 1;
util_cpu_caps.has_3dnow = (regs2[3] 31) 1;
util_cpu_caps.has_3dnow_ext = (regs2[3] 30) 1;
+
+ util_cpu_caps.has_xop = util_cpu_caps.has_avx
+ ((regs2[2] 11) 1);
}
if (regs[0] = 0x8006) {
@@ -394,10 +440,12 @@ util_cpu_detect(void)
debug_printf(util_cpu_caps.has_sse4_1 = %u\n,
util_cpu_caps.has_sse4_1);
debug_printf(util_cpu_caps.has_sse4_2 = %u\n,
util_cpu_caps.has_sse4_2);
debug_printf(util_cpu_caps.has_avx = %u\n, util_cpu_caps.has_avx);
+ debug_printf(util_cpu_caps.has_avx2 = %u\n, util_cpu_caps.has_avx2);
debug_printf(util_cpu_caps.has_f16c = %u\n, util_cpu_caps.has_f16c);
debug_printf(util_cpu_caps.has_popcnt =
[Mesa-dev] [PATCH 2/3] gallivm: fix bogus aos path detection
From: Roland Scheidegger srol...@vmware.com
Need to check the wrap mode of the actually used coords not a fixed 2.
While checking more than necessary would only potentially disable aos and
not cause any harm I'm pretty sure for 3d textures it could have caused
assertion failures (if s,t coords have simple filter and r not).
---
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index 9f781c5..6d12587 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -2034,21 +2034,27 @@ lp_build_sample_soa(struct gallivm_state *gallivm,
LLVMValueRef lod_ipart = NULL, lod_fpart = NULL;
LLVMValueRef ilevel0 = NULL, ilevel1 = NULL;
boolean use_aos = util_format_fits_8unorm(bld.format_desc)
-lp_is_simple_wrap_mode(static_sampler_state-wrap_s)
-lp_is_simple_wrap_mode(static_sampler_state-wrap_t)
/* not sure this is strictly needed or simply
impossible */
-static_sampler_state-compare_mode ==
PIPE_TEX_COMPARE_NONE;
+static_sampler_state-compare_mode ==
PIPE_TEX_COMPARE_NONE
+lp_is_simple_wrap_mode(static_sampler_state-wrap_s);
+ if (dims 1) {
+ use_aos = lp_is_simple_wrap_mode(static_sampler_state-wrap_t);
+ if (dims 2) {
+use_aos = lp_is_simple_wrap_mode(static_sampler_state-wrap_r);
+ }
+ }
if ((gallivm_debug GALLIVM_DEBUG_PERF)
!use_aos util_format_fits_8unorm(bld.format_desc)) {
debug_printf(%s: using floating point linear filtering for %s\n,
__FUNCTION__, bld.format_desc-short_name);
- debug_printf( min_img %d mag_img %d mip %d wraps %d wrapt %d\n,
+ debug_printf( min_img %d mag_img %d mip %d wraps %d wrapt %d
wrapr %d\n,
static_sampler_state-min_img_filter,
static_sampler_state-mag_img_filter,
static_sampler_state-min_mip_filter,
static_sampler_state-wrap_s,
- static_sampler_state-wrap_t);
+ static_sampler_state-wrap_t,
+ static_sampler_state-wrap_r);
}
lp_build_sample_common(bld, texture_index, sampler_index,
--
1.7.9.5
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/3] gallivm: do clamping of border color correctly for all formats
From: Roland Scheidegger srol...@vmware.com
Turns out it is actually very complicated to figure out what a format really
is wrt range, as using channel information for determining unorm/snorm etc.
doesn't work for a bunch of cases - namely compressed, subsampled, other.
Also while here add clamping for uint/sint as well - d3d10 doesn't actually
need this (can only use ld with these formats hence no border) and we could
do this outside the shader for GL easily (due to the fixed texture/sampler
relation) do it here too just so I can forget about it.
v2: move border color clamping out of fetch texel. Also change it to clamp
the whole border vector at once (and use vectorized load of border color),
which saves a couple of instructions - needs some different handling of
mixed signed/unsigned formats so skip the per channel stuff and just derive
this from first channel except for special formats.
---
src/gallium/auxiliary/gallivm/lp_bld_sample.h |2 +
src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c | 300 +
2 files changed, 256 insertions(+), 46 deletions(-)
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample.h
b/src/gallium/auxiliary/gallivm/lp_bld_sample.h
index 6d17377..067a995 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample.h
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample.h
@@ -291,6 +291,8 @@ struct lp_build_sample_context
/** Integer vector with texture width, height, depth */
LLVMValueRef int_size;
+
+ LLVMValueRef border_color_clamped;
};
diff --git a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
index 2ffe21f..9f781c5 100644
--- a/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
+++ b/src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c
@@ -42,6 +42,7 @@
#include util/u_math.h
#include util/u_format.h
#include util/u_cpu_detect.h
+#include util/u_format_rgb9e5.h
#include lp_bld_debug.h
#include lp_bld_type.h
#include lp_bld_const.h
@@ -180,17 +181,14 @@ lp_build_sample_texel_soa(struct lp_build_sample_context
*bld,
if (use_border) {
/* select texel color or border color depending on use_border. */
- LLVMValueRef border_color_ptr =
- bld-dynamic_state-border_color(bld-dynamic_state,
- bld-gallivm, sampler_unit);
- const struct util_format_description *format_desc;
+ const struct util_format_description *format_desc = bld-format_desc;
int chan;
- format_desc = util_format_description(bld-static_texture_state-format);
+ struct lp_type border_type = bld-texel_type;
+ border_type.length = 4;
/*
* Only replace channels which are actually present. The others should
* get optimized away eventually by sampler_view swizzle anyway but it's
- * easier too as we'd need some extra logic for channels where we can't
- * determine the format directly otherwise.
+ * easier too.
*/
for (chan = 0; chan 4; chan++) {
unsigned chan_s;
@@ -201,41 +199,17 @@ lp_build_sample_texel_soa(struct lp_build_sample_context
*bld,
}
}
if (chan_s = 3) {
-LLVMValueRef border_chan =
- lp_build_array_get(bld-gallivm, border_color_ptr,
- lp_build_const_int32(bld-gallivm, chan));
-LLVMValueRef border_chan_vec =
- lp_build_broadcast_scalar(bld-float_vec_bld, border_chan);
-
-if (!bld-texel_type.floating) {
- border_chan_vec = LLVMBuildBitCast(builder, border_chan_vec,
- bld-texel_bld.vec_type, );
-}
-else {
- /*
-* For normalized format need to clamp border color (technically
-* probably should also quantize the data). Really sucks doing
this
-* here but can't avoid at least for now since this is part of
-* sampler state and texture format is part of sampler_view
state.
-*/
- unsigned chan_type = format_desc-channel[chan_s].type;
- unsigned chan_norm = format_desc-channel[chan_s].normalized;
- if (chan_type == UTIL_FORMAT_TYPE_SIGNED chan_norm) {
- LLVMValueRef clamp_min;
- clamp_min = lp_build_const_vec(bld-gallivm,
bld-texel_type, -1.0F);
- border_chan_vec = lp_build_clamp(bld-texel_bld,
border_chan_vec,
- clamp_min,
- bld-texel_bld.one);
- }
- else if (chan_type == UTIL_FORMAT_TYPE_UNSIGNED chan_norm) {
- border_chan_vec = lp_build_clamp(bld-texel_bld,
border_chan_vec,
- bld-texel_bld.zero,
-
