[Mesa-dev] [PATCH] intel: GetBuffer fix
After copy buffer on preGEN6, it is necessary to wait for the blit to
complete before returning data to the user.
This fixes the piglit test: copy_buffer_coherency.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
src/mesa/drivers/dri/intel/intel_buffer_objects.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
index 439d6fc..703300b 100644
--- a/src/mesa/drivers/dri/intel/intel_buffer_objects.c
+++ b/src/mesa/drivers/dri/intel/intel_buffer_objects.c
@@ -282,12 +282,17 @@ intel_bufferobj_get_subdata(struct gl_context * ctx,
GLvoid * data, struct gl_buffer_object *obj)
{
struct intel_buffer_object *intel_obj = intel_buffer_object(obj);
+ struct intel_context *intel = intel_context(ctx);
assert(intel_obj);
if (intel_obj-sys_buffer)
memcpy(data, (char *)intel_obj-sys_buffer + offset, size);
- else
+ else {
+ if (drm_intel_bo_references(intel-batch.bo, intel_obj-buffer)) {
+intel_batchbuffer_flush(intel);
+ }
drm_intel_bo_get_subdata(intel_obj-buffer, offset, size, data);
+ }
}
--
1.7.6
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Add support for ROUND
- Original Message - On 8 August 2011 03:58, Jose Fonseca jfons...@vmware.com wrote: It's subjective. It depends on the expected input distribution, which is effectively impossible to characterize in general. One can easily find datasets where one method gives biased results and the other not, and vice versa. And if one takes all possible numbers, they are equally good. This is probably largely irrelevant to the patch in question, but just for arguments sake, I don't think that's true. The function floor(x + .5) will introduce positive bias regardless of input distribution, I thought the patch implemented round to +/- infinity. Indeed round to +infinitity indeed has a bias. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Add support for ROUND
On 8 August 2011 03:58, Jose Fonseca jfons...@vmware.com wrote: It's subjective. It depends on the expected input distribution, which is effectively impossible to characterize in general. One can easily find datasets where one method gives biased results and the other not, and vice versa. And if one takes all possible numbers, they are equally good. This is probably largely irrelevant to the patch in question, but just for arguments sake, I don't think that's true. The function floor(x + .5) will introduce positive bias regardless of input distribution, I thought the patch implemented round to +/- infinity. Indeed round to +infinitity indeed has a bias. IMHO, positive numbers are more common in shaders than negative, and for those, the floor(x+0.5) approach would create correct results (= human rounding, away from zero) while rndne would not. Will rewrite to use rndne though if that's the consensus. - Lauri ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D Greetings Egon Ashrafinia ( IRC: Wubbbi ) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 01:01:14AM -0700, Corbin Simpson wrote: On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. This then is what S2TC is for. Distros could ALREADY take S2TC and include that, while most gamers wouldn't see a difference, while feeling safer from those patents (whether it is actually a successful evasion, only a judge can decide). The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On Son, 2011-08-07 at 13:14 +0900, Chia-I Wu wrote: On Sat, Aug 6, 2011 at 5:07 AM, Chad Versace c...@chad-versace.us wrote: On 08/05/2011 05:41 AM, Dan Nicholson wrote: On Thu, Aug 4, 2011 at 7:55 PM, Chad Versace c...@chad-versace.us wrote: The entirety of the Android project --- libc, webkit, the window manager, *everything* --- exists in a single source tree [1]. And that source tree is built with a single, non-recursive invocation of make. Every time I say that, I find it hard to believe myself, so I'll say it again: The entirety of the Android OS, all core libraries and apps, are built with a single, non-recursive invocation of make. (The kernel is the special exception to this all-encompassing build). The final build artifact is a bootable iso image. [1] http://android.git.kernel.org/ Looking at all those git repos, wouldn't this be more appropriate as an android project? platform/external/mesa or something? Mesa already belongs to the Android x86 tree [1] as platform/external/mesa. (The Android x86 project is a fork that closely mirrors upstream Android). It also exists as such in some private trees. [1] http://git.android-x86.org/ I haven't seen any Android.mk files show up in freetype or expat or anything like that. In the same way, mesa doesn't carry a debian folder even though that's how debian and ubuntu build mesa. Certainly if there are fixes to the existing build infrastructure that help get mesa built on android, that should be done, but I don't see why we should carry the android build bits in upstream mesa. -- Dan Dan, you make a strong point. There's no sense in cluttering Mesa with additional makefiles, at least not now. Other projects do not do that for Android, and Mesa doesn't even do it for beloved Debian. The best approach would be to maintain the Android makefiles in a separate branch, perhaps even in a personal repo. I do not have a strong motivation to upstream Android support because - it requires changes to Android framework - it introduces yet another build system to Mesa I said this a few months back on mesa-user or -dev when asked. But generally, I think the not cluttering Mesa with another build system is debatable. I know I conflict with myself here, but if someone ports Mesa to arguably the most widely used OS and would like to upstream it, should we shut it down because the OS _requires_ its own build system? Incidentally, gstreamer has Android.mk upstream. Will a single set of Android.mk files work for all potentially relevant Android trees? To fix the existing build infrastructure to support Android, I would like to extract source lists for some targets into a shared makefile, similiar to what has been done with src/mesa/sources.mak. Jose suggested this, and I think this is the best way to continue. Yes, that surely will make the out-of-tree port be more future proof. I think we can make SCons parses the source list too. That would be awesome. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] r600g: Add support for ROUND, v2
From f76d23a57996eea6862d3bd899e08f9cb3ac5dec Mon Sep 17 00:00:00 2001
From: Lauri Kasanen c...@gmx.com
Date: Mon, 8 Aug 2011 12:20:27 +0300
Subject: [PATCH] r600g: Add support for ROUND, v2
This is a GLSL 1.3 feature, but also used by MLAA.
Signed-off-by: Lauri Kasanen c...@gmx.com
---
src/gallium/drivers/r600/r600_asm.c|2 ++
src/gallium/drivers/r600/r600_shader.c |6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/r600/r600_asm.c
b/src/gallium/drivers/r600/r600_asm.c
index 5fae2b0..24af991 100644
--- a/src/gallium/drivers/r600/r600_asm.c
+++ b/src/gallium/drivers/r600/r600_asm.c
@@ -88,6 +88,7 @@ static inline unsigned int r600_bc_get_num_operands(struct
r600_bc *bc, struct r
case V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_INT_TO_FLT:
case V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_SIN:
case V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_COS:
+ case V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_RNDNE:
return 1;
default: R600_ERR(
Need instruction operand number for 0x%x.\n,
alu-inst);
@@ -140,6 +141,7 @@ static inline unsigned int r600_bc_get_num_operands(struct
r600_bc *bc, struct r
case EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_INT_TO_FLT:
case EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_SIN:
case EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_COS:
+ case EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_RNDNE:
return 1;
default: R600_ERR(
Need instruction operand number for 0x%x.\n,
alu-inst);
diff --git a/src/gallium/drivers/r600/r600_shader.c
b/src/gallium/drivers/r600/r600_shader.c
index 3e21ad1..4034a93 100644
--- a/src/gallium/drivers/r600/r600_shader.c
+++ b/src/gallium/drivers/r600/r600_shader.c
@@ -3228,7 +3228,7 @@ static struct r600_shader_tgsi_instruction
r600_shader_tgsi_instruction[] = {
{TGSI_OPCODE_FRC, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_FRACT,
tgsi_op2},
{TGSI_OPCODE_CLAMP, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_FLR, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_FLOOR,
tgsi_op2},
- {TGSI_OPCODE_ROUND, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
+ {TGSI_OPCODE_ROUND, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_RNDNE,
tgsi_op2},
{TGSI_OPCODE_EX2, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_EXP_IEEE,
tgsi_trans_srcx_replicate},
{TGSI_OPCODE_LG2, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_LOG_IEEE,
tgsi_trans_srcx_replicate},
{TGSI_OPCODE_POW, 0, V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_pow},
@@ -3386,7 +3386,7 @@ static struct r600_shader_tgsi_instruction
eg_shader_tgsi_instruction[] = {
{TGSI_OPCODE_FRC, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_FRACT,
tgsi_op2},
{TGSI_OPCODE_CLAMP, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_FLR, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_FLOOR,
tgsi_op2},
- {TGSI_OPCODE_ROUND, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
+ {TGSI_OPCODE_ROUND, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_RNDNE,
tgsi_op2},
{TGSI_OPCODE_EX2, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_EXP_IEEE,
tgsi_trans_srcx_replicate},
{TGSI_OPCODE_LG2, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_LOG_IEEE,
tgsi_trans_srcx_replicate},
{TGSI_OPCODE_POW, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_pow},
@@ -3544,7 +3544,7 @@ static struct r600_shader_tgsi_instruction
cm_shader_tgsi_instruction[] = {
{TGSI_OPCODE_FRC, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_FRACT,
tgsi_op2},
{TGSI_OPCODE_CLAMP, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
{TGSI_OPCODE_FLR, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_FLOOR,
tgsi_op2},
- {TGSI_OPCODE_ROUND, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
tgsi_unsupported},
+ {TGSI_OPCODE_ROUND, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_RNDNE,
tgsi_op2},
{TGSI_OPCODE_EX2, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_EXP_IEEE,
cayman_emit_float_instr},
{TGSI_OPCODE_LG2, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_LOG_IEEE,
cayman_emit_float_instr},
{TGSI_OPCODE_POW, 0, EG_V_SQ_ALU_WORD1_OP2_SQ_OP2_INST_NOP,
cayman_pow},
--
1.7.2.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] hardware xvmc video decoding with nouveau
Am Samstag, den 06.08.2011, 14:37 -0400 schrieb Younes Manton:
The attached patch I believe should satisfy everyone's needs here. It
removes the use of pipe_video_decode_buffer from the state tracker and
moves it to the shader decoder. This lets every decoder parse the
incoming macroblocks themselves so they can do whatever they need.
Beside the fact that this patch adds a couple of bugs, you are just
going back to a design wich has already proven to be a bit flaw full.
Please take a look at these two documents first:
http://msdn.microsoft.com/en-us/library/ff568441(v=VS.85).aspx
http://cgit.freedesktop.org/libva/tree/va/va.h
The problem I tried to solve with pipe_video_decode_buffer is that it is
valid for XvMC to do something like that:
XvMCRenderSurface(target A);
XvMCRenderSurface(target B);
XvMCRenderSurface(target A);
XvMCPutSurface(target A);
XvMCRenderSurface(target B);
XvMCPutSurface(target B);
That behaviour creates a bunch of problems when the decoder can only
work on whole frames, because you can't switch the decoding target while
inside a frame. This is an ugliness of the XvMC, which in the past made
it problematic to use it with a couple of hardware decoder.
Most modern players doesn't do it like this any more, but it still seems
to cause a bunch of problems when seeking or fast forward both with
mplayer and xine.
So I would suggest we design the interface something like this:
1. We have a create_buffer call witch will return just a void pointer.
This makes it possible for decoders witch needs frame based decoding to
return an pointer to an internal frame decoding buffer, while it still
makes it possible for an decoder which is slice based to just return a
pointer to itself (for example) with this value not being used
otherwise.
2. We have a begin_frame/render/render.../end_frame calls just like
DXVA, to clearly distinct the start and end of a frame, for frame based
decoder this makes it possible to do clean housekeeping of the internal
buffer, while with slice level decoder begin_frame and end_frame are
just noops.
3. We pass the render target and the buffer to begin/render/end.
This enables slice level decoder to start their decoding earlier, while
it still keeps the burden of figuring out where a frame start/ends to
the XvMC state tracker.
Too big to inline, see attached. Tested on XvMC/VDPAU with softpipe
and an RV620 with a couple of videos (this doesn't imply that any/all
combinations produced correct output, just that it was the same
before/after).
Beside the design flaws, the patch shows a couple of problems wich needs
to be addressed first:
static unsigned MotionVFSToPipe(int xvmc_mo_vfs)
{
...
assert(pipe_mo_vfs != 0);
return pipe_mo_vfs;
}
The motion_vertical_field_select bitfield is part of the mpeg2 spec (see
section 6.3.17.2). We should stick our definitions to the spec as most
as possible and don't try to define our own, since XvMC is also using
this field as defined in the spec it can simple be copied over.
And by the way, it is completely valid for this field to be 0.
static enum pipe_mpeg12_macroblock_type TypeToPipe(int xvmc_mb_type)
{
if (xvmc_mb_type XVMC_MB_TYPE_INTRA)
return PIPE_MPEG12_MACROBLOCK_TYPE_INTRA;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == XVMC_MB_TYPE_MOTION_FORWARD)
return PIPE_MPEG12_MACROBLOCK_TYPE_FORWARD;
/* Workaround for Xine's xxmc video out plugin */
if (!(xvmc_mb_type ~XVMC_MB_TYPE_PATTERN))
return PIPE_MPEG12_MACROBLOCK_TYPE_FORWARD;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == XVMC_MB_TYPE_MOTION_BACKWARD)
return PIPE_MPEG12_MACROBLOCK_TYPE_BACKWARD;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD))
return PIPE_MPEG12_MACROBLOCK_TYPE_BI;
assert(0);
XVMC_MSG(XVMC_ERR, [XvMC] Unrecognized mb type 0x%08X.\n, xvmc_mb_type);
return -1;
}
Same problem here, the macroblocktype is defined in section 6.3.17.1 of
the spec, and like XvMC it just defines forward, backward, pattern and
intra flags. Since XvMC is also following the spec here this field can
be copied over without a conversion. For a good reference see the
VAMacroblockParameterBufferMPEG2 structure in the vaapi specification.
static enum pipe_mpeg12_motion_type MotionToPipe(int xvmc_motion_type, int
xvmc_dct_type)
{
switch (xvmc_motion_type) {
case XVMC_PREDICTION_FRAME:
if (xvmc_dct_type == XVMC_DCT_TYPE_FIELD)
return PIPE_MPEG12_MOTION_TYPE_16x8;
else if (xvmc_dct_type == XVMC_DCT_TYPE_FRAME)
return PIPE_MPEG12_MOTION_TYPE_FRAME;
break;
case XVMC_PREDICTION_FIELD:
return PIPE_MPEG12_MOTION_TYPE_FIELD;
case XVMC_PREDICTION_DUAL_PRIME:
return PIPE_MPEG12_MOTION_TYPE_DUALPRIME;
default:
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
- Original Message - On Mon, Aug 08, 2011 at 01:01:14AM -0700, Corbin Simpson wrote: On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. This then is what S2TC is for. Distros could ALREADY take S2TC and include that, while most gamers wouldn't see a difference, while feeling safer from those patents (whether it is actually a successful evasion, only a judge can decide). Please stop this just because people can something it mean it is OK fallacy. That's what's ridiculous. Anybody can punch another in the face anytime, doesn't mean that a) he should; b) we should condemn or induce such practice. Without analogies, yes, people can do all sort of things with our software, but we developers should not condone, nor induce wrong/dubious practices. The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] hardware xvmc video decoding with nouveau
On 08/08/2011 12:10 PM, Christian König wrote:
Am Samstag, den 06.08.2011, 14:37 -0400 schrieb Younes Manton:
The attached patch I believe should satisfy everyone's needs here. It
removes the use of pipe_video_decode_buffer from the state tracker and
moves it to the shader decoder. This lets every decoder parse the
incoming macroblocks themselves so they can do whatever they need.
Beside the fact that this patch adds a couple of bugs, you are just
going back to a design wich has already proven to be a bit flaw full.
Please take a look at these two documents first:
http://msdn.microsoft.com/en-us/library/ff568441(v=VS.85).aspx
http://cgit.freedesktop.org/libva/tree/va/va.h
The problem I tried to solve with pipe_video_decode_buffer is that it is
valid for XvMC to do something like that:
XvMCRenderSurface(target A);
XvMCRenderSurface(target B);
XvMCRenderSurface(target A);
XvMCPutSurface(target A);
XvMCRenderSurface(target B);
XvMCPutSurface(target B);
That behaviour creates a bunch of problems when the decoder can only
work on whole frames, because you can't switch the decoding target while
inside a frame. This is an ugliness of the XvMC, which in the past made
it problematic to use it with a couple of hardware decoder.
Most modern players doesn't do it like this any more, but it still seems
to cause a bunch of problems when seeking or fast forward both with
mplayer and xine.
So I would suggest we design the interface something like this:
As far as I can tell, the hardware decoder I'm using has no problem with that.
I just queue all commands and on putsurface I flush them. In fact, with flushing
on putsurface it works better than other alternatives, since it can decode
future
and current surface simultaneously. Each command has to say which surface it's
being applied to. :)
1. We have a create_buffer call witch will return just a void pointer.
This makes it possible for decoders witch needs frame based decoding to
return an pointer to an internal frame decoding buffer, while it still
makes it possible for an decoder which is slice based to just return a
pointer to itself (for example) with this value not being used
otherwise.
2. We have a begin_frame/render/render.../end_frame calls just like
DXVA, to clearly distinct the start and end of a frame, for frame based
decoder this makes it possible to do clean housekeeping of the internal
buffer, while with slice level decoder begin_frame and end_frame are
just noops.
3. We pass the render target and the buffer to begin/render/end.
This enables slice level decoder to start their decoding earlier, while
it still keeps the burden of figuring out where a frame start/ends to
the XvMC state tracker.
The nouveau hardware acceleration really doesn't need more than
the current patch by ymanton, and the XvMC api doesn't expose this
kind of information, so I don't really think it makes sense to add that.
Too big to inline, see attached. Tested on XvMC/VDPAU with softpipe
and an RV620 with a couple of videos (this doesn't imply that any/all
combinations produced correct output, just that it was the same
before/after).
Beside the design flaws, the patch shows a couple of problems wich needs
to be addressed first:
static unsigned MotionVFSToPipe(int xvmc_mo_vfs)
{
...
assert(pipe_mo_vfs != 0);
return pipe_mo_vfs;
}
The motion_vertical_field_select bitfield is part of the mpeg2 spec (see
section 6.3.17.2). We should stick our definitions to the spec as most
as possible and don't try to define our own, since XvMC is also using
this field as defined in the spec it can simple be copied over.
And by the way, it is completely valid for this field to be 0.
static enum pipe_mpeg12_macroblock_type TypeToPipe(int xvmc_mb_type)
{
if (xvmc_mb_type XVMC_MB_TYPE_INTRA)
return PIPE_MPEG12_MACROBLOCK_TYPE_INTRA;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == XVMC_MB_TYPE_MOTION_FORWARD)
return PIPE_MPEG12_MACROBLOCK_TYPE_FORWARD;
/* Workaround for Xine's xxmc video out plugin */
if (!(xvmc_mb_type ~XVMC_MB_TYPE_PATTERN))
return PIPE_MPEG12_MACROBLOCK_TYPE_FORWARD;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == XVMC_MB_TYPE_MOTION_BACKWARD)
return PIPE_MPEG12_MACROBLOCK_TYPE_BACKWARD;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD))
return PIPE_MPEG12_MACROBLOCK_TYPE_BI;
assert(0);
XVMC_MSG(XVMC_ERR, [XvMC] Unrecognized mb type 0x%08X.\n, xvmc_mb_type);
return -1;
}
Same problem here, the macroblocktype is defined in section 6.3.17.1 of
the spec, and like XvMC it just defines forward, backward, pattern and
intra flags. Since XvMC is also following the spec here this field can
be copied over without a conversion. For a good reference see the
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] intel: GetBuffer fix
On 08/07/2011 11:51 PM, Ben Widawsky wrote: After copy buffer on preGEN6, it is necessary to wait for the blit to complete before returning data to the user. This fixes the piglit test: copy_buffer_coherency. Signed-off-by: Ben Widawsky b...@bwidawsk.net Reviewed-by: Kenneth Graunke kenn...@whitecape.org ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Starting work on var packer
I'll let the GLSL guys review the functionality of this, but a few
high-level comments:
1. What exactly is var packing? Do you mean storing 4 float vars in a
vector register? A better commit message is needed, plus some
comments at the top of the file explaining what's going on.
2. Core Mesa and the GLSL compiler uses 3-space indentation. I see a
mix of 4 and 8-space indentation in your code.
3. Please replace if(expr) with if (expr) and similarly for for-loops.
4. Change this:
if(expr) break;
to read:
if (expr)
break;
In case someone is debugging and wants to put a breakpoint on the
break statement.
5. In switch statements where there's case fallthrough, it's good to
put a comment like /* fall-through */ to make it clear to the reader
that fall-through is intentional.
Thanks.
-Brian
On 08/07/2011 01:49 PM, Vincent Lejeune wrote:
From: vljv...@ovi.com
---
src/glsl/Makefile |1 +
src/glsl/glsl_parser_extras.cpp |7 +-
src/glsl/ir_optimization.h |1 +
src/glsl/opt_var_packer.cpp | 332 +++
4 files changed, 338 insertions(+), 3 deletions(-)
create mode 100644 src/glsl/opt_var_packer.cpp
diff --git a/src/glsl/Makefile b/src/glsl/Makefile
index 68b98b2..226acc4 100644
--- a/src/glsl/Makefile
+++ b/src/glsl/Makefile
@@ -84,6 +84,7 @@ CXX_SOURCES = \
opt_swizzle_swizzle.cpp \
opt_tree_grafting.cpp \
opt_common_subexpression_elimination.cpp \
+ opt_var_packer.cpp \
s_expression.cpp
LIBS = \
diff --git a/src/glsl/glsl_parser_extras.cpp b/src/glsl/glsl_parser_extras.cpp
index 0a57386..1aa7d88 100644
--- a/src/glsl/glsl_parser_extras.cpp
+++ b/src/glsl/glsl_parser_extras.cpp
@@ -777,8 +777,9 @@ do_common_optimization(exec_list *ir, bool linked, unsigned
max_unroll_iteration
GLboolean progress = GL_FALSE;
- progress = do_common_subexpression_elimination(ir) || progress;
- /*progress = lower_instructions(ir, SUB_TO_ADD_NEG) || progress;
+ progress = do_var_packing (ir) || progress;
+ //progress = do_common_subexpression_elimination(ir) || progress;
+ progress = lower_instructions(ir, SUB_TO_ADD_NEG) || progress;
if (linked) {
progress = do_function_inlining(ir) || progress;
@@ -815,7 +816,7 @@ do_common_optimization(exec_list *ir, bool linked, unsigned
max_unroll_iteration
progress = set_loop_controls(ir, ls) || progress;
progress = unroll_loops(ir, ls, max_unroll_iterations) || progress;
}
- delete ls;*/
+ delete ls;
return progress;
}
diff --git a/src/glsl/ir_optimization.h b/src/glsl/ir_optimization.h
index 3604e4e..5b1de66 100644
--- a/src/glsl/ir_optimization.h
+++ b/src/glsl/ir_optimization.h
@@ -72,3 +72,4 @@ bool lower_variable_index_to_cond_assign(exec_list
*instructions,
bool lower_quadop_vector(exec_list *instructions, bool dont_lower_swz);
bool optimize_redundant_jumps(exec_list *instructions);
bool do_common_subexpression_elimination(exec_list *instructions);
+bool do_var_packing(exec_list *instructions);
diff --git a/src/glsl/opt_var_packer.cpp b/src/glsl/opt_var_packer.cpp
new file mode 100644
index 000..fe579f9
--- /dev/null
+++ b/src/glsl/opt_var_packer.cpp
@@ -0,0 +1,332 @@
+/*
+ * Copyright © 2011 Vincent Lejeune
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the Software),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include ir.h
+#include ir_hierarchical_visitor.h
+#include ir_rvalue_visitor.h
+#includecstring
+
+class box : public exec_node
+{
+public:
+void* content;
+box(void* c):content(c)
+{
+
+}
+};
+
+
+
+class boxed_exec_list : public exec_list
+{
+public:
+void push_tail(void *n)
+{
+box* b = new (this) box(n);
+exec_list::push_tail(b);
+}
+
+void push_head(void *n)
+{
+box* b = new (this) box(n);
+
Re: [Mesa-dev] (no subject)
On 08/07/2011 01:49 PM, Vincent Lejeune wrote: This new patch fix an issue with some shader (mandelbrot demo) Are you referring to your var packing patch? Is the mandelbrot demo not working with a particular driver? Which one? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Removing GLw from the main Mesa repository
On 08/05/2011 06:21 PM, Kenneth Graunke wrote: On 08/05/2011 06:45 AM, Brian Paul wrote: On Thu, Aug 4, 2011 at 4:26 PM, Kenneth Graunkekenn...@whitecape.org wrote: Hey, I'd like to remove libGLw from the main Mesa repository. It never changes, and almost noone uses it...because GL and Motif is awesome, right? Since Debian still packages it, I pulled it into its own git repository, preserving history, and then autotooled it. You can get it here: git://people.freedesktop.org/~kwg/glw Sounds good to me. Please scan through the Mesa docs for any mention of libGLw and update/remove as needed. There should at least be a pointer to the new home of libGLw too. -Brian Thanks, Brian. I've done so in this branch: http://cgit.freedesktop.org/~kwg/mesa/log/?h=die-glw-die Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: inline st_prepare_fragment_program in st_translate_fragment_program
On 08/07/2011 01:21 PM, Bryan Cain wrote: This reverts an unnecessary part of commit 4683529048ee and fixes misrendering and an assertion failure in Cogs. Fixes freedesktop.org bug 39888. --- Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On 08/08/11 00:58, Egon Ashrafinia wrote: I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? Incorrect. There's also quite a few other countries which allow software patents directly, such as Japan, South Korea, Australia, etc. Even if you believe the oversimplified (and incorrect) view that the EU has no software patents, European courts have enforced patents such as the MP3 ones when built into a hardware device such as an MP3 player. If you want to ensure Mesa is never built into a phone, or included as part of a preinstalled Linux bundle on a laptop, doing the wrong thing with patents is a good way to accomplish that. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] hardware xvmc video decoding with nouveau
Am Montag, den 08.08.2011, 15:00 +0200 schrieb Maarten Lankhorst: On 08/08/2011 12:10 PM, Christian König wrote: Most modern players doesn't do it like this any more, but it still seems to cause a bunch of problems when seeking or fast forward both with mplayer and xine. So I would suggest we design the interface something like this: As far as I can tell, the hardware decoder I'm using has no problem with that. I just queue all commands and on putsurface I flush them. In fact, with flushing on putsurface it works better than other alternatives, since it can decode future and current surface simultaneously. Each command has to say which surface it's being applied to. :) Finally somebody who understands me :D The problem I'm facing here is that switching the surface a command is applied to is causing either a whole bunch of overhead for me (cache flushes) or is not possible at all because the hardware wants an command buffer always filled with a whole frame. The solution I've found is that I use a separate queue for each surface and flush each queue each time a surface is either used as a reference surface or with putsurface. On the down side that means to either: A) use a hashtable where I can find the buffer for a surface (which will slow things down a little bit) B) or implement my own video buffer with additionally to the video data holds a reference to the command buffer which should be used (also ugly, because with vdpau you just doesn't knows whether a video buffer is used with hardware decoding or software decoding, but maybe that is just another state tracker dependent thing that needs to be hidden from the driver) C) or (and that's the way I think we should follow) enables the state tracker to supply an additional hint to the decoder which command buffer should be used. As long as it is not problem for you to switch the surface on the fly you can just ignore the hint. 3. We pass the render target and the buffer to begin/render/end. This enables slice level decoder to start their decoding earlier, while it still keeps the burden of figuring out where a frame start/ends to the XvMC state tracker. The nouveau hardware acceleration really doesn't need more than the current patch by ymanton, and the XvMC api doesn't expose this kind of information, so I don't really think it makes sense to add that. Yeah that's what I'm talking about, the purpose of a state tracker is to hide all the interface details from the driver (and not the other way around), and since XvMC is the only interface which doesn't have a distinct begin/end frame call (compared to vdpau,vaapi and DXVA), and that it is needed by at least some implementations - it's the job of the state tracker to work around that. So do you have time to work on this a bit more or should I take a break from the h264 implementation and try to do it right this time? Since I think I now knew what you guys need it should be possible for me to change the interface to something everybody is happy with. I'm happy with the current api for nouveau for XvMC (minus bug above). Are you sure? Try what's happening when you just jump back and for in a video with mplayer. Assuming your command buffer is somehow limited in size you will soon get a buffer overrun, because what mplayer does is the following: XvMCRenderSurface(slice 0); XvMCRenderSurface(slice 1); XvMCRenderSurface(slice n); *oh crap the use has just jumped to another key frame* (There is no putsurface for the first set of slices) XvMCRenderSurface(slice 0); XvMCRenderSurface(slice 1); XvMCRenderSurface(slice n); XvMCPutSurface(...); To solve this I first tried to increase the command buffer size, but that's not only a waste memory it also doesn't really solves the problem, because nobody limits mplayer to just call XvMCRenderSurface over and over again. For vdpau, I wonder if it makes more sense to have each driver have its own library, for example vdpau_g3dvl.so and vdpau_nouveau.so, if/when it comes to adding nouveau acceleration. If you look at the vdpau wrapper, it's using dri2 to query for the driver name to use. This would allow setting the right binary to use for each driver. Hui? There should be already separate vdpau_*.so for each build target, at least the r600g driver is called libvdpau_r600.so and softpipe is called libvdpau_softpipe.so. If you add an vdpau-nouveau target you just need to set LIBBASENAME in the makefile. Regards, Christian. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] hardware xvmc video decoding with nouveau
2011/8/8 Christian König deathsim...@vodafone.de:
Am Samstag, den 06.08.2011, 14:37 -0400 schrieb Younes Manton:
The attached patch I believe should satisfy everyone's needs here. It
removes the use of pipe_video_decode_buffer from the state tracker and
moves it to the shader decoder. This lets every decoder parse the
incoming macroblocks themselves so they can do whatever they need.
Beside the fact that this patch adds a couple of bugs, you are just
going back to a design wich has already proven to be a bit flaw full.
Please take a look at these two documents first:
http://msdn.microsoft.com/en-us/library/ff568441(v=VS.85).aspx
http://cgit.freedesktop.org/libva/tree/va/va.h
The problem I tried to solve with pipe_video_decode_buffer is that it is
valid for XvMC to do something like that:
XvMCRenderSurface(target A);
XvMCRenderSurface(target B);
XvMCRenderSurface(target A);
XvMCPutSurface(target A);
XvMCRenderSurface(target B);
XvMCPutSurface(target B);
That behaviour creates a bunch of problems when the decoder can only
work on whole frames, because you can't switch the decoding target while
inside a frame. This is an ugliness of the XvMC, which in the past made
it problematic to use it with a couple of hardware decoder.
Most modern players doesn't do it like this any more, but it still seems
to cause a bunch of problems when seeking or fast forward both with
mplayer and xine.
So I would suggest we design the interface something like this:
Take a closer look at decode_macroblocks in vl_mpeg12_decoder. Having
the state tracker need to care about how much the decoder is buffering
is a bad idea. I don't see how this is going back to a flawed design,
it's doing almost exactly what is currently done, just not in the
state tracker.
1. We have a create_buffer call witch will return just a void pointer.
This makes it possible for decoders witch needs frame based decoding to
return an pointer to an internal frame decoding buffer, while it still
makes it possible for an decoder which is slice based to just return a
pointer to itself (for example) with this value not being used
otherwise.
That's not useful, the hardware decoder needs to parse the incoming
macroblocks for itself. It needs to know things like the CBP, motion
type, etc. Your current decode buffer design throws all that info
away. All I did here is pass the macroblocks on to the driver and let
it do the parsing. In the shader case it still dumps stuff to the
decode buffer.
2. We have a begin_frame/render/render.../end_frame calls just like
DXVA, to clearly distinct the start and end of a frame, for frame based
decoder this makes it possible to do clean housekeeping of the internal
buffer, while with slice level decoder begin_frame and end_frame are
just noops.
3. We pass the render target and the buffer to begin/render/end.
This enables slice level decoder to start their decoding earlier, while
it still keeps the burden of figuring out where a frame start/ends to
the XvMC state tracker.
Again, take a closer look at decode_macroblocks. This is still using
the decode buffer, it's still buffering an entire frame of data, it's
just doing it behind the interface rather than in the state tracker.
Too big to inline, see attached. Tested on XvMC/VDPAU with softpipe
and an RV620 with a couple of videos (this doesn't imply that any/all
combinations produced correct output, just that it was the same
before/after).
Beside the design flaws, the patch shows a couple of problems wich needs
to be addressed first:
static unsigned MotionVFSToPipe(int xvmc_mo_vfs)
{
...
assert(pipe_mo_vfs != 0);
return pipe_mo_vfs;
}
The motion_vertical_field_select bitfield is part of the mpeg2 spec (see
section 6.3.17.2). We should stick our definitions to the spec as most
as possible and don't try to define our own, since XvMC is also using
this field as defined in the spec it can simple be copied over.
And by the way, it is completely valid for this field to be 0.
Valid for it to be 0 in the case where field-based motion estimation
isn't used as far as I can tell. This never gets called for that case.
static enum pipe_mpeg12_macroblock_type TypeToPipe(int xvmc_mb_type)
{
if (xvmc_mb_type XVMC_MB_TYPE_INTRA)
return PIPE_MPEG12_MACROBLOCK_TYPE_INTRA;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == XVMC_MB_TYPE_MOTION_FORWARD)
return PIPE_MPEG12_MACROBLOCK_TYPE_FORWARD;
/* Workaround for Xine's xxmc video out plugin */
if (!(xvmc_mb_type ~XVMC_MB_TYPE_PATTERN))
return PIPE_MPEG12_MACROBLOCK_TYPE_FORWARD;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == XVMC_MB_TYPE_MOTION_BACKWARD)
return PIPE_MPEG12_MACROBLOCK_TYPE_BACKWARD;
if ((xvmc_mb_type (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD)) == (XVMC_MB_TYPE_MOTION_FORWARD |
XVMC_MB_TYPE_MOTION_BACKWARD))
[Mesa-dev] Fwd: S2TC - yet another attempt to solve the S3TC issue
2011/8/8 Jose Fonseca jfons...@vmware.com - Original Message - On Mon, Aug 08, 2011 at 01:01:14AM -0700, Corbin Simpson wrote: On Mon, Aug 8, 2011 at 12:58 AM, Egon Ashrafinia egon.mag...@googlemail.com wrote: As I said in IRC ~ 2 Weeks ago, it is very Important that we support S3TC! I mean, the main problem is that this is a Software Patent, correct? Always as I know, only in the United States of America, correct? If so, in my opinoin the solution is simple. Let's do it the same as we did with --texture-float! Dont build it by default but ad a option to build it. And then every Distribution can decide them self. An American Distribution will disable it and an european distribution will disable it. Why dont we do it like this? I mean this is not a global patent. Even if so, France wont accept it cause they dont have software patents. ( What a great State!!! :D ) Also, please keep in mind! Without this support, Linux/Gnu will _never_ and I realy mean _never_ a gaming Plattform. Not now and not in the future! Let's do some may critical risks to improve the 3D Power of Gnu/Linux :D *You* do it then. We already support an external S3TC lib which can be built separately; go convince distros to pick it up. This then is what S2TC is for. Distros could ALREADY take S2TC and include that, while most gamers wouldn't see a difference, while feeling safer from those patents (whether it is actually a successful evasion, only a judge can decide). Please stop this just because people can something it mean it is OK fallacy. That's what's ridiculous. Anybody can punch another in the face anytime, doesn't mean that a) he should; b) we should condemn or induce such practice. Without analogies, yes, people can do all sort of things with our software, but we developers should not condone, nor induce wrong/dubious practices. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. Jose Calm down! No need to get insane becuase the thing I wrote! This was just an idea/opinion of my self. Not a command! Also the comment ( not by you ), which says I should do it my self is a bit ... wrong! I can create a patch. Yeah I could. But this will be wasted work when we dont discuss it here. I wont get promissions to add it without the ok of the whole mesa-dev list. As far as I can say. When we dont enable ST3C by default, there should be no restrictions with it. Every Distribution can decide them self if the like or dont like to enable it. I mean our whole work will be trash when this wont be included. I tested some games/applications/benchmarks without ST3C ... its unuseable. Everything is black and only the corners of Textures are visable. This cant be! I dont want to command someone in here! Also please keep in mind that this is just a idea/opinion by me personaly. You really dont have to do this that way. =) Greetings Egon Ashrafinia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] hardware xvmc video decoding with nouveau
2011/8/8 Christian König deathsim...@vodafone.de: Am Montag, den 08.08.2011, 15:00 +0200 schrieb Maarten Lankhorst: On 08/08/2011 12:10 PM, Christian König wrote: Most modern players doesn't do it like this any more, but it still seems to cause a bunch of problems when seeking or fast forward both with mplayer and xine. So I would suggest we design the interface something like this: As far as I can tell, the hardware decoder I'm using has no problem with that. I just queue all commands and on putsurface I flush them. In fact, with flushing on putsurface it works better than other alternatives, since it can decode future and current surface simultaneously. Each command has to say which surface it's being applied to. :) Finally somebody who understands me :D The problem I'm facing here is that switching the surface a command is applied to is causing either a whole bunch of overhead for me (cache flushes) or is not possible at all because the hardware wants an command buffer always filled with a whole frame. The solution I've found is that I use a separate queue for each surface and flush each queue each time a surface is either used as a reference surface or with putsurface. On the down side that means to either: A) use a hashtable where I can find the buffer for a surface (which will slow things down a little bit) B) or implement my own video buffer with additionally to the video data holds a reference to the command buffer which should be used (also ugly, because with vdpau you just doesn't knows whether a video buffer is used with hardware decoding or software decoding, but maybe that is just another state tracker dependent thing that needs to be hidden from the driver) This is actually not an ugly idea and makes the most sense. If you need every surface to have it's own separate decode buffer for XvMC you do that. If you need to implement decode buffers in the decoder for VDPAU you do that also. Again, take a closer look at the patch I sent. The problem of what to do with VDPAU's context-free surface creation when it comes to which decoder is being used is completely separate from this. Any driver that wants to support both shader-based decoding and hardware decoding at runtime should use a delayed allocation pattern similar to what the failover driver did for HW/softpipe mixing, that is don't create the actual buffer until the decoder sees it and at that point create the right buffer. This means of course that a buffer allocation failure would fail later than it would under a regular VDPAU driver, but the VDPAU API wasn't designed with runtime switching of decoders in mind so I'm fine with that personally. C) or (and that's the way I think we should follow) enables the state tracker to supply an additional hint to the decoder which command buffer should be used. As long as it is not problem for you to switch the surface on the fly you can just ignore the hint. 3. We pass the render target and the buffer to begin/render/end. This enables slice level decoder to start their decoding earlier, while it still keeps the burden of figuring out where a frame start/ends to the XvMC state tracker. The nouveau hardware acceleration really doesn't need more than the current patch by ymanton, and the XvMC api doesn't expose this kind of information, so I don't really think it makes sense to add that. Yeah that's what I'm talking about, the purpose of a state tracker is to hide all the interface details from the driver (and not the other way around), and since XvMC is the only interface which doesn't have a distinct begin/end frame call (compared to vdpau,vaapi and DXVA), and that it is needed by at least some implementations - it's the job of the state tracker to work around that. So do you have time to work on this a bit more or should I take a break from the h264 implementation and try to do it right this time? Since I think I now knew what you guys need it should be possible for me to change the interface to something everybody is happy with. I'm happy with the current api for nouveau for XvMC (minus bug above). Are you sure? Try what's happening when you just jump back and for in a video with mplayer. Assuming your command buffer is somehow limited in size you will soon get a buffer overrun, because what mplayer does is the following: XvMCRenderSurface(slice 0); XvMCRenderSurface(slice 1); XvMCRenderSurface(slice n); *oh crap the use has just jumped to another key frame* (There is no putsurface for the first set of slices) XvMCRenderSurface(slice 0); XvMCRenderSurface(slice 1); XvMCRenderSurface(slice n); XvMCPutSurface(...); To solve this I first tried to increase the command buffer size, but that's not only a waste memory it also doesn't really solves the problem, because nobody limits mplayer to just call XvMCRenderSurface over and over again. The hardware decoder doesn't have any problem with
Re: [Mesa-dev] [PATCH 2/2] glsl: When linking, emit functions at the tail of the final linked program.
On 5 August 2011 18:29, Kenneth Graunke kenn...@whitecape.org wrote: On 08/03/2011 05:07 PM, Paul Berry wrote: When link_functions.cpp adds a new function to the final linked program, it needs to add it after any global variable declarations that the function refers to, otherwise the IR will be invalid (because variable declarations must occur before variable accesses). The easiest way to do that is to have the linker emit functions to the tail of the final linked program. The linker used to emit functions to the head of the final linked program, in an effort to keep callees sorted before their callers. However, this was not reliable: it didn't work for functions declared or defined in the same compilation unit as main, for diamond-shaped patterns in the call graph, or for some obscure cases involving overloaded functions. And no code currently relies on this sort order. No Piglit regressions with i965 Ironlake. Seems reasonable. Reviewed-by: Kenneth Graunke kenn...@whitecape.org That said, I still dislike all this nonsense. I've really wanted to separate these, so a shader contains three separate lists: 1. A list of global variable declarations (ir_variable *) 2. A list of function declarations (ir_function *) 3. Global initializer instructions (ir_instruction *) Then you wouldn't have any of this crap about emitting functions before variable declarations, functions in functions, etc, etc. Plus you wouldn't need to dynamically check whether things in your top-level list are variables/functions/etc. Quite some time ago I took a stab at this, but wasn't thinking about global initializers, so I made no provisions for them and ended up tossing the code. It'd be nice to resurrect the idea. If you'd like to try, feel free... :) That's a really good idea. I'm not sure I have the time to pour into this right now, but I'll keep it in mind if I have to visit this code again. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On 08/07/2011 02:25 AM, Jose Fonseca wrote: - Original Message - On Sat, Aug 6, 2011 at 5:07 AM, Chad Versace c...@chad-versace.us wrote: On 08/05/2011 05:41 AM, Dan Nicholson wrote: I haven't seen any Android.mk files show up in freetype or expat or anything like that. In the same way, mesa doesn't carry a debian folder even though that's how debian and ubuntu build mesa. Certainly if there are fixes to the existing build infrastructure that help get mesa built on android, that should be done, but I don't see why we should carry the android build bits in upstream mesa. -- Dan Dan, you make a strong point. There's no sense in cluttering Mesa with additional makefiles, at least not now. Other projects do not do that for Android, and Mesa doesn't even do it for beloved Debian. The best approach would be to maintain the Android makefiles in a separate branch, perhaps even in a personal repo. I do not have a strong motivation to upstream Android support because - it requires changes to Android framework - it introduces yet another build system to Mesa I said this a few months back on mesa-user or -dev when asked. But generally, I think the not cluttering Mesa with another build system is debatable. I know I conflict with myself here, but if someone ports Mesa to arguably the most widely used OS and would like to upstream it, should we shut it down because the OS _requires_ its own build system? Incidentally, gstreamer has Android.mk upstream. Personally, I wouldn't object having the Android.mk on master branch. IMO code should be useful, above being beautiful and clean. As long it is maintained, serves a purpose, and does not impair the current stuff, then it's fine by me FWIW. Jose Having considered this more, I see two large benefits from having the Android.mk's on the master branch. 1) It would relieve Android Mesa maintainers (including me) from the need to periodically rebase the Android branch atop master. 2) More importantly, it would enable anyone working on Android Mesa to simply pull from master and to be able to build and test with all the latest bits. I think (2) is a strong point for keeping the Android.mk's on master. Since the Android port will now be undergoing active development, I believe the inability to simply pull from master and then build and test with the latest bits is a significant, and unnecessary, hindrance to Android GL development. Since Jose is ok with presence of the Android.mk's and no one has posted any vehement objections, I will begin moving forward with this. (This patch series is annoyingly long, and some patches have bugs, so, as time permits, I will repost the series as several smaller, more digestable series of 3 to 4 patches each. I'm at SIGGRAPH this week, so expect the emails to be intermittent.) -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39941] New: [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 Summary: [regression] glsl-to-tgsi broke rendering in Fallout 3 Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Mesa core AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: s...@whiz.se Created an attachment (id=50039) -- (https://bugs.freedesktop.org/attachment.cgi?id=50039) broken rendering The glsl-to-tgsi merge broke rendering in the game Fallout 3 (running in Wine), I confirmed this by reverting the merge. Before/after screenshots are attached, but I'm not sure what environment variables I need to set to dump the shaders? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 39941] [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 --- Comment #1 from Sven Arvidsson s...@whiz.se 2011-08-08 12:47:14 PDT --- Created an attachment (id=50040) -- (https://bugs.freedesktop.org/attachment.cgi?id=50040) normal rendering -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] S2TC - yet another attempt to solve the S3TC issue
Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 6:12 AM, Rudolf Polzer divver...@xonotic.org wrote: On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ 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] S2TC - yet another attempt to solve the S3TC issue
It is not transparent if applications must opt into using it. Please go ask distributions to pick this up; we aren't going to do it without the legal issues being cleared up. Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 6:12 AM, Rudolf Polzer divver...@xonotic.org wrote: On Mon, Aug 08, 2011 at 05:49:09AM -0700, Jose Fonseca wrote: - Original Message - The suggestion however is to include a S2TC-like method with Mesa, to basically make sure that in the long run NO distro has no support for S3TC uploading, without requiring an extra decision in each distro. I wouldn't oppose bundling S2TC for software renderers, but enabling S3TC decompression on hardware is an orthogonal matter, which depends on the licensing terms between the IHV and S3. If you wanna fix this, convince IHVs to fully license the S3TC use in their hardware for Linux. So far the only IHV that _seems_ to have such wide cross-OS license is NVIDIA. I think it would be good to add a FAQ about this in the docs. But I'm done with this stupid thread. I'll enjoy my vacation and stop wasting time with this nonsense. In other words: you want the EXISTING support in Mesa to upload S3TC compressed textures (pre-compressed, not runtime compressed) to the hardware removed. It is the driconf option Enable S3TC texture compression even if software support is not available (force_s3tc_enable in the configuration file or environment). There is already existing games that use this method to silently enable precompressed texture even when no libtxc_dxtn library is available: http://trac.wildfiregames.com/ticket/575 So effectively, Mesa already does this. If you were right with your opinion, this would mean Mesa is ALREADY violating the patent, because any game can set that environment variable and thus TRANSPARENTLY use S3TC, without the user being aware that the patented technology is being used. And then I would ask how it is any MORE illegal if a distro bundles the S2TC lib, and thus S3TC upload is available WITHOUT setting force_s3tc_enable. Summarizing: in the EXISTING code, it's already possible for any application to enable S3TC decompression. Just enable force_s3tc_enable before initializing OpenGL. So it is available, just by a different API than the one in the OpenGL extension spec (due to an extra putenv() call being required). Including S2TC, and thus enabling compressed texture upload by default, only changes the API by which this functionality is enabled to the standard OpenGL one (without the putenv() call). Best regards, Rudolf Polzer ___ 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] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 12:52:14PM -0700, Corbin Simpson wrote: [force_s3tc_enable] It is not transparent if applications must opt into using it. Applications must also opt into using the regular S3TC extension, by using the appropriate texture format constant. No difference there, just a different way of doing it. Please go ask distributions to pick this up; we aren't going to do it without the legal issues being cleared up. All I'd be asking for is a link to it as an alternate implementation of libtxc_dxtn on http://dri.freedesktop.org/wiki/S3TC (immutable page). Possibly with a text like An alternate implementation using a restricted format subset of S3TC to possibly evade the aforementioned patent problems is available on https://github.com/divVerent/s2tc/ - however, even though it is plausible, Mesa or DRI give no guarantee that using this does not violate any less patent claims than the full implementation of libtxc_dxtn does, so please consult a lawyer if unsure. Without that, it'll be hard for me to get distros interested in it. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39941] [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 --- Comment #2 from Henri Verbeet hverb...@gmail.com 2011-08-08 13:20:33 PDT --- I've seen similar issues in a couple of other applications using Wine as well. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] S2TC - yet another attempt to solve the S3TC issue
Unless I missed something, we (the Mesa developers) do not endorse using S3TC at all, anywhere in the stack, as long as it is patented. Have you actually talked to any distros? This is my last post; we aren't getting anywhere. Sending from a mobile, pardon my terseness. ~ C. On Aug 8, 2011 1:02 PM, Rudolf Polzer divver...@xonotic.org wrote: ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 8, 2011 at 8:02 PM, Rudolf Polzer divver...@xonotic.org wrote: Without that, it'll be hard for me to get distros interested in it. I'll make sure it's available in Gentoo very soon. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 39941] [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 --- Comment #3 from Bryan Cain bryancain3+...@gmail.com 2011-08-08 14:25:45 PDT --- Can you check out the glsl-to-tgsi branch and bisect it there? That will give me a better idea of what's causing the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 39941] [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 --- Comment #4 from Bryan Cain bryancain3+...@gmail.com 2011-08-08 14:40:05 PDT --- Also, if you're using r600g, you can dump the TGSI output with the environment variable R600_DUMP_SHADERS=1. Regardless of the driver, you can also dump the GLSL IR output by setting MESA_GLSL=dump. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 39941] [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 --- Comment #5 from Sven Arvidsson s...@whiz.se 2011-08-08 14:56:42 PDT --- Created an attachment (id=50042) -- (https://bugs.freedesktop.org/attachment.cgi?id=50042) TGSI output from broken rendering (In reply to comment #4) Also, if you're using r600g, you can dump the TGSI output with the environment variable R600_DUMP_SHADERS=1. Regardless of the driver, you can also dump the GLSL IR output by setting MESA_GLSL=dump. Thanks! I'm attaching before/after output from a R600_DUMP_SHADERS=1 run, will try bisecting tomorrow. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 39941] [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 --- Comment #6 from Sven Arvidsson s...@whiz.se 2011-08-08 14:57:29 PDT --- Created an attachment (id=50043) -- (https://bugs.freedesktop.org/attachment.cgi?id=50043) TGSI output from normal rendering -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] Re : (no subject)
Thank for the review ! I was referring to my previous var packing patch. Previous patch made GLSL optimisation entering an infinite loop (it added a variable, then dead_code_elimination removed it sometimes because not all occurences of the packed variables were replaced.) I made some change, I should resend a new patch according to your recommandation tomorrow. Vincent - Mail original - De : Brian Paul bri...@vmware.com À : Vincent Lejeune v...@ovi.com Cc : mesa-dev@lists.freedesktop.org Envoyé le : Lundi 8 Août 2011 16h40 Objet : Re: [Mesa-dev] (no subject) On 08/07/2011 01:49 PM, Vincent Lejeune wrote: This new patch fix an issue with some shader (mandelbrot demo) Are you referring to your var packing patch? Is the mandelbrot demo not working with a particular driver? Which one? -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g winsys backend rework
On Sun, Aug 7, 2011 at 5:25 PM, Marek Olšák mar...@gmail.com wrote: Hi, I have been recently trying to get thread offloading of the CS ioctl into r600g in order to reduce the impact of kernel overhead on fps. That, unfortunately, requires whole winsys/radeon to be used, because even the buffer management (bo_map, bo_wait, bo_busy) must take into account that a CS ioctl may be in progress. Besides that, there are several possible race conditions in r600g, so instead of rewriting r600g and trying to do what winsys/radeon is doing, I decided to simply use winsys/radeon. What's new in r600g: - Thread offloading of the DRM CS ioctl. I expect 0-15% increase in performance from that in CPU-bound apps. - The new GEM_WAIT ioctl is used to avoid waiting for a buffer when possible. (e.g. Mesa may map an index buffer to compute index bounds, which shouldn't cause unnecessary waiting now) I have sent the DRM patches which add the ioctl to dri-devel. - Thread-safety: There are several possible races in r600g. I especially don't like radeon_bo::reloc, which may cause pretty ugly races if a resource is shared and relocated in multiple contexts. winsys/radeon doesn't have that race and also fixes a couple more. Hopefully this thread-safeness won't cause performance regressions. winsys/radeon can do space checking as well, but we don't use that in r600g yet. Performance improvements - I have been able to find a difference with these apps: Unigine Heaven Before: 7.3 fps After: 7.6 fps Torcs Before: 29 fps After: 34 fps Note that every commit in the r600winsys2 branch has been committed without piglit regressions, so that we can bisect through it if needed. The net loss is a little over 900 lines of code in r600g. The fenced cache buffer manager in r600g has turned out not to be superior to pb_cache_bufmgr with the is_buffer_busy hook set, so I removed the former too, as the latter is way simpler. This new work has been pushed into a new branch r600winsys2 in the main Mesa repository, please review/test. Looks good. I'll try and run some tests on various hw later this week. Reviewed-by: Alex Deucher alexander.deuc...@amd.com Marek ___ 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 39941] [regression] glsl-to-tgsi broke rendering in Fallout 3
https://bugs.freedesktop.org/show_bug.cgi?id=39941 --- Comment #7 from Bryan Cain bryancain3+...@gmail.com 2011-08-08 17:26:28 PDT --- Thanks, although bisecting the regression in the glsl-to-tgsi branch will probably give more helpful results. Also, since I've never used R600_DUMP_TGSI before, I now see that in addition to the actual TGSI, it dumps the hardware shader, which is useless to me and clutters the output. So for doing TGSI dumps in the future, it would probably be best if you instead compiled st/mesa with the ST_DEBUG define (in st_debug.h) set to DEBUG_TGSI. That should dump only the TGSI. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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 39588] [bisected] mesa demo xeglgears draw nothing if surface type is a pixmap
https://bugs.freedesktop.org/show_bug.cgi?id=39588 --- Comment #7 from huihui.zh...@intel.com 2011-08-08 20:02:52 PDT --- (In reply to comment #6) Created an attachment (id=49902) View: https://bugs.freedesktop.org/attachment.cgi?id=49902 Review: https://bugs.freedesktop.org/review?bug=39588attachment=49902 intel: Set ctx's drawbuffer according to drawables visual Hi, I just try your patch. ./xeglgears -pixmap works fine but ./xeglgears -pixmap -fullscreen doesn't work The pixmap fullscreen mode doesn't work out on both the 7.9 and 7.11. Would you mind helping me looking into this issue. Thanks a lot. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- 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] S2TC - yet another attempt to solve the S3TC issue
On Mon, Aug 08, 2011 at 02:03:59PM -0700, Corbin Simpson wrote: Unless I missed something, we (the Mesa developers) do not endorse using S3TC at all, anywhere in the stack, as long as it is patented. Here, you reference the full S3TC implementation: http://dri.freedesktop.org/wiki/S3TC All I am asking for is ALSO a reference to the restricted S2TC implementation there. I'd do it myself, if the page were not immutable. Have you actually talked to any distros? I have no contact person to these, thus no influence. I am at the moment preparing a PKGBUILD for Arch Linux, but that is about all I can do without having contact to people at the distros who decide such things. Best regards, Rudolf Polzer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
