[Mesa-dev] [Bug 83445] eglSwapBuffers() crash on dri
https://bugs.freedesktop.org/show_bug.cgi?id=83445 kalyank kondapallykalyancontrib...@gmail.com changed: What|Removed |Added CC||kondapallykalyancontribute@ ||gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84566] Unify the format conversion code
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #5 from Iago Toral ito...@igalia.com ---
Jason, in your initial implementation of the master function you have this
assert:
if (src_array_format.as_uint dst_array_format.as_uint) {
assert(src_array_format.normalized == dst_array_format.normalized);
(...)
_mesa_swizzle_and_convert(dst, dst_gl_type, dst_array_format.num_channels,
src, src_gl_type, src_array_format.num_channels,
src2dst, normalized, width);
}
I think this assertion is wrong, since it prevents conversion from float array
types (which are being generated with normalized=false) to normalized integer
types. Something that is explicitly supported in _mesa_swizzle_and_convert. I
am hitting this assertion while converting from RGB FLOAT to RGBA UBYTE for
example.
Looking at the implementation of texstore_swizzle, which uses
_mesa_swizzle_and_convert (and is the path that the original code takes to do
this conversion in my example), I don't find this kind of checks. What it does
is this:
is_array = _mesa_format_to_array(dstFormat, dst_type, dst_components,
rgba2dst, normalized);
(...)
normalized |= !_mesa_is_enum_format_integer(srcFormat);
This will make it so that normalized is always set to true for float src
formats like RGB FLOAT.
So assuming that this code is correct I think we would want to do the same in
the master function: remove the assert and set normalized to true if either src
or dst are normalized or if src is a float type.
There is another issue, and that is how we decide if a (glformat,gldatatype)
combination is normalized or not when creating an array format from it. There
are a bunch of functions in glformats.c I could use, like:
GLboolean _mesa_is_enum_format_unorm(GLenum format)
GLboolean _mesa_is_enum_format_snorm(GLenum format)
GLboolean _mesa_is_enum_format_integer(GLenum format)
...
But these do not consider the data type, only the format, so for example
_mesa_is_enum_format_unorm(GL_RGB) will always return true, even if we have a
GL_FLOAT data type. This is the same thing that _mesa_swizzle_and_convert does
when doing:
normalized |= !_mesa_is_enum_format_integer(srcFormat);
but it is inconsistent with your definition of array formats, since all array
formats generated in format_info.c have a normalized setting of 0.
I could also avoid the problem if I simply use I just use
_mesa_is_enum_format_integer(format) when mapping a (glformat,gldatatype) to a
mesa_array_format, like texstore_swizzle does, but as I mentioned, that will
create float array formats with normalized set to true, which is inconsistent
with the array_formats you are generating, so I am not sure about the best path
to take here.
What do you think?
--
You are receiving this mail because:
You are the QA Contact for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/main: Fix unpack_R5G6B5_UNORM.
On 08.10.2014 13:36, Iago Toral wrote: Could not test with llvmpipe, for some reason, even when I am bulding with llvm and I see the llvmpipe sources being built Mesa insists in using the softpipe driver at runtime... If you're using an LLVM SVN snapshot, llvmpipe currently doesn't work with that until someone adapts the gallivm code for the removal of the JITMemoryManager class. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84566] Unify the format conversion code
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #6 from Jason Ekstrand ja...@jlekstrand.net ---
(In reply to Iago Toral from comment #5)
Jason, in your initial implementation of the master function you have this
assert:
if (src_array_format.as_uint dst_array_format.as_uint) {
assert(src_array_format.normalized == dst_array_format.normalized);
(...)
_mesa_swizzle_and_convert(dst, dst_gl_type, dst_array_format.num_channels,
src, src_gl_type, src_array_format.num_channels,
src2dst, normalized, width);
}
I think this assertion is wrong, since it prevents conversion from float
array types (which are being generated with normalized=false) to normalized
integer types. Something that is explicitly supported in
_mesa_swizzle_and_convert. I am hitting this assertion while converting from
RGB FLOAT to RGBA UBYTE for example.
Looking at the implementation of texstore_swizzle, which uses
_mesa_swizzle_and_convert (and is the path that the original code takes to
do this conversion in my example), I don't find this kind of checks. What it
does is this:
is_array = _mesa_format_to_array(dstFormat, dst_type, dst_components,
rgba2dst, normalized);
(...)
normalized |= !_mesa_is_enum_format_integer(srcFormat);
This will make it so that normalized is always set to true for float src
formats like RGB FLOAT.
So assuming that this code is correct I think we would want to do the same
in the master function: remove the assert and set normalized to true if
either src or dst are normalized or if src is a float type.
Yes, I believe that is correct. While I implemented the master function, it
didn't get much testing. I'ts mostly just a prototype, so bugs like that
aren't surprising.
There is another issue, and that is how we decide if a (glformat,gldatatype)
combination is normalized or not when creating an array format from it.
There are a bunch of functions in glformats.c I could use, like:
GLboolean _mesa_is_enum_format_unorm(GLenum format)
GLboolean _mesa_is_enum_format_snorm(GLenum format)
GLboolean _mesa_is_enum_format_integer(GLenum format)
...
But these do not consider the data type, only the format, so for example
_mesa_is_enum_format_unorm(GL_RGB) will always return true, even if we have
a GL_FLOAT data type. This is the same thing that _mesa_swizzle_and_convert
does when doing:
normalized |= !_mesa_is_enum_format_integer(srcFormat);
This should be correct. The way you detect things on the GL side is usually
that the GL_RGBA type formats are normalized while the GL_RGBA_INTEGER type
formats are not.
The only issue here is when you should clamp floating-point. What we probably
want is a boolean clamp parameter that indicates that the input should be
clamped to [0, 1] before converting. Whether a float-float conversion should
be clampped depends on where the conversion is being done.
but it is inconsistent with your definition of array formats, since all
array formats generated in format_info.c have a normalized setting of 0.
The generation is quite possibly wrong there. Again, the branches I pushed
were very thrown together and not a full, tested, implementation.
I could also avoid the problem if I simply use I just use
_mesa_is_enum_format_integer(format) when mapping a (glformat,gldatatype) to
a mesa_array_format, like texstore_swizzle does, but as I mentioned, that
will create float array formats with normalized set to true, which is
inconsistent with the array_formats you are generating, so I am not sure
about the best path to take here.
I think that's perfectly reasonable if we fix the generation format_info code.
--
You are receiving this mail because:
You are the QA Contact for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] i965: Fix register write checks.
When mapping the buffer a second time, we need to use the new pointer, not the one from the previous mapping. Otherwise, we will most likely crash. Apparently, we've just been getting lucky and getting the same bo-virtual pointer in both cases. libdrm probably has a hand in that. Signed-off-by: Kenneth Graunke kenn...@whitecape.org Cc: mesa-sta...@lists.freedesktop.org --- src/mesa/drivers/dri/i965/intel_extensions.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/mesa/drivers/dri/i965/intel_extensions.c b/src/mesa/drivers/dri/i965/intel_extensions.c index b04bd8f..76f 100644 --- a/src/mesa/drivers/dri/i965/intel_extensions.c +++ b/src/mesa/drivers/dri/i965/intel_extensions.c @@ -87,6 +87,7 @@ can_do_pipelined_register_writes(struct brw_context *brw) /* Check whether the value got written. */ drm_intel_bo_map(brw-batch.workaround_bo, false); + data = brw-batch.workaround_bo-virtual; bool success = data[offset] == expected_value; drm_intel_bo_unmap(brw-batch.workaround_bo); @@ -145,6 +146,7 @@ can_write_oacontrol(struct brw_context *brw) /* Check whether the value got written. */ drm_intel_bo_map(brw-batch.workaround_bo, false); + data = brw-batch.workaround_bo-virtual; bool success = data[offset] == expected_value; drm_intel_bo_unmap(brw-batch.workaround_bo); -- 2.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Make _mesa_print_arrays use stderr.
These days, most driver debug output happens via stderr, not stdout.
Some applications (such as Xephyr) also appear to close stdout which
makes these messages go nowhere.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/varray.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 09bf52c..96c2b26 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -1907,10 +1907,10 @@ static void
print_array(const char *name, GLint index, const struct gl_client_array *array)
{
if (index = 0)
- printf( %s[%d]: , name, index);
+ fprintf(stderr, %s[%d]: , name, index);
else
- printf( %s: , name);
- printf(Ptr=%p, Type=0x%x, Size=%d, ElemSize=%u, Stride=%d, Buffer=%u(Size
%lu)\n,
+ fprintf(stderr, %s: , name);
+ fprintf(stderr, Ptr=%p, Type=0x%x, Size=%d, ElemSize=%u, Stride=%d,
Buffer=%u(Size %lu)\n,
array-Ptr, array-Type, array-Size,
array-_ElementSize, array-StrideB,
array-BufferObj-Name, (unsigned long) array-BufferObj-Size);
--
2.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84566] Unify the format conversion code
https://bugs.freedesktop.org/show_bug.cgi?id=84566
--- Comment #7 from Iago Toral ito...@igalia.com ---
(In reply to Jason Ekstrand from comment #6)
(In reply to Iago Toral from comment #5)
Jason, in your initial implementation of the master function you have this
assert:
if (src_array_format.as_uint dst_array_format.as_uint) {
assert(src_array_format.normalized == dst_array_format.normalized);
(...)
_mesa_swizzle_and_convert(dst, dst_gl_type,
dst_array_format.num_channels,
src, src_gl_type,
src_array_format.num_channels,
src2dst, normalized, width);
}
I think this assertion is wrong, since it prevents conversion from float
array types (which are being generated with normalized=false) to normalized
integer types. Something that is explicitly supported in
_mesa_swizzle_and_convert. I am hitting this assertion while converting from
RGB FLOAT to RGBA UBYTE for example.
Looking at the implementation of texstore_swizzle, which uses
_mesa_swizzle_and_convert (and is the path that the original code takes to
do this conversion in my example), I don't find this kind of checks. What it
does is this:
is_array = _mesa_format_to_array(dstFormat, dst_type, dst_components,
rgba2dst, normalized);
(...)
normalized |= !_mesa_is_enum_format_integer(srcFormat);
This will make it so that normalized is always set to true for float src
formats like RGB FLOAT.
So assuming that this code is correct I think we would want to do the same
in the master function: remove the assert and set normalized to true if
either src or dst are normalized or if src is a float type.
Yes, I believe that is correct. While I implemented the master function, it
didn't get much testing. I'ts mostly just a prototype, so bugs like that
aren't surprising.
Yeah, I know, but since I don't really have any previous experience with the
formats code I prefer to double check my conclusions with you just in case I am
missing something or messing up.
BTW, Thanks for the fast reply!
--
You are receiving this mail because:
You are the QA Contact for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Make _mesa_print_arrays use stderr.
On 10/08/2014 11:24 AM, Kenneth Graunke wrote:
These days, most driver debug output happens via stderr, not stdout.
Some applications (such as Xephyr) also appear to close stdout which
makes these messages go nowhere.
There's some more debug code using printf there (at least in uniform and
texture code), not sure if you want all of these to be changed (?)
Reviewed-by: Tapani Pälli tapani.pa...@intel.com
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/main/varray.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/mesa/main/varray.c b/src/mesa/main/varray.c
index 09bf52c..96c2b26 100644
--- a/src/mesa/main/varray.c
+++ b/src/mesa/main/varray.c
@@ -1907,10 +1907,10 @@ static void
print_array(const char *name, GLint index, const struct gl_client_array
*array)
{
if (index = 0)
- printf( %s[%d]: , name, index);
+ fprintf(stderr, %s[%d]: , name, index);
else
- printf( %s: , name);
- printf(Ptr=%p, Type=0x%x, Size=%d, ElemSize=%u, Stride=%d,
Buffer=%u(Size %lu)\n,
+ fprintf(stderr, %s: , name);
+ fprintf(stderr, Ptr=%p, Type=0x%x, Size=%d, ElemSize=%u, Stride=%d,
Buffer=%u(Size %lu)\n,
array-Ptr, array-Type, array-Size,
array-_ElementSize, array-StrideB,
array-BufferObj-Name, (unsigned long) array-BufferObj-Size);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Make _mesa_print_arrays use stderr.
On Wednesday, October 08, 2014 11:31:38 AM Tapani Pälli wrote: On 10/08/2014 11:24 AM, Kenneth Graunke wrote: These days, most driver debug output happens via stderr, not stdout. Some applications (such as Xephyr) also appear to close stdout which makes these messages go nowhere. There's some more debug code using printf there (at least in uniform and texture code), not sure if you want all of these to be changed (?) Reviewed-by: Tapani Pälli tapani.pa...@intel.com It's probably a good idea - I just changed the one function I wanted to use. 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 23/23] i965: Skip uploading border color when unnecessary.
On Tuesday, July 29, 2014 04:29:28 PM Kenneth Graunke wrote:
The border color is only needed when using the
GL_CLAMP_TO_BORDER or
(deprecated) GL_CLAMP wrap modes; all others ignore it, including
the
common GL_CLAMP_TO_EDGE and GL_REPEAT wrap modes.
In those cases, we can skip uploading it entirely, saving a bit of
space
in the batchbuffer. Instead, we just point it at the start of the
batch (offset 0); we have to program something, and that address is
safe
to read.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_sampler_state.c | 22
--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c
b/src/mesa/drivers/dri/i965/brw_sampler_state.c index
f48e3c9..ad9a527
100644
--- a/src/mesa/drivers/dri/i965/brw_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c
@@ -161,6 +161,16 @@ translate_wrap_mode(struct brw_context
*brw, GLenum
wrap, bool using_nearest) }
/**
+ * Return true if the given wrap mode requires the border color to
exist.
+ */
+static bool
+wrap_mode_needs_border_color(unsigned wrap_mode)
+{
+ return wrap_mode == BRW_TEXCOORDMODE_CLAMP_BORDER ||
+ wrap_mode == GEN8_TEXCOORDMODE_HALF_BORDER;
+}
+
+/**
* Upload SAMPLER_BORDER_COLOR_STATE.
*/
static void
@@ -410,8 +420,16 @@ brw_update_sampler_state(struct
brw_context *brw,
lod_bits);
base_level = U_FIXED(0, 1);
- uint32_t border_color_offset;
- upload_default_color(brw, sampler, unit, border_color_offset);
+ /* Upload the border color if necessary. If not, just point it at
+* offset 0 (the start of the batch) - the color should be ignored,
+* but that address won't fault in case something reads it anyway.
+*/
+ uint32_t border_color_offset = 0;
+ if (wrap_mode_needs_border_color(wrap_s) ||
+ wrap_mode_needs_border_color(wrap_t) ||
+ wrap_mode_needs_border_color(wrap_r)) {
+ upload_default_color(brw, sampler, unit, border_color_offset);
+ }
brw_emit_sampler_state(brw,
sampler_state,
I don't think I ever received any review on this patch (23/23). The rest
got pushed a long time ago.
Thoughts?
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Add support for compiling to native object code v2
Tom Stellard thomas.stell...@amd.com writes:
v2:
- Split build_module_native() into three separate functions.
- Code cleanups.
---
.../state_trackers/clover/llvm/invocation.cpp | 200
-
src/gallium/targets/opencl/Makefile.am | 1 +
2 files changed, 192 insertions(+), 9 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index 3b6b6a4..d9c3d11 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -45,12 +45,18 @@
#include llvm/Support/SourceMgr.h
#include llvm/IRReader/IRReader.h
#endif
+#if HAVE_LLVM 0x0305
+#include llvm/ADT/OwningPtr.h
+#endif
#include llvm/PassManager.h
+#include llvm/Support/CodeGen.h
#include llvm/Support/TargetSelect.h
#include llvm/Support/MemoryBuffer.h
#if HAVE_LLVM 0x0303
#include llvm/Support/PathV1.h
#endif
+#include llvm/Support/FormattedStream.h
+#include llvm/Support/TargetRegistry.h
#include llvm/Transforms/IPO.h
#include llvm/Transforms/IPO/PassManagerBuilder.h
@@ -61,6 +67,13 @@
#else
#include llvm/IR/DataLayout.h
#endif
+#include llvm/Target/TargetLibraryInfo.h
+#include llvm/Target/TargetMachine.h
+#include llvm/Target/TargetOptions.h
+
+#include llvm-c/Target.h
+#include llvm-c/TargetMachine.h
+#include llvm-c/Core.h
#include pipe/p_state.h
#include util/u_memory.h
@@ -71,6 +84,8 @@
#include fstream
#include cstdio
#include sstream
+#include libelf.h
+#include gelf.h
using namespace clover;
@@ -117,10 +132,11 @@ namespace {
#endif
llvm::Module *
- compile(llvm::LLVMContext llvm_ctx, const std::string source,
+ compile_llvm(llvm::LLVMContext llvm_ctx, const std::string source,
const std::string name, const std::string triple,
const std::string processor, const std::string opts,
- clang::LangAS::Map address_spaces, compat::string r_log) {
+ clang::LangAS::Map address_spaces, unsigned optimization_level,
+compat::string r_log) {
clang::CompilerInstance c;
clang::EmitLLVMOnlyAction act(llvm_ctx);
@@ -228,6 +244,8 @@ namespace {
// that is no executed by all threads) during its optimizaton passes.
c.getCodeGenOpts().LinkBitcodeFile = libclc_path;
+ optimization_level = c.getCodeGenOpts().OptimizationLevel;
+
// Compile the code
bool ExecSuccess = c.ExecuteAction(act);
r_log = log;
@@ -264,8 +282,8 @@ namespace {
}
void
- internalize_functions(llvm::Module *mod,
-const std::vectorllvm::Function * kernels) {
+ optimize(llvm::Module *mod, unsigned optimization_level,
+const std::vectorllvm::Function * kernels) {
llvm::PassManager PM;
// Add a function internalizer pass.
@@ -289,7 +307,14 @@ namespace {
llvm::Function *kernel = *I;
export_list.push_back(kernel-getName().data());
}
+ PM.add(new llvm::DataLayoutPass());
PM.add(llvm::createInternalizePass(export_list));
+
+ llvm::PassManagerBuilder PMB;
+ PMB.OptLevel = optimization_level;
+ PMB.LibraryInfo = new llvm::TargetLibraryInfo(
+llvm::Triple(mod-getTargetTriple()));
+ PMB.populateModulePassManager(PM);
PM.run(*mod);
}
@@ -404,6 +429,150 @@ namespace {
return m;
}
+
+ std::vectorchar
+ compile_native(const llvm::Module *mod, std::string triple,
+ std::string processor, compat::string r_log) {
+
triple and processor should be const references.
+ std::string log;
+ LLVMTargetRef target;
+ char *error_message;
+ LLVMMemoryBufferRef out_buffer;
+ unsigned buffer_size;
+ const char *buffer_data;
+ LLVMBool err;
+ LLVMModuleRef mod_ref = wrap(mod);
+
+ if (LLVMGetTargetFromTriple(triple.c_str(), target, error_message)) {
+ r_log = std::string(error_message);
+ LLVMDisposeMessage(error_message);
+ throw build_error();
+ }
+
+ LLVMTargetMachineRef tm = LLVMCreateTargetMachine(
+target, triple.c_str(), processor.c_str(), ,
+LLVMCodeGenLevelDefault, LLVMRelocDefault, LLVMCodeModelDefault);
+
+ if (!tm) {
+ r_log = Could not create TargetMachine: + triple;
+ throw build_error();
+ }
+
+ err = LLVMTargetMachineEmitToMemoryBuffer(tm, mod_ref, LLVMObjectFile,
+error_message, out_buffer);
+
+ if (err) {
+ LLVMDisposeTargetMachine(tm);
+ r_log = std::string(error_message);
+ LLVMDisposeMessage(error_message);
+ throw build_error();
+ }
+
+ buffer_size = LLVMGetBufferSize(out_buffer);
+ buffer_data = LLVMGetBufferStart(out_buffer);
+
+
Re: [Mesa-dev] [PATCH 23/23] i965: Skip uploading border color when unnecessary.
Seems reasonable to me. Always nice to save a bit more batchbuffer space.
Reviewed-by: Chris Forbes chr...@ijw.co.nz
On Wed, Oct 8, 2014 at 9:57 PM, Kenneth Graunke kenn...@whitecape.org wrote:
On Tuesday, July 29, 2014 04:29:28 PM Kenneth Graunke wrote:
The border color is only needed when using the
GL_CLAMP_TO_BORDER or
(deprecated) GL_CLAMP wrap modes; all others ignore it, including
the
common GL_CLAMP_TO_EDGE and GL_REPEAT wrap modes.
In those cases, we can skip uploading it entirely, saving a bit of
space
in the batchbuffer. Instead, we just point it at the start of the
batch (offset 0); we have to program something, and that address is
safe
to read.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_sampler_state.c | 22
--
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sampler_state.c
b/src/mesa/drivers/dri/i965/brw_sampler_state.c index
f48e3c9..ad9a527
100644
--- a/src/mesa/drivers/dri/i965/brw_sampler_state.c
+++ b/src/mesa/drivers/dri/i965/brw_sampler_state.c
@@ -161,6 +161,16 @@ translate_wrap_mode(struct brw_context
*brw, GLenum
wrap, bool using_nearest) }
/**
+ * Return true if the given wrap mode requires the border color to
exist.
+ */
+static bool
+wrap_mode_needs_border_color(unsigned wrap_mode)
+{
+ return wrap_mode == BRW_TEXCOORDMODE_CLAMP_BORDER ||
+ wrap_mode == GEN8_TEXCOORDMODE_HALF_BORDER;
+}
+
+/**
* Upload SAMPLER_BORDER_COLOR_STATE.
*/
static void
@@ -410,8 +420,16 @@ brw_update_sampler_state(struct
brw_context *brw,
lod_bits);
base_level = U_FIXED(0, 1);
- uint32_t border_color_offset;
- upload_default_color(brw, sampler, unit, border_color_offset);
+ /* Upload the border color if necessary. If not, just point it at
+* offset 0 (the start of the batch) - the color should be ignored,
+* but that address won't fault in case something reads it anyway.
+*/
+ uint32_t border_color_offset = 0;
+ if (wrap_mode_needs_border_color(wrap_s) ||
+ wrap_mode_needs_border_color(wrap_t) ||
+ wrap_mode_needs_border_color(wrap_r)) {
+ upload_default_color(brw, sampler, unit, border_color_offset);
+ }
brw_emit_sampler_state(brw,
sampler_state,
I don't think I ever received any review on this patch (23/23). The rest
got pushed a long time ago.
Thoughts?
--Ken
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 05/10] clover: Add environment variables for dumping kernel code
Tom Stellard thomas.stell...@amd.com writes:
---
.../state_trackers/clover/llvm/invocation.cpp | 74
++
1 file changed, 63 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index a1a54e0..3e6a186 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -61,6 +61,8 @@
#include llvm/Support/TargetRegistry.h
#include llvm/Transforms/IPO.h
#include llvm/Transforms/IPO/PassManagerBuilder.h
+#include llvm/Transforms/Utils/Cloning.h
+
#if HAVE_LLVM 0x0302
#include llvm/Target/TargetData.h
@@ -433,19 +435,39 @@ namespace {
return m;
}
+ static void emit_code(LLVMTargetMachineRef tm, LLVMModuleRef mod,
+ LLVMCodeGenFileType file_type,
+ LLVMMemoryBufferRef *out_buffer,
+ compat::string r_log) {
+ LLVMBool err;
+ char *err_message = NULL;
+
+ err = LLVMTargetMachineEmitToMemoryBuffer(tm, mod, file_type,
+err_message, out_buffer);
+
+ if (err) {
+ r_log = std::string(err_message);
+ }
+
+ LLVMDisposeMessage(err_message);
+
+ if (err) {
+ throw build_error();
+ }
+ }
+
module
build_module_native(llvm::Module *mod,
const std::vectorllvm::Function * kernels,
clang::LangAS::Map address_spaces,
std::string triple, std::string processor,
- compat::string r_log) {
+ bool dump_asm, compat::string r_log) {
std::string log;
LLVMTargetRef target;
char *error_message;
LLVMMemoryBufferRef out_buffer;
unsigned buffer_size;
const char *buffer_data;
- LLVMBool err;
LLVMModuleRef mod_ref = wrap(mod);
if (LLVMGetTargetFromTriple(triple.c_str(), target, error_message)) {
@@ -463,16 +485,27 @@ namespace {
throw build_error();
}
- err = LLVMTargetMachineEmitToMemoryBuffer(tm, mod_ref, LLVMObjectFile,
-error_message, out_buffer);
+ if (dump_asm) {
+ LLVMSetTargetMachineAsmVerbosity(tm, true);
+#if HAVE_LLVM = 0x0306
+ LLVMSetTargetMachineShowMCEncoding(tm, true);
+#endif
+ LLVMModuleRef debug_mod = wrap(llvm::CloneModule(mod));
+ emit_code(tm, debug_mod, LLVMAssemblyFile, out_buffer, r_log);
+ buffer_size = LLVMGetBufferSize(out_buffer);
+ buffer_data = LLVMGetBufferStart(out_buffer);
+ fprintf(stderr, %.*s\n, buffer_size, buffer_data);
We should try to avoid mixing iostream and stdio library calls. How about
using 'std::cerr ...' here?
- if (err) {
- LLVMDisposeTargetMachine(tm);
- r_log = std::string(error_message);
- LLVMDisposeMessage(error_message);
- throw build_error();
+ LLVMSetTargetMachineAsmVerbosity(tm, false);
+#if HAVE_LLVM = 0x0306
+ LLVMSetTargetMachineShowMCEncoding(tm, false);
+#endif
+ LLVMDisposeMemoryBuffer(out_buffer);
+ LLVMDisposeModule(debug_mod);
}
+ emit_code(tm, mod_ref, LLVMObjectFile, out_buffer, r_log);
+
buffer_size = LLVMGetBufferSize(out_buffer);
buffer_data = LLVMGetBufferStart(out_buffer);
@@ -569,6 +602,18 @@ static void diagnostic_handler(const
llvm::DiagnosticInfo di, void *err_string)
#endif
+#define DBG_CLC (1 0)
+#define DBG_LLVM (1 1)
+#define DBG_ASM (1 2)
+
+static const struct debug_named_value debug_options[] = {
+ {clc, DBG_CLC, Dump the OpenCL C code for all kernels.},
+ {llvm, DBG_LLVM, Dump the generated LLVM IR for all kernels.},
+ {asm, DBG_ASM, Dump kernel assembly code for targets specifying
+PIPE_SHADER_IR_NATIVE},
+ DEBUG_NAMED_VALUE_END // must be last
+};
+
module
clover::compile_program_llvm(const compat::string source,
enum pipe_shader_ir ir,
@@ -576,8 +621,9 @@ clover::compile_program_llvm(const compat::string source,
const compat::string opts,
compat::string r_log) {
+ static unsigned debug_flags = debug_get_flags_option(CLOVER_DEBUG,
+ debug_options, 0);
static bool target_init = false;
-
if (!target_init) {
LLVMInitializeAllTargets();
@@ -610,6 +656,12 @@ clover::compile_program_llvm(const compat::string
source,
optimize(mod, optimization_level, kernels);
+ if (debug_flags DBG_CLC)
+ std::cerr std::string(source);
+
+ if (debug_flags DBG_LLVM)
+ mod-dump();
+
module m;
// Build the
Re: [Mesa-dev] [PATCH 09/10] radeonsi/compute: Enable PIPE_SHADER_IR_NATIVE for compute shaders
There already is a function called si_shader_create. I don't think it
would be nice to add si_create_shader. Can we choose a better naming
here? (for both functions if needed)
Marek
On Mon, Oct 6, 2014 at 9:44 PM, Tom Stellard thomas.stell...@amd.com wrote:
---
src/gallium/drivers/radeonsi/si_compute.c | 51 +--
src/gallium/drivers/radeonsi/si_pipe.c| 2 +-
src/gallium/drivers/radeonsi/si_shader.c | 104
++
src/gallium/drivers/radeonsi/si_shader.h | 7 ++
4 files changed, 88 insertions(+), 76 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_compute.c
b/src/gallium/drivers/radeonsi/si_compute.c
index 490845b..a133380 100644
--- a/src/gallium/drivers/radeonsi/si_compute.c
+++ b/src/gallium/drivers/radeonsi/si_compute.c
@@ -23,14 +23,14 @@
*/
#include util/u_memory.h
+#include radeon/r600_pipe_common.h
+#include radeon/radeon_elf_util.h
#include radeon/r600_cs.h
#include si_pipe.h
#include si_shader.h
#include sid.h
-#include radeon/radeon_llvm_util.h
-
#define MAX_GLOBAL_BUFFERS 20
#define NUM_USER_SGPRS 4
@@ -40,14 +40,12 @@ struct si_compute {
unsigned local_size;
unsigned private_size;
unsigned input_size;
- unsigned num_kernels;
- struct si_shader *kernels;
+ struct radeon_shader_binary binary;
+ struct si_shader program;
unsigned num_user_sgprs;
struct r600_resource *input_buffer;
struct pipe_resource *global_buffers[MAX_GLOBAL_BUFFERS];
-
- LLVMContextRef llvm_ctx;
};
static void *si_create_compute_state(
@@ -57,10 +55,7 @@ static void *si_create_compute_state(
struct si_context *sctx = (struct si_context *)ctx;
struct si_compute *program = CALLOC_STRUCT(si_compute);
const struct pipe_llvm_program_header *header;
- const unsigned char *code;
- unsigned i;
-
- program-llvm_ctx = LLVMContextCreate();
+ const char *code;
header = cso-prog;
code = cso-prog + sizeof(struct pipe_llvm_program_header);
@@ -70,16 +65,9 @@ static void *si_create_compute_state(
program-private_size = cso-req_private_mem;
program-input_size = cso-req_input_mem;
- program-num_kernels = radeon_llvm_get_num_kernels(program-llvm_ctx,
code,
- header-num_bytes);
- program-kernels = CALLOC(sizeof(struct si_shader),
- program-num_kernels);
- for (i = 0; i program-num_kernels; i++) {
- LLVMModuleRef mod =
radeon_llvm_get_kernel_module(program-llvm_ctx, i,
- code,
header-num_bytes);
- si_compile_llvm(sctx-screen, program-kernels[i], mod);
- LLVMDisposeModule(mod);
- }
+ memset(program-binary, 0, sizeof(program-binary));
+ radeon_elf_read(code, header-num_bytes, program-binary, true);
+ si_create_shader(sctx-screen, program-program, program-binary);
program-input_buffer = si_resource_create_custom(sctx-b.b.screen,
PIPE_USAGE_IMMUTABLE, program-input_size);
@@ -177,7 +165,7 @@ static void si_launch_grid(
uint64_t shader_va;
unsigned arg_user_sgpr_count = NUM_USER_SGPRS;
unsigned i;
- struct si_shader *shader = program-kernels[pc];
+ struct si_shader *shader = program-program;
unsigned lds_blocks;
unsigned num_waves_for_scratch;
@@ -194,6 +182,9 @@ static void si_launch_grid(
pm4-compute_pkt = true;
+ /* Read the config informatio */
+ si_shader_binary_read_config(program-binary, program-program, pc);
+
/* Upload the kernel arguments */
/* The extra num_work_size_bytes are for work group / work item size
information */
@@ -285,7 +276,7 @@ static void si_launch_grid(
0x190 /* Default value */);
}
- shader_va = shader-bo-gpu_address;
+ shader_va = shader-bo-gpu_address + pc;
si_pm4_add_bo(pm4, shader-bo, RADEON_USAGE_READ,
RADEON_PRIO_SHADER_DATA);
si_pm4_set_reg(pm4, R_00B830_COMPUTE_PGM_LO, (shader_va 8)
0x);
si_pm4_set_reg(pm4, R_00B834_COMPUTE_PGM_HI, shader_va 40);
@@ -384,22 +375,12 @@ static void si_delete_compute_state(struct pipe_context
*ctx, void* state){
return;
}
- if (program-kernels) {
- for (int i = 0; i program-num_kernels; i++){
- if (program-kernels[i].bo){
- si_shader_destroy(ctx, program-kernels[i]);
- }
- }
- FREE(program-kernels);
- }
-
- if (program-llvm_ctx){
- LLVMContextDispose(program-llvm_ctx);
- }
[Mesa-dev] [Bug 54080] glXQueryDrawable fails with GLXBadDrawable for a Window in direct context
https://bugs.freedesktop.org/show_bug.cgi?id=54080 --- Comment #7 from Ian Romanick i...@freedesktop.org --- The server doesn't make the direct-rendering client current, so it gets angry when it tries to make it un-current. This is the reason we weren't sending it the MakeCurrent in the first place. There's probably some work that would need to be done in the server to make this work. -- 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] mesa/main: Fix unpack_R5G6B5_UNORM.
On 10/07/2014 11:11 PM, Jason Ekstrand wrote: On Oct 8, 2014 6:36 AM, Iago Toral ito...@igalia.com mailto:ito...@igalia.com wrote: El 2014-10-07 21:46, Jason Ekstrand escribió: On Oct 7, 2014 12:04 PM, Iago Toral Quiroga ito...@igalia.com mailto:ito...@igalia.com wrote: There is a comment warning about the fact that this is not doing what we expect, so fix it. This should be doing the same as unpack_B5G6R5_UNORM but swapping B and R. --- Jason started some work to auto-generate the format_pack.c and format_unpack.c files which I think has this fixed. I am continuing his work on this at the moment, but I guess it might make sense to fix this in the current code too while that work is on-going. Not much time to reply right now, but I seem to recall there being a bit more to fix here. What about packing and swrast's texel fetch implementation. Are those OK for this format? No piglit regressions observed. On what drivers? It might be good to test on swrast and llvmpipe. I'm not super-concerned there but we should at least try not to break it. --Jason That was on Intel, but you are right, at least classic swrast has some regressions with this. For reference, I did not see any regressions on Gallium Softpipe but I could only run a small subset of tests with this driver (-t texture -t color -t format) or otherwise it would hog my CPU and eventually crash my system. Could not test with llvmpipe, for some reason, even when I am bulding with llvm and I see the llvmpipe sources being built Mesa insists in using the softpipe driver at runtime... I can give you the configure flags for testing llvmpipe if you'd like. Yes, doing a full piglit run on llvmpipe or swrast requires a pretty beefy desktop and still takes quite a while. Since there are regressions on swrast at least I guess we should just drop this patch until we have a proper fix for all drivers. I'm not as worried about llvmpipe because it fails about half the tests it attempts anyway. I would like to know what's going on with swrast though. Brian, any ideas? --Jason Not of the top of my head. I'll be mostly off-line until next week... -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 11/13] gallium/docs: Highlighting opcodes
--- src/gallium/docs/source/tgsi.rst | 85 +++-- 1 files changed, 44 insertions(+), 41 deletions(-) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index f795c59..9bfefd8 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -939,7 +939,7 @@ XXX doesn't look like most of the opcodes really belong here. filtering operation and packs them into a single register. Only works with 2D, 2D array, cubemaps, and cubemaps arrays. For 2D textures, only the addressing modes of the sampler and the top level of any mip pyramid are - used. Set W to zero. It behaves like the TEX instruction, but a filtered + used. Set W to zero. It behaves like the :opcode:`TEX` instruction, but a filtered sample is not generated. The four samples that contribute to filtering are placed into xyzw in clockwise order, starting with the (u,v) texture coordinate delta at the following locations (-, +), (+, +), (+, -), (-, -), @@ -1501,7 +1501,7 @@ GLSL ISA These opcodes are part of :term:`GLSL`'s opcode set. Support for these opcodes is determined by a special capability bit, ``GLSL``. -Some require glsl version 1.30 (UIF/BREAKC/SWITCH/CASE/DEFAULT/ENDSWITCH). +Some require glsl version 1.30 (:opcode:`UIF`/:opcode:`BREAKC`/:opcode:`SWITCH`/:opcode:`CASE`/:opcode:`DEFAULT`/:opcode:`ENDSWITCH`). .. opcode:: CAL - Subroutine Call @@ -1521,22 +1521,22 @@ Some require glsl version 1.30 (UIF/BREAKC/SWITCH/CASE/DEFAULT/ENDSWITCH). .. opcode:: CONT - Continue Unconditionally moves the point of execution to the instruction after the - last bgnloop. The instruction must appear within a bgnloop/endloop. + last :opcode:`BGNLOOP`. The instruction must appear within a :opcode:`BGNLOOP`/:opcode:`ENDLOOP`. .. note:: - Support for CONT is determined by a special capability bit, + Support for :opcode:`CONT` is determined by a special capability bit, ``TGSI_CONT_SUPPORTED``. See :ref:`Screen` for more information. .. opcode:: BGNLOOP - Begin a Loop - Start a loop. Must have a matching endloop. + Start a loop. Must have a matching :opcode:`ENDLOOP`. .. opcode:: BGNSUB - Begin Subroutine - Starts definition of a subroutine. Must have a matching endsub. + Starts definition of a subroutine. Must have a matching :opcode:`ENDSUB`. .. opcode:: ENDLOOP - End a Loop @@ -1557,60 +1557,63 @@ Some require glsl version 1.30 (UIF/BREAKC/SWITCH/CASE/DEFAULT/ENDSWITCH). .. opcode:: BRK - Break Unconditionally moves the point of execution to the instruction after the - next endloop or endswitch. The instruction must appear within a loop/endloop - or switch/endswitch. + next :opcode:`ENDLOOP` or :opcode:`ENDSWITCH`. The instruction must appear within a :opcode:`BGNLOOP`/:opcode:`ENDLOOP` + or :opcode:`SWITCH`/:opcode:`ENDSWITCH`. .. opcode:: BREAKC - Break Conditional Conditionally moves the point of execution to the instruction after the - next endloop or endswitch. The instruction must appear within a loop/endloop - or switch/endswitch. - Condition evaluates to true if src0.x != 0 where src0.x is interpreted - as an integer register. + next :opcode:`ENDLOOP` or :opcode:`ENDSWITCH`. The instruction must appear within a :opcode:`BGNLOOP`/:opcode:`ENDLOOP` + or :opcode:`SWITCH`/:opcode:`ENDSWITCH`. + Condition evaluates to true if + +src0.x != 0 + + where ``src0.x`` is interpreted as an integer register. .. note:: Considered for removal as it's quite inconsistent wrt other opcodes - (could emulate with UIF/BRK/ENDIF). + (could emulate with :opcode:`UIF`/:opcode:`BRK`/:opcode:`ENDIF`). .. opcode:: IF - Float If - Start an IF ... ELSE .. ENDIF block. Condition evaluates to true if + Start an :opcode:`IF` ... :opcode:`ELSE`... :opcode:`ENDIF` block. Condition evaluates to true if src0.x != 0.0 - where src0.x is interpreted as a floating point register. + where ``src0.x`` is interpreted as a floating point register. .. opcode:: UIF - Bitwise If - Start an UIF ... ELSE .. ENDIF block. Condition evaluates to true if + Start an :opcode:`UIF` ... :opcode:`ELSE` ... :opcode:`ENDIF` block. Condition evaluates to true if src0.x != 0 - where src0.x is interpreted as an integer register. + where ``src0.x`` is interpreted as an integer register. .. opcode:: ELSE - Else - Starts an else block, after an IF or UIF statement. + Starts an else block, after an :opcode:`IF` or :opcode:`UIF` statement. .. opcode:: ENDIF - End If - Ends an IF or UIF block. + Ends an :opcode:`IF` or :opcode:`UIF` block. .. opcode:: SWITCH - Switch Starts a C-style switch expression. The switch consists of one or multiple - CASE statements, and at most one DEFAULT statement. Execution of a statement - ends when a BRK is hit, but just like in C falling through to other cases - without a break is allowed.
[Mesa-dev] [PATCH 12/13] gallium/docs: misc improvements
---
src/gallium/docs/source/format.rst |8 +++---
src/gallium/docs/source/tgsi.rst | 37 +++
2 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/src/gallium/docs/source/format.rst
b/src/gallium/docs/source/format.rst
index 93faf4f..f6ddbdf 100644
--- a/src/gallium/docs/source/format.rst
+++ b/src/gallium/docs/source/format.rst
@@ -17,15 +17,15 @@ with the X component in the s least-significant bits of the
integer. In C::
Format suffixes affect the interpretation of the channel:
-- ``SINT``: N bit signed integer [-2^(N-1) ... 2^(N-1) - 1]
+- ``SINT``: N bit signed integer [:math:`-2^{N-1} ... (2^{N-1} - 1)`]
- ``SNORM``:N bit signed integer normalized to [-1 ... 1]
-- ``SSCALED``: N bit signed integer [-2^(N-1) ... 2^(N-1) - 1]
+- ``SSCALED``: N bit signed integer [:math:`-2^{N-1} ... (2^{N-1} - 1)`]
- ``FIXED``:Signed fixed point integer, (N/2 - 1) bits of mantissa
- ``FLOAT``:N bit IEEE754 float
- ``NORM``: Normalized integers, signed or unsigned per channel
-- ``UINT``: N bit unsigned integer [0 ... 2^N - 1]
+- ``UINT``: N bit unsigned integer [:math:`0 ... (2^N - 1)`]
- ``UNORM``:N bit unsigned integer normalized to [0 ... 1]
-- ``USCALED``: N bit unsigned integer [0 ... 2^N - 1]
+- ``USCALED``: N bit unsigned integer [:math:`0 ... (2^N - 1)`]
The difference between ``SINT`` and ``SSCALED`` is that the former are pure
integers in shaders, while the latter are floats; likewise for ``UINT`` versus
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 9bfefd8..cf61dce 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -958,7 +958,7 @@ XXX doesn't look like most of the opcodes really belong
here.
dst = texture\_gather4 (unit, coord, component)
-(with SM5 - cube array shadow)
+(with `SM5` - cube array shadow)
.. math::
@@ -1245,10 +1245,10 @@ Support for these opcodes indicated by
PIPE_SHADER_CAP_INTEGERS (all of them?)
.. math::
- dst.x = src0.x (unsigned) (0x1f \quad \ \quad src1.x) \\
- dst.y = src0.y (unsigned) (0x1f \quad \ \quad src1.y) \\
- dst.z = src0.z (unsigned) (0x1f \quad \ \quad src1.z) \\
- dst.w = src0.w (unsigned) (0x1f \quad \ \quad src1.w)
+ dst.x = src0.x \underset{unsigned}\gg (0x1f \quad \ \quad src1.x) \\
+ dst.y = src0.y \underset{unsigned}\gg (0x1f \quad \ \quad src1.y) \\
+ dst.z = src0.z \underset{unsigned}\gg (0x1f \quad \ \quad src1.z) \\
+ dst.w = src0.w \underset{unsigned}\gg (0x1f \quad \ \quad src1.w)
.. opcode:: UCMP - Integer Conditional Move
@@ -1408,7 +1408,7 @@ These opcodes are used for bit-level manipulation of
integers.
.. opcode:: IBFE - Signed Bitfield Extract
- See SM5 instruction of the same name. Extracts a set of bits from the input,
+ See `SM5` instruction [#sm5-ops]_ of the same name. Extracts a set of bits
from the input,
and sign-extends them if the high bit of the extracted window is set.
Pseudocode::
@@ -1423,9 +1423,12 @@ These opcodes are used for bit-level manipulation of
integers.
else:
return value offset
+.. [#sm5-ops]
http://msdn.microsoft.com/en-us/library/windows/desktop/hh447232%28v=vs.85%29.aspx
+
+
.. opcode:: UBFE - Unsigned Bitfield Extract
- See SM5 instruction of the same name. Extracts a set of bits from the input,
+ See `SM5` instruction of the same name. Extracts a set of bits from the
input,
without any sign-extension.
Pseudocode::
@@ -1442,7 +1445,7 @@ These opcodes are used for bit-level manipulation of
integers.
.. opcode:: BFI - Bitfield Insert
- See SM5 instruction of the same name. Replaces a bit region of 'base' with
+ See `SM5` instruction of the same name. Replaces a bit region of 'base' with
the low bits of 'insert'.
Pseudocode::
@@ -1455,27 +1458,27 @@ These opcodes are used for bit-level manipulation of
integers.
.. opcode:: BREV - Bitfield Reverse
- See SM5 instruction BFREV. Reverses the bits of the argument.
+ See `SM5` instruction BFREV. Reverses the bits of the argument.
.. opcode:: POPC - Population Count
- See SM5 instruction COUNTBITS. Counts the number of set bits in the argument.
+ See `SM5` instruction COUNTBITS. Counts the number of set bits in the
argument.
.. opcode:: LSB - Index of lowest set bit
- See SM5 instruction FIRSTBIT_LO. Computes the 0-based index of the first set
+ See `SM5` instruction FIRSTBIT_LO. Computes the 0-based index of the first
set
bit of the argument. Returns -1 if none are set.
.. opcode:: IMSB - Index of highest non-sign bit
- See SM5 instruction FIRSTBIT_SHI. Computes the 0-based index of the highest
+ See `SM5` instruction FIRSTBIT_SHI. Computes the 0-based index of the highest
non-sign bit of the argument (i.e. highest 0 bit for negative numbers,
highest 1 bit for positive numbers). Returns -1 if all bits are the same
(i.e. for inputs 0 and -1).
..
[Mesa-dev] [PATCH 10/13] gallium/docs: Use 'Pseudocode::'
--- src/gallium/docs/source/tgsi.rst | 12 +++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index 1ca1238..f795c59 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -659,7 +659,7 @@ This instruction replicates its result. Conditional discard. Allowed in fragment shaders only. -.. math:: + Pseudocode:: if (src.x 0 || src.y 0 || src.z 0 || src.w 0) discard @@ -790,6 +790,8 @@ This instruction replicates its result. .. opcode:: PUSHA - Push Address Register On Stack + Pseudocode:: + push(src.x) push(src.y) push(src.z) @@ -805,6 +807,8 @@ This instruction replicates its result. .. opcode:: POPA - Pop Address Register From Stack + Pseudocode:: + dst.w = pop() dst.z = pop() dst.y = pop() @@ -821,6 +825,8 @@ This instruction replicates its result. .. opcode:: BRA - Branch + Pseudocode:: + pc = target .. note:: @@ -1499,12 +1505,16 @@ Some require glsl version 1.30 (UIF/BREAKC/SWITCH/CASE/DEFAULT/ENDSWITCH). .. opcode:: CAL - Subroutine Call + Pseudocode:: + push(pc) pc = target .. opcode:: RET - Subroutine Call Return + Pseudocode:: + pc = pop() -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 08/13] gallium/docs: Explanation of function insert to table
---
src/gallium/docs/source/tgsi.rst | 59 +++--
1 files changed, 30 insertions(+), 29 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index 38b5602..f91e7d6 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2220,36 +2220,37 @@ Functions
^^
- :math:`|x|` Absolute value of `x`.
++--+--+
+| :math:`|x|` |Absolute value of `x`.
|
++--+--+
+| :math:`\lceil x \rceil` | Ceiling of `x`.
|
++--+--+
+| clamp(x,y,z) |:math:`(x y) ? \quad y : ((x z) ? \quad z : x)
\quad` |
+| |Clamp x between y and z.
|
++--+--+
+| :math:`\lfloor x\rfloor` | Floor of `x`.
|
++--+--+
+| :math:`\log_2{x}`|Logarithm of `x`, base 2.
|
++--+--+
+| max(x,y) |:math:`(x y) ? \quad x : y \qquad` Maximum of x
and y. |
++--+--+
+| min(x,y) |:math:`(x y) ? \quad x : y \qquad` Minimum of x
and y. |
++--+--+
+| partialx(x) |Derivative of x relative to fragment's X.
|
++--+--+
+| partialy(x) |Derivative of x relative to fragment's Y.
|
++--+--+
+| pop()|Pop from stack.
|
++--+--+
+| :math:`x^y` |`x` to the power `y`.
|
++--+--+
+| push(x) |Push x on stack.
|
++--+--+
+| round(x) |Round x.
|
++--+--+
+| trunc(x) |Truncate x, i.e. drop the fraction bits.
|
++--+--+
- :math:`\lceil x \rceil` Ceiling of `x`.
-
- clamp(x,y,z) Clamp x between y and z.
-(x y) ? \quad y : (x z) ? \quad z : x
-
- :math:`\lfloor x\rfloor` Floor of `x`.
-
- :math:`\log_2{x}` Logarithm of `x`, base 2.
-
- max(x,y) Maximum of x and y.
-(x y) ? \quad x : y
-
- min(x,y) Minimum of x and y.
-(x y) ? \quad x : y
-
- partialx(x) Derivative of x relative to fragment's X.
-
- partialy(x) Derivative of x relative to fragment's Y.
-
- pop() Pop from stack.
-
- :math:`x^y` `x` to the power `y`.
-
- push(x) Push x on stack.
-
- round(x) Round x.
-
- trunc(x) Truncate x, i.e. drop the fraction bits.
Keywords
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 07/13] gallium/docs: alignment formulas
--- src/gallium/docs/source/tgsi.rst | 1053 ++ 1 files changed, 387 insertions(+), 666 deletions(-) diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst index 2ace544..38b5602 100644 --- a/src/gallium/docs/source/tgsi.rst +++ b/src/gallium/docs/source/tgsi.rst @@ -48,26 +48,20 @@ used. .. math:: - dst.x = \lfloor src.x\rfloor - - dst.y = \lfloor src.y\rfloor - - dst.z = \lfloor src.z\rfloor - - dst.w = \lfloor src.w\rfloor + dst.x = \lfloor src.x\rfloor \\ + dst.y = \lfloor src.y\rfloor \\ + dst.z = \lfloor src.z\rfloor \\ + dst.w = \lfloor src.w\rfloor .. opcode:: MOV - Move .. math:: - dst.x = src.x - - dst.y = src.y - - dst.z = src.z - - dst.w = src.w + dst.x = src.x \\ + dst.y = src.y \\ + dst.z = src.z \\ + dst.w = src.w .. opcode:: LIT - Light Coefficients @@ -131,26 +125,20 @@ This instruction replicates its result. The results are undefined for src 0. .. math:: - dst.x = src0.x \times src1.x - - dst.y = src0.y \times src1.y - - dst.z = src0.z \times src1.z - - dst.w = src0.w \times src1.w + dst.x = src0.x \times src1.x \\ + dst.y = src0.y \times src1.y \\ + dst.z = src0.z \times src1.z \\ + dst.w = src0.w \times src1.w .. opcode:: ADD - Add .. math:: - dst.x = src0.x + src1.x - - dst.y = src0.y + src1.y - - dst.z = src0.z + src1.z - - dst.w = src0.w + src1.w + dst.x = src0.x + src1.x \\ + dst.y = src0.y + src1.y \\ + dst.z = src0.z + src1.z \\ + dst.w = src0.w + src1.w .. opcode:: DP3 - 3-component Dot Product @@ -185,143 +173,110 @@ This instruction replicates its result. .. math:: - dst.x = min(src0.x, src1.x) - - dst.y = min(src0.y, src1.y) - - dst.z = min(src0.z, src1.z) - - dst.w = min(src0.w, src1.w) + dst.x = min(src0.x, src1.x) \\ + dst.y = min(src0.y, src1.y) \\ + dst.z = min(src0.z, src1.z) \\ + dst.w = min(src0.w, src1.w) .. opcode:: MAX - Maximum .. math:: - dst.x = max(src0.x, src1.x) - - dst.y = max(src0.y, src1.y) - - dst.z = max(src0.z, src1.z) - - dst.w = max(src0.w, src1.w) + dst.x = max(src0.x, src1.x) \\ + dst.y = max(src0.y, src1.y) \\ + dst.z = max(src0.z, src1.z) \\ + dst.w = max(src0.w, src1.w) .. opcode:: SLT - Set On Less Than .. math:: - dst.x = (src0.x src1.x) ? \quad 1.0F : 0.0F - - dst.y = (src0.y src1.y) ? \quad 1.0F : 0.0F - - dst.z = (src0.z src1.z) ? \quad 1.0F : 0.0F - - dst.w = (src0.w src1.w) ? \quad 1.0F : 0.0F + dst.x = (src0.x src1.x) ? \quad 1.0F : 0.0F \\ + dst.y = (src0.y src1.y) ? \quad 1.0F : 0.0F \\ + dst.z = (src0.z src1.z) ? \quad 1.0F : 0.0F \\ + dst.w = (src0.w src1.w) ? \quad 1.0F : 0.0F .. opcode:: SGE - Set On Greater Equal Than .. math:: - dst.x = (src0.x = src1.x) ? \quad 1.0F : 0.0F - - dst.y = (src0.y = src1.y) ? \quad 1.0F : 0.0F - - dst.z = (src0.z = src1.z) ? \quad 1.0F : 0.0F - - dst.w = (src0.w = src1.w) ? \quad 1.0F : 0.0F + dst.x = (src0.x = src1.x) ? \quad 1.0F : 0.0F \\ + dst.y = (src0.y = src1.y) ? \quad 1.0F : 0.0F \\ + dst.z = (src0.z = src1.z) ? \quad 1.0F : 0.0F \\ + dst.w = (src0.w = src1.w) ? \quad 1.0F : 0.0F .. opcode:: MAD - Multiply And Add .. math:: - dst.x = src0.x \times src1.x + src2.x - - dst.y = src0.y \times src1.y + src2.y - - dst.z = src0.z \times src1.z + src2.z - - dst.w = src0.w \times src1.w + src2.w + dst.x = src0.x \times src1.x + src2.x \\ + dst.y = src0.y \times src1.y + src2.y \\ + dst.z = src0.z \times src1.z + src2.z \\ + dst.w = src0.w \times src1.w + src2.w .. opcode:: SUB - Subtract .. math:: - dst.x = src0.x - src1.x - - dst.y = src0.y - src1.y - - dst.z = src0.z - src1.z - - dst.w = src0.w - src1.w + dst.x = src0.x - src1.x \\ + dst.y = src0.y - src1.y \\ + dst.z = src0.z - src1.z \\ + dst.w = src0.w - src1.w .. opcode:: LRP - Linear Interpolate .. math:: - dst.x = src0.x \times src1.x + (1 - src0.x) \times src2.x - - dst.y = src0.y \times src1.y + (1 - src0.y) \times src2.y - - dst.z = src0.z \times src1.z + (1 - src0.z) \times src2.z - - dst.w = src0.w \times src1.w + (1 - src0.w) \times src2.w + dst.x = src0.x \times src1.x + (1 - src0.x) \times src2.x \\ + dst.y = src0.y \times src1.y + (1 - src0.y) \times src2.y \\ + dst.z = src0.z \times src1.z + (1 - src0.z) \times src2.z \\ + dst.w = src0.w \times src1.w + (1 - src0.w) \times src2.w .. opcode:: CND - Condition .. math:: - dst.x = (src2.x 0.5) ? \quad src0.x : src1.x - - dst.y = (src2.y 0.5) ? \quad src0.y : src1.y - - dst.z = (src2.z 0.5) ? \quad src0.z : src1.z - - dst.w = (src2.w 0.5) ? \quad src0.w : src1.w + dst.x = (src2.x 0.5) ? \quad src0.x : src1.x \\ + dst.y = (src2.y 0.5) ? \quad src0.y : src1.y \\ + dst.z = (src2.z 0.5) ? \quad src0.z : src1.z \\ + dst.w = (src2.w 0.5) ? \quad src0.w : src1.w .. opcode:: DP2A - 2-component Dot Product And Add .. math:: - dst.x = src0.x \times src1.x + src0.y \times src1.y + src2.x - - dst.y =
[Mesa-dev] [PATCH 09/13] gallium/docs: Fix view of table 'texture image components' in the PDF version
---
src/gallium/docs/source/tgsi.rst |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index f91e7d6..1ca1238 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -2708,6 +2708,9 @@ by TGSI texture instructions, such as :opcode:`TEX`,
:opcode:`TXD`, and
:opcode:`TXP`. For reference, OpenGL and Direct3D conventions are shown as
well.
+
+.. tabularcolumns:: | *{4}{p{0.2\linewidth}|}
+
++--++--+
| Texture Components | Gallium | OpenGL | Direct3D 9 |
++==++==+
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 03/13] gallium/docs: Use fractions
---
src/gallium/docs/source/tgsi.rst | 40 +++---
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index bdb4655..c23408e 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -412,7 +412,7 @@ XXX cleanup on aisle three
.. math::
- dst = (1 / src.x) 0 ? clamp(1 / src.x, 5.42101e-020, 1.84467e+019) :
clamp(1 / src.x, -1.84467e+019, -5.42101e-020)
+ dst = (src.x 0) ? clamp(\frac1{src.x}, 5.42101e-020, 1.84467e+019) :
clamp(\frac1{src.x}, -1.84467e+019, -5.42101e-020)
.. opcode:: DPH - Homogeneous Dot Product
@@ -491,11 +491,11 @@ while DDY is allowed to be the same for the entire 2x2
quad.
.. math::
- dst.x = 2 \times (src0.x \times src1.x + src0.y \times src1.y + src0.z
\times src1.z) / ((src0.x)^2 + (src0.y)^2 + (src0.z)^2) \times src0.x - src1.x
+ dst.x = 2 \times \frac{src0.x \times src1.x + src0.y \times src1.y + src0.z
\times src1.z} {((src0.x)^2 + (src0.y)^2 + (src0.z)^2) \times src0.x} - src1.x
- dst.y = 2 \times (src0.x \times src1.x + src0.y \times src1.y + src0.z
\times src1.z) / ((src0.x)^2 + (src0.y)^2 + (src0.z)^2) \times src0.y - src1.y
+ dst.y = 2 \times \frac{src0.x \times src1.x + src0.y \times src1.y + src0.z
\times src1.z} {((src0.x)^2 + (src0.y)^2 + (src0.z)^2) \times src0.y} - src1.y
- dst.z = 2 \times (src0.x \times src1.x + src0.y \times src1.y + src0.z
\times src1.z) / ((src0.x)^2 + (src0.y)^2 + (src0.z)^2) \times src0.z - src1.z
+ dst.z = 2 \times \frac{src0.x \times src1.x + src0.y \times src1.y + src0.z
\times src1.z} {((src0.x)^2 + (src0.y)^2 + (src0.z)^2) \times src0.z} - src1.z
dst.w = 1
@@ -650,11 +650,11 @@ This instruction replicates its result.
.. math::
- coord.x = src0.x / src0.w
+ coord.x = \frac{src0.x}{src0.w}
- coord.y = src0.y / src0.w
+ coord.y = \frac{src0.y}{src0.w}
- coord.z = src0.z / src0.w
+ coord.z = \frac{src0.z}{src0.w}
coord.w = src0.w
@@ -838,11 +838,11 @@ This instruction replicates its result.
.. math::
- dst.x = src.x / ((src.x)^2 + (src.y)^2 + (src.z)^2)
+ dst.x = \frac{src.x} {(src.x)^2 + (src.y)^2 + (src.z)^2}
- dst.y = src.y / ((src.x)^2 + (src.y)^2 + (src.z)^2)
+ dst.y = \frac{src.y} {(src.x)^2 + (src.y)^2 + (src.z)^2}
- dst.z = src.z / ((src.x)^2 + (src.y)^2 + (src.z)^2)
+ dst.z = \frac{src.z} {(src.x)^2 + (src.y)^2 + (src.z)^2}
dst.w = 1
@@ -1270,13 +1270,13 @@ Support for these opcodes indicated by
PIPE_SHADER_CAP_INTEGERS (all of them?)
.. math::
- dst.x = src0.x \ src1.x
+ dst.x = \frac{src0.x}{src1.x}
- dst.y = src0.y \ src1.y
+ dst.y = \frac{src0.y}{src1.y}
- dst.z = src0.z \ src1.z
+ dst.z = \frac{src0.z}{src1.z}
- dst.w = src0.w \ src1.w
+ dst.w = \frac{src0.w}{src1.w}
.. opcode:: UDIV - Unsigned Integer Division
@@ -1285,13 +1285,13 @@ Support for these opcodes indicated by
PIPE_SHADER_CAP_INTEGERS (all of them?)
.. math::
- dst.x = src0.x \ src1.x
+ dst.x = \frac{src0.x}{src1.x}
- dst.y = src0.y \ src1.y
+ dst.y = \frac{src0.y}{src1.y}
- dst.z = src0.z \ src1.z
+ dst.z = \frac{src0.z}{src1.z}
- dst.w = src0.w \ src1.w
+ dst.w = \frac{src0.w}{src1.w}
.. opcode:: UMOD - Unsigned Integer Remainder
@@ -1943,9 +1943,9 @@ Support for these opcodes is XXX undecided. :T
.. math::
- dst.xy = src0.xy / src1.xy
+ dst.xy = \frac{src0.xy}{src1.xy}
- dst.zw = src0.zw / src1.zw
+ dst.zw = \frac{src0.zw}{src1.zw}
.. opcode:: DSEQ - Set on Equal
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 06/13] gallium/docs: more spaces and brackets, fix UMOD
---
src/gallium/docs/source/tgsi.rst | 88 +++---
1 files changed, 44 insertions(+), 44 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst b/src/gallium/docs/source/tgsi.rst
index b1be923..2ace544 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -358,7 +358,7 @@ This instruction replicates its result.
.. math::
- dst = 2^{src.x}
+ dst = 2^{(src.x)}
.. opcode:: LG2 - Logarithm Base 2
@@ -367,7 +367,7 @@ This instruction replicates its result.
.. math::
- dst = \log_2{src.x}
+ dst = \log_2{(src.x)}
.. opcode:: POW - Power
@@ -376,7 +376,7 @@ This instruction replicates its result.
.. math::
- dst = src0.x^{src1.x}
+ dst = (src0.x)^{(src1.x)}
.. opcode:: XPD - Cross Product
@@ -429,7 +429,7 @@ This instruction replicates its result.
.. math::
- dst = \cos{src.x}
+ dst = \cos{(src.x)}
.. opcode:: DDX, DDX_FINE - Derivative Relative To X
@@ -548,7 +548,7 @@ This instruction replicates its result.
.. math::
- dst = \sin{src.x}
+ dst = \sin{(src.x)}
.. opcode:: SLE - Set On Less Equal Than
@@ -605,7 +605,7 @@ This instruction replicates its result.
coord = src0
- shadow_ref = src0.z or src0.w (optional)
+ shadow_ref = src0.z \quad or \quad src0.w (optional)
unit = src1
@@ -736,13 +736,13 @@ This instruction replicates its result.
.. math::
- dst.x = (src.x 0) ? \quad 1 : (src.x 0) ? \quad -1 : 0
+ dst.x = (src.x 0) ? \quad 1 : ((src.x 0) ? \quad -1 : 0)
- dst.y = (src.y 0) ? \quad 1 : (src.y 0) ? \quad -1 : 0
+ dst.y = (src.y 0) ? \quad 1 : ((src.y 0) ? \quad -1 : 0)
- dst.z = (src.z 0) ? \quad 1 : (src.z 0) ? \quad -1 : 0
+ dst.z = (src.z 0) ? \quad 1 : ((src.z 0) ? \quad -1 : 0)
- dst.w = (src.w 0) ? \quad 1 : (src.w 0) ? \quad -1 : 0
+ dst.w = (src.w 0) ? \quad 1 : ((src.w 0) ? \quad -1 : 0)
.. opcode:: CMP - Compare
@@ -778,9 +778,9 @@ This instruction replicates its result.
.. math::
- dst.x = \cos{src.x}
+ dst.x = \cos{(src.x)}
- dst.y = \sin{src.x}
+ dst.y = \sin{(src.x)}
dst.z = 0
@@ -1299,52 +1299,52 @@ Support for these opcodes indicated by
PIPE_SHADER_CAP_INTEGERS (all of them?)
.. math::
- dst.x = src0.x \ src1.x
+ dst.x = src0.x \quad \% \quad src1.x
- dst.y = src0.y \ src1.y
+ dst.y = src0.y \quad \% \quad src1.y
- dst.z = src0.z \ src1.z
+ dst.z = src0.z \quad \% \quad src1.z
- dst.w = src0.w \ src1.w
+ dst.w = src0.w \quad \% \quad src1.w
.. opcode:: NOT - Bitwise Not
.. math::
- dst.x = \sim src.x
+ dst.x = \quad \sim (src.x)
- dst.y = \sim src.y
+ dst.y = \quad \sim (src.y)
- dst.z = \sim src.z
+ dst.z = \quad \sim (src.z)
- dst.w = \sim src.w
+ dst.w = \quad \sim (src.w)
.. opcode:: AND - Bitwise And
.. math::
- dst.x = src0.x \ src1.x
+ dst.x = src0.x \quad \ \quad src1.x
- dst.y = src0.y \ src1.y
+ dst.y = src0.y \quad \ \quad src1.y
- dst.z = src0.z \ src1.z
+ dst.z = src0.z \quad \ \quad src1.z
- dst.w = src0.w \ src1.w
+ dst.w = src0.w \quad \ \quad src1.w
.. opcode:: OR - Bitwise Or
.. math::
- dst.x = src0.x | src1.x
+ dst.x = src0.x \quad | \quad src1.x
- dst.y = src0.y | src1.y
+ dst.y = src0.y \quad | \quad src1.y
- dst.z = src0.z | src1.z
+ dst.z = src0.z \quad | \quad src1.z
- dst.w = src0.w | src1.w
+ dst.w = src0.w \quad | \quad src1.w
.. opcode:: XOR - Bitwise Xor
@@ -1418,13 +1418,13 @@ Support for these opcodes indicated by
PIPE_SHADER_CAP_INTEGERS (all of them?)
.. math::
- dst.x = src0.x (0x1f \ src1.x)
+ dst.x = src0.x (0x1f \quad \ \quad src1.x)
- dst.y = src0.y (0x1f \ src1.y)
+ dst.y = src0.y (0x1f \quad \ \quad src1.y)
- dst.z = src0.z (0x1f \ src1.z)
+ dst.z = src0.z (0x1f \quad \ \quad src1.z)
- dst.w = src0.w (0x1f \ src1.w)
+ dst.w = src0.w (0x1f \quad \ \quad src1.w)
.. opcode:: ISHR - Arithmetic Shift Right (of Signed Integer)
@@ -1433,13 +1433,13 @@ Support for these opcodes indicated by
PIPE_SHADER_CAP_INTEGERS (all of them?)
.. math::
- dst.x = src0.x (0x1f \ src1.x)
+ dst.x = src0.x (0x1f \quad \ \quad src1.x)
- dst.y = src0.y (0x1f \ src1.y)
+ dst.y = src0.y (0x1f \quad \ \quad src1.y)
- dst.z = src0.z (0x1f \ src1.z)
+ dst.z = src0.z (0x1f \quad \ \quad src1.z)
- dst.w = src0.w (0x1f \ src1.w)
+ dst.w = src0.w (0x1f \quad \ \quad src1.w)
.. opcode:: USHR - Logical Shift Right
@@ -1448,13 +1448,13 @@ Support for these opcodes indicated by
PIPE_SHADER_CAP_INTEGERS (all of them?)
.. math::
- dst.x = src0.x (unsigned) (0x1f \ src1.x)
+ dst.x = src0.x (unsigned) (0x1f \quad \ \quad src1.x)
- dst.y = src0.y (unsigned) (0x1f \ src1.y)
+ dst.y = src0.y (unsigned) (0x1f \quad \ \quad src1.y)
- dst.z = src0.z (unsigned) (0x1f \ src1.z)
+ dst.z = src0.z (unsigned) (0x1f \quad \ \quad src1.z)
- dst.w = src0.w (unsigned) (0x1f \ src1.w)
+ dst.w = src0.w (unsigned) (0x1f
[Mesa-dev] [PATCH 00/13] gallium/docs: A series of patches to improve appearance Gallium documentation
*** BLURB HERE *** Alexander Troosh (13): gallium/docs: Some opcodes was not included into the INDEX section of pdf version gallium/docs: Use squarings gallium/docs: Use fractions gallium/docs: Best view of conditional-expression operator via spaces gallium/docs: refactoring opcode RCC gallium/docs: more spaces and brackets, fix UMOD gallium/docs: alignment formulas gallium/docs: Explanation of function insert to table gallium/docs: Fix view of table 'texture image components' in the PDF version gallium/docs: Use 'Pseudocode::' gallium/docs: Highlighting opcodes gallium/docs: misc improvements gallium/docs: Add minor info about Ilo, Freedreno, VC4, Noop drivers src/gallium/docs/source/distro.rst | 27 + src/gallium/docs/source/format.rst |8 +- src/gallium/docs/source/tgsi.rst | 1280 ++-- 3 files changed, 541 insertions(+), 774 deletions(-) -- 1.7.3.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] fbo-depth-array:Check completness with a color texture
---
tests/all.py| 2 +-
tests/fbo/fbo-depth-array.c | 36 ++--
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/tests/all.py b/tests/all.py
index 586cead..9aa600f 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2831,7 +2831,7 @@ add_shader_test_dir(ext_texture_array,
add_msaa_visual_plain_tests(ext_texture_array, 'copyteximage 1D_ARRAY')
add_msaa_visual_plain_tests(ext_texture_array, 'copyteximage 2D_ARRAY')
add_plain_test(ext_texture_array, 'fbo-array')
-for test in ('depth-clear', 'depth-layered-clear', 'depth-draw',
'fs-writes-depth',
+for test in ('depth-clear', 'depth-layered-clear',
'depth-stencil-color-clear', 'depth-draw', 'fs-writes-depth',
'stencil-clear', 'stencil-layered-clear', 'stencil-draw',
'fs-writes-stencil'):
add_concurrent_test(ext_texture_array, 'fbo-depth-array ' + test)
add_plain_test(ext_texture_array, 'array-texture')
diff --git a/tests/fbo/fbo-depth-array.c b/tests/fbo/fbo-depth-array.c
index 84370e4..dde807d 100644
--- a/tests/fbo/fbo-depth-array.c
+++ b/tests/fbo/fbo-depth-array.c
@@ -46,6 +46,7 @@
enum {
CLEAR,
LAYERED_CLEAR,
+ LAYERED_DEPTH_STENCIL_COLOR_CLEAR,
DRAW,
FS_WRITES_VALUE,
};
@@ -135,11 +136,13 @@ static GLuint program_stencil_output;
static GLuint program_texdepth;
static GLuint program_texstencil;
+static GLuint color_texture;
+
static float
get_depth_value(unsigned layer)
{
- if (test == LAYERED_CLEAR)
+ if (test == LAYERED_CLEAR || LAYERED_DEPTH_STENCIL_COLOR_CLEAR)
return 0.4; /* constant */
else
return (double)(layer+1) / (layers+1);
@@ -181,6 +184,10 @@ parse_args(int argc, char **argv)
test = LAYERED_CLEAR;
puts(Testing layered glClear);
}
+ else if (!strcmp(argv[i], depth-stencil-color-layered-clear))
{
+ test = LAYERED_DEPTH_STENCIL_COLOR_CLEAR;
+ puts(Testing depth stencil color layered glClear);
+ }
else if (!strcmp(argv[i], depth-draw)) {
test = DRAW;
puts(Testing drawing);
@@ -224,6 +231,14 @@ create_array_fbo(void)
int layer;
glGenTextures(1, tex);
+ glGenTextures(1, color_texture);
+
+ glBindTexture(GL_TEXTURE_2D_ARRAY, color_texture);
+ glTexImage3D(GL_TEXTURE_2D_ARRAY, 0, GL_RGBA,
+width, height, layers, 0,
+GL_RGBA, GL_UNSIGNED_INT, NULL);
+ assert(glGetError() == 0);
+
glBindTexture(GL_TEXTURE_2D_ARRAY, tex);
assert(glGetError() == 0);
@@ -241,11 +256,19 @@ create_array_fbo(void)
/* draw something into each layer of the array texture */
for (layer = 0; layer layers; layer++) {
- if (test == LAYERED_CLEAR) {
- glFramebufferTexture(GL_FRAMEBUFFER,
-test_stencil ?
GL_STENCIL_ATTACHMENT :
- GL_DEPTH_ATTACHMENT,
-tex, 0);
+ if (test == LAYERED_CLEAR || test ==
LAYERED_DEPTH_STENCIL_COLOR_CLEAR) {
+ if (test == LAYERED_DEPTH_STENCIL_COLOR_CLEAR) {
+ glFramebufferTexture(GL_FRAMEBUFFER,
+GL_COLOR_ATTACHMENT0_EXT,
+color_texture, 0);
+ glFramebufferTexture(GL_FRAMEBUFFER,
+
GL_DEPTH_STENCIL_ATTACHMENT,
+tex, 0);
+ } else
+ glFramebufferTexture(GL_FRAMEBUFFER,
+test_stencil ?
GL_STENCIL_ATTACHMENT :
+
GL_DEPTH_ATTACHMENT,
+tex, 0);
status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (status != GL_FRAMEBUFFER_COMPLETE) {
@@ -433,6 +456,7 @@ test_once(void)
}
glDeleteTextures(1, tex);
+ glDeleteTextures(1, color_texture);
assert(glGetError() == 0);
return pass;
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] fbo-depth-array:Check completness with a color texture
On Wed, Oct 8, 2014 at 8:33 AM, Vincent Lejeune v...@ovi.com wrote:
---
tests/all.py| 2 +-
tests/fbo/fbo-depth-array.c | 36 ++--
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/tests/all.py b/tests/all.py
index 586cead..9aa600f 100644
--- a/tests/all.py
+++ b/tests/all.py
@@ -2831,7 +2831,7 @@ add_shader_test_dir(ext_texture_array,
add_msaa_visual_plain_tests(ext_texture_array, 'copyteximage 1D_ARRAY')
add_msaa_visual_plain_tests(ext_texture_array, 'copyteximage 2D_ARRAY')
add_plain_test(ext_texture_array, 'fbo-array')
-for test in ('depth-clear', 'depth-layered-clear', 'depth-draw',
'fs-writes-depth',
+for test in ('depth-clear', 'depth-layered-clear',
'depth-stencil-color-clear', 'depth-draw', 'fs-writes-depth',
depth-stencil-color-layered-clear, right? Or fix the string in the test...
'stencil-clear', 'stencil-layered-clear', 'stencil-draw',
'fs-writes-stencil'):
add_concurrent_test(ext_texture_array, 'fbo-depth-array ' + test)
add_plain_test(ext_texture_array, 'array-texture')
diff --git a/tests/fbo/fbo-depth-array.c b/tests/fbo/fbo-depth-array.c
index 84370e4..dde807d 100644
--- a/tests/fbo/fbo-depth-array.c
+++ b/tests/fbo/fbo-depth-array.c
@@ -46,6 +46,7 @@
enum {
CLEAR,
LAYERED_CLEAR,
+ LAYERED_DEPTH_STENCIL_COLOR_CLEAR,
DRAW,
FS_WRITES_VALUE,
};
@@ -135,11 +136,13 @@ static GLuint program_stencil_output;
static GLuint program_texdepth;
static GLuint program_texstencil;
+static GLuint color_texture;
+
static float
get_depth_value(unsigned layer)
{
- if (test == LAYERED_CLEAR)
+ if (test == LAYERED_CLEAR || LAYERED_DEPTH_STENCIL_COLOR_CLEAR)
return 0.4; /* constant */
else
return (double)(layer+1) / (layers+1);
@@ -181,6 +184,10 @@ parse_args(int argc, char **argv)
test = LAYERED_CLEAR;
puts(Testing layered glClear);
}
+ else if (!strcmp(argv[i],
depth-stencil-color-layered-clear)) {
+ test = LAYERED_DEPTH_STENCIL_COLOR_CLEAR;
+ puts(Testing depth stencil color layered glClear);
+ }
else if (!strcmp(argv[i], depth-draw)) {
test = DRAW;
puts(Testing drawing);
@@ -224,6 +231,14 @@ create_array_fbo(void)
int layer;
glGenTextures(1, tex);
+ glGenTextures(1, color_texture);
+
+ glBindTexture(GL_TEXTURE_2D_ARRAY, color_texture);
+ glTexImage3D(GL_TEXTURE_2D_ARRAY, 0, GL_RGBA,
+width, height, layers, 0,
+GL_RGBA, GL_UNSIGNED_INT, NULL);
+ assert(glGetError() == 0);
+
glBindTexture(GL_TEXTURE_2D_ARRAY, tex);
assert(glGetError() == 0);
@@ -241,11 +256,19 @@ create_array_fbo(void)
/* draw something into each layer of the array texture */
for (layer = 0; layer layers; layer++) {
- if (test == LAYERED_CLEAR) {
- glFramebufferTexture(GL_FRAMEBUFFER,
-test_stencil ?
GL_STENCIL_ATTACHMENT :
-
GL_DEPTH_ATTACHMENT,
-tex, 0);
+ if (test == LAYERED_CLEAR || test ==
LAYERED_DEPTH_STENCIL_COLOR_CLEAR) {
+ if (test == LAYERED_DEPTH_STENCIL_COLOR_CLEAR) {
+ glFramebufferTexture(GL_FRAMEBUFFER,
+GL_COLOR_ATTACHMENT0_EXT,
+color_texture, 0);
+ glFramebufferTexture(GL_FRAMEBUFFER,
+
GL_DEPTH_STENCIL_ATTACHMENT,
+tex, 0);
+ } else
+ glFramebufferTexture(GL_FRAMEBUFFER,
+test_stencil ?
GL_STENCIL_ATTACHMENT :
+
GL_DEPTH_ATTACHMENT,
+tex, 0);
status = glCheckFramebufferStatus(GL_FRAMEBUFFER);
if (status != GL_FRAMEBUFFER_COMPLETE) {
@@ -433,6 +456,7 @@ test_once(void)
}
glDeleteTextures(1, tex);
+ glDeleteTextures(1, color_texture);
assert(glGetError() == 0);
return pass;
}
--
1.9.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
Re: [Mesa-dev] [PATCH] configure.ac: check for libexpat when no pkg-config is available
On 7 October 2014 15:32, Andres Gomez ago...@igalia.com wrote: Previously, when no pkg-config was available for libexpat we would just add the needed linking flags without any extra check. Now, we check that the library and the headers are also installed in the building environment. I secretly hope that all distros that provide the old expat will die off soon, thus we can simplify things. Either way this one looks good for me. Reviewed-by: Emil Velikov emil.l.veli...@gmail.com --- configure.ac | 15 +++ 1 file changed, 7 insertions(+), 8 deletions(-) diff --git a/configure.ac b/configure.ac index 2a5c143..a8f814d 100644 --- a/configure.ac +++ b/configure.ac @@ -1126,14 +1126,13 @@ if test x$enable_dri = xyes; then fi # Check for expat -PKG_CHECK_EXISTS([expat], [have_expat=yes], [have_expat=no]) -if test x$have_expat = xyes; then - PKG_CHECK_MODULES([EXPAT], [expat], [], - AC_MSG_ERROR([Expat required for DRI.])) -else - # expat version 2.0 and earlier do not provide expat.pc - EXPAT_LIBS=-lexpat -fi +PKG_CHECK_MODULES([EXPAT], [expat], [], +# expat version 2.0 and earlier do not provide expat.pc +[AC_CHECK_HEADER([expat.h],[], + [AC_MSG_ERROR([Expat headers required for DRI not found])]) + AC_CHECK_LIB([expat],[XML_ParserCreate],[], + [AC_MSG_ERROR([Expat library required for DRI not found])]) + EXPAT_LIBS=-lexpat]) DRICOMMON_NEED_LIBDRM=no # If we are building any DRI driver other than swrast. -- 1.9.1 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa/main: Fix unpack_R5G6B5_UNORM.
Am 08.10.2014 um 07:11 schrieb Jason Ekstrand: On Oct 8, 2014 6:36 AM, Iago Toral ito...@igalia.com mailto:ito...@igalia.com wrote: El 2014-10-07 21:46, Jason Ekstrand escribió: On Oct 7, 2014 12:04 PM, Iago Toral Quiroga ito...@igalia.com mailto:ito...@igalia.com wrote: There is a comment warning about the fact that this is not doing what we expect, so fix it. This should be doing the same as unpack_B5G6R5_UNORM but swapping B and R. --- Jason started some work to auto-generate the format_pack.c and format_unpack.c files which I think has this fixed. I am continuing his work on this at the moment, but I guess it might make sense to fix this in the current code too while that work is on-going. Not much time to reply right now, but I seem to recall there being a bit more to fix here. What about packing and swrast's texel fetch implementation. Are those OK for this format? No piglit regressions observed. On what drivers? It might be good to test on swrast and llvmpipe. I'm not super-concerned there but we should at least try not to break it. --Jason That was on Intel, but you are right, at least classic swrast has some regressions with this. For reference, I did not see any regressions on Gallium Softpipe but I could only run a small subset of tests with this driver (-t texture -t color -t format) or otherwise it would hog my CPU and eventually crash my system. Could not test with llvmpipe, for some reason, even when I am bulding with llvm and I see the llvmpipe sources being built Mesa insists in using the softpipe driver at runtime... I can give you the configure flags for testing llvmpipe if you'd like. Yes, doing a full piglit run on llvmpipe or swrast requires a pretty beefy desktop and still takes quite a while. Since there are regressions on swrast at least I guess we should just drop this patch until we have a proper fix for all drivers. I'm not as worried about llvmpipe because it fails about half the tests it attempts anyway. I would like to know what's going on with swrast though. llvmpipe's result in the area of texture fetch should be near perfect (at least if you've got a sse41 capable cpu), I'm not aware of any major bugs there. It does, however, do some not quite conformant optimizations by default (nothing which graphics hw at some point didn't already do...). So, to get these perfect results, you'd need to set GALLIVM_DEBUG=no_brilinear,no_quad_lod,no_rho_approx. no_brilinear does not clamp lod to one mipmap if the lod is close enough to that mipmap. no_quad_lod does not do per quad lod if that's not conformant (ok for ordinary implicit derivatives, not ok for explicit derivatives, per-pixel lod bias etc.) no_rho_approx will use suggested formula for rho calculation, though OpenGL still explicitly permits using the simpler formula (swrast has both formulas too though the simple one is ifdefed out). On top of that, I believe there are some failures due to precision issues with small ( 8 bits) numbers as the rescaling isn't perfect in all places (IIRC we got a bunch more failures when the formula for signed numbers was switched). However, this ought to be always just precision, nothing like switched channels of course. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 --- Comment #11 from Kai k...@dev.carbon-project.org --- (In reply to Michel Dänzer from comment #10) Does the kernel patch I attached to bug 84662 help? Note that you may need a newer kernel for it to apply. Which one? Attachment 107451, attachment 107544 or both? Do I need the other two patches for Mesa, attachment 107542 and attachment 107543, you've attached to that report, as well? -- 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 0/3] cl workdim v2
Jan Vesely jan.ves...@rutgers.edu writes:
[SNIP]
I also don't like that this way there is no difference between
explicit and implicit kernel arguments. On the other hand it's simple,
and does not need additional per driver code.
Yeah... We definitely want to hide these from the user, as e.g. the
CL_KERNEL_NUM_ARGS param is required by the spec to return the number of
arguments provided by the user, and we don't want the user to set
implicit args, so it gets a bit messy. I think I like better your
original idea of passing them as launch_grid() arguments, even though
the grid offset and dimension parameters are somewhat artificial from a
the hardware's point of view.
sorry to bug you some more with this. I tried one more thing before
going back to the launch_grid parameters. this time it implements a
parallel infrastructure for implicit arguments by creating artificial
module arguments for uint and size_t (I don't think we need more for
implicit arguments).
I only added the work dimension argument but adding more should be easy.
If you think that the launch_grid way is better, I'll stop experimenting
as I ran out of ideas I wanted to try.
ping
should I just resend using git instead of attachments?
Hi Jan, I'm sorry, I finally had a while to have a look into this. I've
taken your series and tried to fix the couple of issues I wasn't very
comfortable with, see the attached series. Does it look OK to you?
Note that it's completely untested, maybe you could give it a run on
your system?
Thanks.
thanks,
jan
[SNIP]
--
Jan Vesely jan.ves...@rutgers.edu
From bb592403bf43f11aba2299c498599827f295a648 Mon Sep 17 00:00:00 2001
From: Francisco Jerez curroje...@riseup.net
Date: Wed, 8 Oct 2014 17:29:14 +0300
Subject: [PATCH 1/4] clover: Use unreachable() from util/macros.h instead of
assert(0).
---
src/gallium/state_trackers/clover/Makefile.am | 1 +
src/gallium/state_trackers/clover/core/device.cpp | 6 ++
src/gallium/state_trackers/clover/core/object.hpp | 1 +
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/clover/Makefile.am b/src/gallium/state_trackers/clover/Makefile.am
index cb1e9c2..62c13fa 100644
--- a/src/gallium/state_trackers/clover/Makefile.am
+++ b/src/gallium/state_trackers/clover/Makefile.am
@@ -6,6 +6,7 @@ AM_CPPFLAGS = \
$(GALLIUM_PIPE_LOADER_DEFINES) \
-DPIPE_SEARCH_DIR=\$(libdir)/gallium-pipe\ \
-I$(top_srcdir)/include \
+ -I$(top_srcdir)/src \
-I$(top_srcdir)/src/gallium/include \
-I$(top_srcdir)/src/gallium/drivers \
-I$(top_srcdir)/src/gallium/auxiliary \
diff --git a/src/gallium/state_trackers/clover/core/device.cpp b/src/gallium/state_trackers/clover/core/device.cpp
index 12c9584..688a7dd 100644
--- a/src/gallium/state_trackers/clover/core/device.cpp
+++ b/src/gallium/state_trackers/clover/core/device.cpp
@@ -70,8 +70,7 @@ device::type() const {
case PIPE_LOADER_DEVICE_PLATFORM:
return CL_DEVICE_TYPE_GPU;
default:
- assert(0);
- return 0;
+ unreachable(Unknown device type.);
}
}
@@ -84,8 +83,7 @@ device::vendor_id() const {
case PIPE_LOADER_DEVICE_PCI:
return ldev-u.pci.vendor_id;
default:
- assert(0);
- return 0;
+ unreachable(Unknown device type.);
}
}
diff --git a/src/gallium/state_trackers/clover/core/object.hpp b/src/gallium/state_trackers/clover/core/object.hpp
index 697565c..daad068 100644
--- a/src/gallium/state_trackers/clover/core/object.hpp
+++ b/src/gallium/state_trackers/clover/core/object.hpp
@@ -32,6 +32,7 @@
#include core/error.hpp
#include core/property.hpp
#include api/dispatch.hpp
+#include util/macros.h
///
/// Main namespace of the CL state tracker.
--
2.1.1
From 21f34572ed3fcccb086e3b88bdfb27d664a6b82f Mon Sep 17 00:00:00 2001
From: Francisco Jerez curroje...@riseup.net
Date: Wed, 8 Oct 2014 17:32:18 +0300
Subject: [PATCH 2/4] clover: Add semantic information to module::argument for
implicit parameter passing.
---
src/gallium/state_trackers/clover/core/module.hpp | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/src/gallium/state_trackers/clover/core/module.hpp b/src/gallium/state_trackers/clover/core/module.hpp
index 18a5bfb..268e3ba 100644
--- a/src/gallium/state_trackers/clover/core/module.hpp
+++ b/src/gallium/state_trackers/clover/core/module.hpp
@@ -68,27 +68,35 @@ namespace clover {
sign_ext
};
+ enum semantic {
+general,
+grid_dimension,
+grid_offset
+ };
+
argument(enum type type, size_t size,
size_t target_size, size_t target_align,
- enum ext_type ext_type) :
+ enum ext_type ext_type,
+ enum semantic semantic = general) :
type(type), size(size),
target_size(target_size), target_align(target_align),
-ext_type(ext_type) { }
+
Re: [Mesa-dev] [PATCH 05/13] gallium/docs: refactoring opcode RCC
Am 08.10.2014 um 13:40 schrieb Alexander Troosh:
---
src/gallium/docs/source/tgsi.rst |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/gallium/docs/source/tgsi.rst
b/src/gallium/docs/source/tgsi.rst
index 12c675e..b1be923 100644
--- a/src/gallium/docs/source/tgsi.rst
+++ b/src/gallium/docs/source/tgsi.rst
@@ -408,11 +408,10 @@ This instruction replicates its result.
This instruction replicates its result.
-XXX cleanup on aisle three
-
.. math::
- dst = (src.x 0) ? \quad clamp(\frac1{src.x}, 5.42101e-020, 1.84467e+019)
: clamp(\frac1{src.x}, -1.84467e+019, -5.42101e-020)
+ dst = \begin{cases} clamp\left(\dfrac1{src.x}, \quad +5.42101 \times
{10}^{-20}, \quad +1.84467 \times {10}^{+19}\right) \mbox{for } src.x 0 \\
+ clamp\left(\dfrac1{src.x}, \quad -1.84467 \times
{10}^{+19}, \quad -5.42101 \times {10}^{-20}\right) \mbox{otherwise}
\end{cases}
.. opcode:: DPH - Homogeneous Dot Product
FWIW I'm pretty sure the comment you've deleted referred to the actual
opcode, not the documentation of it. But not really an issue...
Some of the changes in the series look a bit confusing viewed as source
(who looks at the processed version, anyway :-)), but I guess it all
works. So that's ok by me but I'm not an expert on the matter.
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84805] New: DEF files missing for GLES1/GLES2
https://bugs.freedesktop.org/show_bug.cgi?id=84805 Bug ID: 84805 Summary: DEF files missing for GLES1/GLES2 Product: Mesa Version: git Hardware: x86 (IA32) OS: Windows (All) Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: genpfa...@gmail.com Created attachment 107558 -- https://bugs.freedesktop.org/attachment.cgi?id=107558action=edit Add DEF files for GLES1/GLES2 GLES1 and GLES2 are missing DEF files for their respective DLLs. -- 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 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 --- Comment #12 from Michel Dänzer mic...@daenzer.net --- (In reply to Kai from comment #11) Please try with all the patches you mentioned. -- 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 84805] DEF files missing for GLES1/GLES2
https://bugs.freedesktop.org/show_bug.cgi?id=84805 Matt Turner matts...@gmail.com changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #1 from Matt Turner matts...@gmail.com --- I assume you copied the list of functions from the ABI-check scripts. Those lists contain more than what you actually want to export. See the FIXME comments at the top. For instance, glMultiDrawArraysEXT shouldn't be exported. -- 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 05/13] gallium/docs: refactoring opcode RCC
FWIW I'm pretty sure the comment you've deleted referred to the actual opcode, not the documentation of it. But not really an issue... Some of the changes in the series look a bit confusing viewed as source (who looks at the processed version, anyway :-)), but I guess it all works. So that's ok by me but I'm not an expert on the matter. Roland Roland, this patch change formulа of RCC opcode from: http://gallium.readthedocs.org/en/latest/tgsi.html#opcode-RCC ( http://gallium.readthedocs.org/en/latest/_images/math/0cb182169e07191c372a20e83a952e2aff430b63.png ) to view as in attachment I'm not think look to sources of document better compiled html/pdf versions. :) Thanks___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84805] DEF files missing for GLES1/GLES2
https://bugs.freedesktop.org/show_bug.cgi?id=84805 --- Comment #2 from Charles Huber genpfa...@gmail.com --- I just took the existing decorated exports (via 'dumpbin /exports') and stripped the prefix/suffixes. -- 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 05/10] clover: Add environment variables for dumping kernel code
On Oct 6, 2014, at 12:44 PM, Tom Stellard thomas.stell...@amd.com wrote:
---
.../state_trackers/clover/llvm/invocation.cpp | 74 ++
1 file changed, 63 insertions(+), 11 deletions(-)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index a1a54e0..3e6a186 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -61,6 +61,8 @@
#include llvm/Support/TargetRegistry.h
#include llvm/Transforms/IPO.h
#include llvm/Transforms/IPO/PassManagerBuilder.h
+#include llvm/Transforms/Utils/Cloning.h
+
#if HAVE_LLVM 0x0302
#include llvm/Target/TargetData.h
@@ -433,19 +435,39 @@ namespace {
return m;
}
+ static void emit_code(LLVMTargetMachineRef tm, LLVMModuleRef mod,
+ LLVMCodeGenFileType file_type,
+ LLVMMemoryBufferRef *out_buffer,
+ compat::string r_log) {
+ LLVMBool err;
+ char *err_message = NULL;
+
+ err = LLVMTargetMachineEmitToMemoryBuffer(tm, mod, file_type,
+err_message, out_buffer);
+
+ if (err) {
+ r_log = std::string(err_message);
+ }
+
+ LLVMDisposeMessage(err_message);
+
+ if (err) {
+ throw build_error();
+ }
+ }
+
module
build_module_native(llvm::Module *mod,
const std::vectorllvm::Function * kernels,
clang::LangAS::Map address_spaces,
std::string triple, std::string processor,
- compat::string r_log) {
+ bool dump_asm, compat::string r_log) {
std::string log;
LLVMTargetRef target;
char *error_message;
LLVMMemoryBufferRef out_buffer;
unsigned buffer_size;
const char *buffer_data;
- LLVMBool err;
LLVMModuleRef mod_ref = wrap(mod);
if (LLVMGetTargetFromTriple(triple.c_str(), target, error_message)) {
@@ -463,16 +485,27 @@ namespace {
throw build_error();
}
- err = LLVMTargetMachineEmitToMemoryBuffer(tm, mod_ref, LLVMObjectFile,
-error_message, out_buffer);
+ if (dump_asm) {
+ LLVMSetTargetMachineAsmVerbosity(tm, true);
+#if HAVE_LLVM = 0x0306
+ LLVMSetTargetMachineShowMCEncoding(tm, true);
+#endif
+ LLVMModuleRef debug_mod = wrap(llvm::CloneModule(mod));
+ emit_code(tm, debug_mod, LLVMAssemblyFile, out_buffer, r_log);
+ buffer_size = LLVMGetBufferSize(out_buffer);
+ buffer_data = LLVMGetBufferStart(out_buffer);
+ fprintf(stderr, %.*s\n, buffer_size, buffer_data);
It would be much better to emit each of these to a separate file with a
consistent naming scheme than to just dump everything to stderr. It’s easier to
just have a separate file for the source, IR and ISA to look at and compare
rather than having to split it out of the rest of the debug output, which also
gets harder as programs get bigger and add multiple kernels. There’s also the
problem with stderr not being flushed if the machine hangs, so you only get
partial output.
What we have is an environment variable that specifies the prefix to use for
the file name, (defaulting to _temp_), so the output is like
_temp_0_Tahiti_foo.isa, _temp_0_Tahiti_foo.bc, _temp_1_Tahiti_bar.cl. The
number is the compile index for the program, which is important for programs
with multiple compiles, especially for ones which compile kernels with the same
name multiple times (which seems to be strangely not uncommon). The specified
prefix is useful for saving sets of slightly different output with a change or
different compile options or something like that
- if (err) {
- LLVMDisposeTargetMachine(tm);
- r_log = std::string(error_message);
- LLVMDisposeMessage(error_message);
- throw build_error();
+ LLVMSetTargetMachineAsmVerbosity(tm, false);
+#if HAVE_LLVM = 0x0306
+ LLVMSetTargetMachineShowMCEncoding(tm, false);
+#endif
+ LLVMDisposeMemoryBuffer(out_buffer);
+ LLVMDisposeModule(debug_mod);
}
+ emit_code(tm, mod_ref, LLVMObjectFile, out_buffer, r_log);
+
buffer_size = LLVMGetBufferSize(out_buffer);
buffer_data = LLVMGetBufferStart(out_buffer);
@@ -569,6 +602,18 @@ static void diagnostic_handler(const
llvm::DiagnosticInfo di, void *err_string)
#endif
+#define DBG_CLC (1 0)
+#define DBG_LLVM (1 1)
+#define DBG_ASM (1 2)
+
+static const struct debug_named_value debug_options[] = {
+ {clc, DBG_CLC, Dump the OpenCL C code for all kernels.},
+ {llvm, DBG_LLVM, Dump the generated LLVM IR for all kernels.},
+ {asm, DBG_ASM, Dump kernel assembly code for targets specifying
+
[Mesa-dev] [Bug 84805] DEF files missing for GLES1/GLES2
https://bugs.freedesktop.org/show_bug.cgi?id=84805 --- Comment #3 from Charles Huber genpfa...@gmail.com --- Created attachment 107563 -- https://bugs.freedesktop.org/attachment.cgi?id=107563action=edit Add DEF files for GLES1/GLES2, take 2 This time around I took the exports directly from GLES/gl.h and GLES2/gl2.h. -- 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 84807] New: Build issue starting between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b and a3e9582f09249ad27716ba82c7dfcee685b65d51
https://bugs.freedesktop.org/show_bug.cgi?id=84807 Bug ID: 84807 Summary: Build issue starting between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b and a3e9582f09249ad27716ba82c7dfcee685b65d51 Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Mesa core Assignee: mesa-dev@lists.freedesktop.org Reporter: adf.li...@gmail.com Created attachment 107564 -- https://bugs.freedesktop.org/attachment.cgi?id=107564action=edit example patch Haven't had time to bisect properly, but there are a group of build patches between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b (Good) and a3e9582f09249ad27716ba82c7dfcee685b65d51 (Bad) The issue is that without doing a make distclean applying a trivial patch and doing make no longer works properly. I am radeonsi and from clean build like - ./autogen.sh --prefix=/usr --sysconfdir=/etc --enable-texture-float --with-egl-platforms=x11,drm --with-gallium-drivers=radeonsi,swrast --enable-opencl --enable-gbm --enable-shared-glapi --enable-glx-tls --with-dri-drivers= make -j5 On bad applying a patch and just doing make fails to update lib/gallium/radeonsi_dri.so example patch and output from make on good and bad to be attached. -- 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 84807] Build issue starting between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b and a3e9582f09249ad27716ba82c7dfcee685b65d51
https://bugs.freedesktop.org/show_bug.cgi?id=84807 --- Comment #1 from Andy Furniss adf.li...@gmail.com --- Created attachment 107565 -- https://bugs.freedesktop.org/attachment.cgi?id=107565action=edit make output on bad -- 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 84807] Build issue starting between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b and a3e9582f09249ad27716ba82c7dfcee685b65d51
https://bugs.freedesktop.org/show_bug.cgi?id=84807 --- Comment #2 from Andy Furniss adf.li...@gmail.com --- Created attachment 107566 -- https://bugs.freedesktop.org/attachment.cgi?id=107566action=edit make output on good -- 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 84807] Build issue starting between bf4aecfb2acc8d0dc815105d2f36eccbc97c284b and a3e9582f09249ad27716ba82c7dfcee685b65d51
https://bugs.freedesktop.org/show_bug.cgi?id=84807 --- Comment #3 from Andy Furniss adf.li...@gmail.com --- Here's the diff between the outputs ph4[~]$ diff mesa-build-issue-bad mesa-build-issue-good 1,2c1,3 bad a3e9582f09249ad27716ba82c7dfcee685b65d51 --- Good commit bf4aecfb2acc8d0dc815105d2f36eccbc97c284b 200a202 CXXLDgallium_dri.la 208a211 CXXLDlibvdpau_gallium.la -- 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 1/3] clover: add a simple compat::pair
EdB edb+m...@sigluy.net writes:
std::pair is not c++98/c++11 safe
---
src/gallium/state_trackers/clover/util/compat.hpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/clover/util/compat.hpp
b/src/gallium/state_trackers/clover/util/compat.hpp
index 7305577..dd20ef0 100644
--- a/src/gallium/state_trackers/clover/util/compat.hpp
+++ b/src/gallium/state_trackers/clover/util/compat.hpp
@@ -380,6 +380,12 @@ namespace clover {
mutable vectorchar v;
};
+ templateclass T1, class T2
Please use typename instead of class in template arguments for
consistency.
+ struct pair {
A default constructor would be useful here.
Other than that this looks good.
+ T1 first;
+ T2 second;
+ };
+
templatetypename T
bool
operator==(const vector_refT a, const vector_refT b) {
--
2.1.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpa20FIcLZfd.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/3] clover: add a simple compat::pair
Francisco Jerez curroje...@riseup.net writes:
EdB edb+m...@sigluy.net writes:
std::pair is not c++98/c++11 safe
---
src/gallium/state_trackers/clover/util/compat.hpp | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/state_trackers/clover/util/compat.hpp
b/src/gallium/state_trackers/clover/util/compat.hpp
index 7305577..dd20ef0 100644
--- a/src/gallium/state_trackers/clover/util/compat.hpp
+++ b/src/gallium/state_trackers/clover/util/compat.hpp
@@ -380,6 +380,12 @@ namespace clover {
mutable vectorchar v;
};
+ templateclass T1, class T2
Please use typename instead of class in template arguments for
consistency.
+ struct pair {
A default constructor would be useful here.
Hmm, or maybe a two-argument constructor initializing both members
instead, in order to make possible a small clean-up for PATCH 3 that
I'll propose in a minute.
Other than that this looks good.
+ T1 first;
+ T2 second;
+ };
+
templatetypename T
bool
operator==(const vector_refT a, const vector_refT b) {
--
2.1.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
pgpZPVJCDRLg8.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] memory leak in egl
diff --git a/src/egl/drivers/dri2/egl_dri2.c b/src/egl/drivers/dri2/egl_dri2.c index 20a7243..6b48646 100644 --- a/src/egl/drivers/dri2/egl_dri2.c +++ b/src/egl/drivers/dri2/egl_dri2.c @@ -706,6 +706,7 @@ dri2_terminate(_EGLDriver *drv, _EGLDisplay *disp) break; } + free(dri2_dpy-driver_configs); free(dri2_dpy); disp-DriverData = NULL; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/4] i965/fs: Don't interfere with too many base registers
On Tue, Oct 7, 2014 at 4:33 AM, Jason Ekstrand ja...@jlekstrand.net wrote:
On older GENs in SIMD16 mode, we were accidentally building too much
interference into our register classes. Since everything is divided by 2,
the reigster allocator thinks we have 64 base registers instead of 128.
The actual GRF mapping still needs to be doubled, but as far as the ra_set
is concerned, we only have 64. We were accidentally adding way too much
interference.
Hmm, interesting. I'm not sure I quite follow the logic yet, but I
trust you that this is the right thing. Btw, just for the lols, did
you try and run shaderdb on this change? I bet we'd allocate even more
things on SIMD16 :) The SIMD16 register allocator saga continues, I
guess...
Signed-off-by: Jason Ekstrand jason.ekstr...@gmail.com
Cc: Connor Abbot cwabbo...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index fd34941..b23ddc5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -179,8 +179,8 @@ brw_alloc_reg_set(struct intel_screen *screen, int
reg_width)
ra_reg_to_grf[reg] = j * 2;
-for (int base_reg = j * 2;
- base_reg j * 2 + class_sizes[i];
+for (int base_reg = j;
+ base_reg j + (class_sizes[i] + 1) / 2;
base_reg++) {
ra_add_transitive_reg_conflict(regs, base_reg, reg);
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84570] Borderlands 2: Constant frame rate drops while playing; really bad with additionl lighting
https://bugs.freedesktop.org/show_bug.cgi?id=84570 Kai k...@dev.carbon-project.org changed: What|Removed |Added Attachment #107502|0 |1 is obsolete|| Attachment #107503|0 |1 is obsolete|| --- Comment #13 from Kai k...@dev.carbon-project.org --- Created attachment 107574 -- https://bugs.freedesktop.org/attachment.cgi?id=107574action=edit Screenshot with GALLIUM_HUD=fps,requested-VRAM+VRAM-usage,requested-GTT+GTT-usage showing FPS drops (DynamicLights=true) Ok, with the following stack detailed at the end of this comment, the DynamicLights=false case starts to become stable. I am, however, down from the ~50 FPS during normal operations to ~42-45 FPS. The GTT usage stays 10 MB and the requested GTT size varies between a few hundred K to ~4 MB. VRAM usage is up to about 950 MB and the requested VRAM is somewhere above 520-530 MB. That said, there are still some drops FPS drops, especially, when you come around a corner (ie. lots of new stuff to draw). Or you turn really fast. But after the first turn in the general area the drops are almost gone. The non-DynamicLights case is now more or less flawless, even if I would expect a few more FPS again. The DynamicLights=True case is however still a mess. The attached screenshot was taken with the stack detailed below and DynamicLigts turned on. Again, you see the ~10 FPS drop compared to the DynamicLights=False case (what is to be expeceted, considering what Ian said in comment #1, but it still hurts, becuase ~45 FPS is not high enough for a 10 FPS drop to go by unnoticed). And in addition – even while GTT and VRAM look exactly like the non-DynamicLights case – you get the constant drops when turning, running, etc. My current stack is (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/581418585e + attachment 107542 and attachment 107543 libdrm: Git:master/00847fa48b LLVM: SVN:trunk/r219288 (3.6 devel) X.Org: 2:1.16.1-1 Linux: Git:~agd5f/linux:drm-next-3.18:369283bfbd + attachment 107451 and attachment 107544 (identifies itself as 3.17.0-rc5) Firmware: http://people.freedesktop.org/~agd5f/radeon_ucode/ 9e05820da42549ce9c89d147cf1f8e19 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_ce.bin c8bab593090fc54f239c8d7596c8d846 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_mc.bin 3618dbb955d8a84970e262bb2e6d2a16 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_me.bin c000b0fc9ff6582145f66504b0ec9597 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_mec.bin 0643ad24b3beff2214cce533e094c1b7 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_pfp.bin ba6054b7d78184a74602fd81607e1386 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_rlc.bin 11288f635737331b69de9ee82fe04898 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_sdma.bin 284429675a5560e0fad42aa982965fc2 /lib/firmware/updates/3.17.0-citadel/radeon/hawaii_smc.bin libclc: Git:master/7f6f5bff1f DDX: Git:master/xf86-video-ati-7.5.0 Let me know, if you need something else (e-mail me, if you want access to the ApiTraces). -- 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 3/4] i965/fs: Don't interfere with too many base registers
On Oct 8, 2014 11:39 AM, Connor Abbott cwabbo...@gmail.com wrote:
On Tue, Oct 7, 2014 at 4:33 AM, Jason Ekstrand ja...@jlekstrand.net
wrote:
On older GENs in SIMD16 mode, we were accidentally building too much
interference into our register classes. Since everything is divided by
2,
the reigster allocator thinks we have 64 base registers instead of 128.
The actual GRF mapping still needs to be doubled, but as far as the
ra_set
is concerned, we only have 64. We were accidentally adding way too much
interference.
Hmm, interesting. I'm not sure I quite follow the logic yet, but I
trust you that this is the right thing. Btw, just for the lols, did
you try and run shaderdb on this change? I bet we'd allocate even more
things on SIMD16 :) The SIMD16 register allocator saga continues, I
guess...
Until my desktop shows up, running shader-db is never for LOLs. It takes
20 minutes per run on my poor thermally throttled ultrabook. But yes, the
results would be amusing.
Signed-off-by: Jason Ekstrand jason.ekstr...@gmail.com
Cc: Connor Abbot cwabbo...@gmail.com
---
src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
index fd34941..b23ddc5 100644
--- a/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs_reg_allocate.cpp
@@ -179,8 +179,8 @@ brw_alloc_reg_set(struct intel_screen *screen, int
reg_width)
ra_reg_to_grf[reg] = j * 2;
-for (int base_reg = j * 2;
- base_reg j * 2 + class_sizes[i];
+for (int base_reg = j;
+ base_reg j + (class_sizes[i] + 1) / 2;
base_reg++) {
ra_add_transitive_reg_conflict(regs, base_reg, reg);
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84124] Please revert 8449121971ce1db03fea19665d314e523fdc10dd
https://bugs.freedesktop.org/show_bug.cgi?id=84124 --- Comment #4 from almos aaalmo...@gmail.com --- I've been thinking a bit about this, and I'd like to ask for an entry in the release notes about this feature change. I hope that will increase the chance that someone will eventually start working on a better implementation. A question that is somewhat related: is it possible to automatically do alpha-to-coverage for alpha-tested surfaces? When using __GL_FSAA_MODE on old games it was quite noticeable that railings and fences were not antialiased. -- You are receiving this mail because: You are the QA Contact for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] clover: Register an llvm diagnostic handler v2
Tom Stellard thomas.stell...@amd.com writes:
This will allow us to handle internal compiler errors.
v2:
- Code cleanups.
---
.../state_trackers/clover/llvm/invocation.cpp | 27
++
1 file changed, 27 insertions(+)
diff --git a/src/gallium/state_trackers/clover/llvm/invocation.cpp
b/src/gallium/state_trackers/clover/llvm/invocation.cpp
index d9c3d11..5cc0825 100644
--- a/src/gallium/state_trackers/clover/llvm/invocation.cpp
+++ b/src/gallium/state_trackers/clover/llvm/invocation.cpp
@@ -33,6 +33,8 @@
#include llvm/Linker.h
#else
#include llvm/Linker/Linker.h
+#include llvm/IR/DiagnosticInfo.h
+#include llvm/IR/DiagnosticPrinter.h
#endif
#if HAVE_LLVM 0x0303
#include llvm/DerivedTypes.h
@@ -566,6 +568,26 @@ namespace {
return m;
}
+#if HAVE_LLVM = 0x0305
+
+ void
+ diagnostic_handler(const llvm::DiagnosticInfo di, void *data) {
+ if (di.getSeverity() == llvm::DS_Error) {
+ std::string message;
+ llvm::raw_string_ostream stream(message);
+ llvm::DiagnosticPrinterRawOStream dp(stream);
+ di.print(dp);
+ stream.flush();
+ compat::string *r_log = (compat::string*)data;
+ message.insert(0, *r_log);
+ *r_log = message;
Doesn't raw_string_ostream append to the end of the string? You could
save a copy by doing it like:
| std::string message = *(compat::string *)data;
| llvm::raw_string_ostream stream(message);
|
| ...
|
| stream.flush();
| *(compat::string *)data = message;
+
+ throw build_error();
+ }
+ }
+
+#endif
+
void
init_targets() {
LLVMInitializeAllTargets();
@@ -598,6 +620,10 @@ clover::compile_program_llvm(const compat::string
source,
llvm::LLVMContext llvm_ctx;
unsigned optimization_level;
+#if HAVE_LLVM = 0x0305
+ llvm_ctx.setDiagnosticHandler(diagnostic_handler, r_log);
+#endif
+
// The input file name must have the .cl extension in order for the
// CompilerInvocation class to recognize it as an OpenCL source file.
llvm::Module *mod = compile_llvm(llvm_ctx, source, input.cl, triple,
@@ -629,5 +655,6 @@ clover::compile_program_llvm(const compat::string source,
// LLVM 3.6 and newer, the user takes ownership of the module.
delete mod;
#endif
+
return m;
}
--
1.8.5.5
pgp9vZyr0FZqZ.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 83445] eglSwapBuffers() crash on dri
https://bugs.freedesktop.org/show_bug.cgi?id=83445 --- Comment #2 from kalyank kondapallykalyancontrib...@gmail.com --- Lionel, Can you send this patch for review to mesa dev mailing list? Br, Kalyan -- 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
