[Mesa-dev] [Bug 61036] Shader fails to build in LLVMpipe, aborts program
https://bugs.freedesktop.org/show_bug.cgi?id=61036 José Fonseca jfons...@vmware.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |jfons...@vmware.com |org | CC||jfons...@vmware.com, ||srol...@vmware.com, ||za...@vmware.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 61052] New: [llvmpipe] mesa/src/gallium/auxiliary/util/u_dl.c:48: undefined reference to `dlopen'
https://bugs.freedesktop.org/show_bug.cgi?id=61052 Priority: medium Bug ID: 61052 Assignee: mesa-dev@lists.freedesktop.org Summary: [llvmpipe] mesa/src/gallium/auxiliary/util/u_dl.c:48: undefined reference to `dlopen' Severity: normal Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: dd599188d2868838541859a76800a8420958d358 (master) $ make check [...] make lp_test_format lp_test_arit lp_test_blend lp_test_conv lp_test_printf make[1]: Entering directory `mesa/src/gallium/drivers/llvmpipe' CXXLD lp_test_format /usr/lib/llvm-3.2/lib/libLLVMSupport.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::getPermanentLibrary(char const*, std::string*)': (.text+0x347): undefined reference to `dlopen' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::getPermanentLibrary(char const*, std::string*)': (.text+0x3ec): undefined reference to `dlclose' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::getPermanentLibrary(char const*, std::string*)': (.text+0x726): undefined reference to `dlerror' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(char const*)': (.text+0xb8b): undefined reference to `dlsym' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::getAddressOfSymbol(char const*)': (.text+0xa6d): undefined reference to `dlsym' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x6c): undefined reference to `dladdr' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x18f): undefined reference to `dladdr' ../../auxiliary/.libs/libgallium.a(u_dl.o): In function `util_dl_open': mesa/src/gallium/auxiliary/util/u_dl.c:48: undefined reference to `dlopen' ../../auxiliary/.libs/libgallium.a(u_dl.o): In function `util_dl_get_proc_address': mesa/src/gallium/auxiliary/util/u_dl.c:62: undefined reference to `dlsym' ../../auxiliary/.libs/libgallium.a(u_dl.o): In function `util_dl_close': mesa/src/gallium/auxiliary/util/u_dl.c:75: undefined reference to `dlclose' ../../auxiliary/.libs/libgallium.a(u_dl.o): In function `util_dl_error': mesa/src/gallium/auxiliary/util/u_dl.c:88: undefined reference to `dlerror' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(Mutex.o): In function `llvm::sys::MutexImpl::MutexImpl(bool)': (.text+0x41): undefined reference to `pthread_mutexattr_init' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(Mutex.o): In function `llvm::sys::MutexImpl::MutexImpl(bool)': (.text+0x4d): undefined reference to `pthread_mutexattr_settype' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(Mutex.o): In function `llvm::sys::MutexImpl::MutexImpl(bool)': (.text+0x57): undefined reference to `pthread_mutexattr_setpshared' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(Mutex.o): In function `llvm::sys::MutexImpl::MutexImpl(bool)': (.text+0x6a): undefined reference to `pthread_mutexattr_destroy' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(Mutex.o): In function `llvm::sys::MutexImpl::tryacquire()': (.text+0x108): undefined reference to `pthread_mutex_trylock' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(RWMutex.o): In function `llvm::sys::RWMutexImpl::RWMutexImpl()': (.text+0x2b): undefined reference to `pthread_rwlock_init' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(RWMutex.o): In function `llvm::sys::RWMutexImpl::~RWMutexImpl()': (.text+0x58): undefined reference to `pthread_rwlock_destroy' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(RWMutex.o): In function `llvm::sys::RWMutexImpl::reader_acquire()': (.text+0x78): undefined reference to `pthread_rwlock_rdlock' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(RWMutex.o): In function `llvm::sys::RWMutexImpl::reader_release()': (.text+0x98): undefined reference to `pthread_rwlock_unlock' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(RWMutex.o): In function `llvm::sys::RWMutexImpl::writer_acquire()': (.text+0xb8): undefined reference to `pthread_rwlock_wrlock' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(RWMutex.o): In function `llvm::sys::RWMutexImpl::writer_release()': (.text+0xd8): undefined reference to `pthread_rwlock_unlock' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(ThreadLocal.o): In function `llvm::sys::ThreadLocalImpl::~ThreadLocalImpl()': (.text+0x12): undefined reference to `pthread_key_delete' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(ThreadLocal.o): In function `llvm::sys::ThreadLocalImpl::ThreadLocalImpl()': (.text+0x6f): undefined reference to `pthread_key_create' /usr/lib/llvm-3.2/lib/libLLVMSupport.a(ThreadLocal.o): In function `llvm::sys::ThreadLocalImpl::setInstance(void const*)': (.text+0x84): undefined reference to `pthread_setspecific'
[Mesa-dev] Need bench mark application for Opengles2 on mesa-8.0.4 with Linux
Hi, Can you please let us know is there any benchmark tool for opengles2 API's in Linux and Windows. Thanks and Regards, Ramesh CAUTION - Disclaimer * This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS End of Disclaimer INFOSYS*** ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: status of my work on the shader optimization
Stefan Seifert wrote: Hi! Amazing work! I see some 50 % speed ups in FlightGear and even more. While normally 3D clouds tear performance down to an unflyable stutter, with your branch I can fly in densly clouded conditions at usable framerates. I can now turn all shaders to maximum and enjoy the view. This makes a huge difference. Unfortunately there's a downside as well: Testing with rv790 with drm-fixes kernel not much works - etqw runs but in a level 50% of screen is junk. nexuiz menus total junk, didn't test further. xonotic menus OK but gpu lock on starting timedemo. vdpau mpeg2 decode - renders 90% junk. heaven 3.0 (on a different pure 64 bit setup) gpu lock. Unrelated question wtr heaven 3.0 - does it work properly anyway? For me running 64bit on rv790 with vanilla mesa with or without llvm I have to set shaders to medium, on high it works but I get no lighting/effects. There are also a couple of scenes that render as flared out black and white. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: status of my work on the shader optimization
Well, the branch was said to work with EG. For HD4000, probably further work is needed. On Mon, Feb 18, 2013 at 12:20 PM, Andy Furniss andy...@ukfsn.org wrote: Stefan Seifert wrote: Hi! Amazing work! I see some 50 % speed ups in FlightGear and even more. While normally 3D clouds tear performance down to an unflyable stutter, with your branch I can fly in densly clouded conditions at usable framerates. I can now turn all shaders to maximum and enjoy the view. This makes a huge difference. Unfortunately there's a downside as well: Testing with rv790 with drm-fixes kernel not much works - etqw runs but in a level 50% of screen is junk. nexuiz menus total junk, didn't test further. xonotic menus OK but gpu lock on starting timedemo. vdpau mpeg2 decode - renders 90% junk. heaven 3.0 (on a different pure 64 bit setup) gpu lock. Unrelated question wtr heaven 3.0 - does it work properly anyway? For me running 64bit on rv790 with vanilla mesa with or without llvm I have to set shaders to medium, on high it works but I get no lighting/effects. There are also a couple of scenes that render as flared out black and white. __**_ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/**mailman/listinfo/mesa-devhttp://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61052] [llvmpipe] mesa/src/gallium/auxiliary/util/u_dl.c:48: undefined reference to `dlopen'
https://bugs.freedesktop.org/show_bug.cgi?id=61052 José Fonseca jfons...@vmware.com changed: What|Removed |Added CC||jfons...@vmware.com --- Comment #1 from José Fonseca jfons...@vmware.com --- autotools build needs to add -ldl on all gallium targets. -- 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 59876] glGetTexLevelParameteriv broken for indirect rendering
https://bugs.freedesktop.org/show_bug.cgi?id=59876 --- Comment #5 from Stefan Brüns stefan.bru...@rwth-aachen.de --- Can *anyonye* act on this, please? The bug is obvious and the fix is trivial ... -- 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] r600g: status of my work on the shader optimization
On 02/18/2013 02:20 PM, Andy Furniss wrote: Stefan Seifert wrote: Hi! Amazing work! I see some 50 % speed ups in FlightGear and even more. While normally 3D clouds tear performance down to an unflyable stutter, with your branch I can fly in densly clouded conditions at usable framerates. I can now turn all shaders to maximum and enjoy the view. This makes a huge difference. Unfortunately there's a downside as well: Testing with rv790 with drm-fixes kernel not much works - It's an expected result for now. I have the evergreen card only, so the branch wasn't tested with the non-evergreen chips at all. It will require some fixes to handle the hardware differences between chip generations. I'll try to make sure that all differences are taken into account. etqw runs but in a level 50% of screen is junk. nexuiz menus total junk, didn't test further. xonotic menus OK but gpu lock on starting timedemo. vdpau mpeg2 decode - renders 90% junk. heaven 3.0 (on a different pure 64 bit setup) gpu lock. Unrelated question wtr heaven 3.0 - does it work properly anyway? For me running 64bit on rv790 with vanilla mesa with or without llvm I have to set shaders to medium, on high it works but I get no lighting/effects. There are also a couple of scenes that render as flared out black and white. Unigine engine has known compatibility problems with mesa, so it requires some workarounds. I use the following environment variables: MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding force_glsl_extensions_warn=true With these settings the rendering seems correct on evergreen with all Unigine demos. I don't know if it works with the non-evergreen chips though. Vadim ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61003] gluSurface with Nurbs spits out C code arc_ccw_turn...
https://bugs.freedesktop.org/show_bug.cgi?id=61003 Blaž Hrastnik speed.the.b...@gmail.com changed: What|Removed |Added CC||speed.the.b...@gmail.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] gles2: a stub implementation for GL_EXT_discard_framebuffer
On 02/18/2013 12:12 AM, Tapani Pälli wrote:
This patch implements a stub for GL_EXT_discard_framebuffer with
required checks listed by the extension specification. This extension
is required by GLBenchmark 2.5 when compiled with OpenGL ES 2.0
as the rendering backend.
Signed-off-by: Tapani Pällitapani.pa...@intel.com
---
src/mapi/glapi/gen/es_EXT.xml | 13
src/mesa/drivers/common/driverfuncs.c | 1 +
src/mesa/main/dd.h | 4 ++-
src/mesa/main/extensions.c | 1 +
src/mesa/main/fbobject.c| 54 +
src/mesa/main/fbobject.h| 4 +++
src/mesa/main/tests/dispatch_sanity.cpp | 2 ++
7 files changed, 78 insertions(+), 1 deletion(-)
Just a couple very minor nits.
+void GLAPIENTRY
+_mesa_DiscardFramebufferEXT(GLenum target, GLsizei numAttachments,
+const GLenum *attachments)
+{
+ struct gl_framebuffer *fb;
+ GLint i;
+
+ GET_CURRENT_CONTEXT(ctx);
+
+ fb = get_framebuffer_target(ctx, target);
+ if (!fb) {
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ glDiscardFramebufferEXT(target %s),
+ _mesa_lookup_enum_by_nr(target));
+ return;
+ }
+
+ if (numAttachments 0) {
+ _mesa_error(ctx, GL_INVALID_VALUE,
+ glDiscardFramebufferEXT(numAttachments 0));
+ return;
+ }
+
+ for(i = 0; i numAttachments; i++) {
+
Please put a space in for ( and you can remove the blank line
between 'for' and 'switch'.
+ switch (attachments[i]) {
+ case GL_COLOR:
+ case GL_DEPTH:
+ case GL_STENCIL:
+ if (_mesa_is_user_fbo(fb))
+goto invalid_enum;
+ break;
+ case GL_COLOR_ATTACHMENT0:
+ case GL_DEPTH_ATTACHMENT:
+ case GL_STENCIL_ATTACHMENT:
+ if (_mesa_is_winsys_fbo(fb))
+goto invalid_enum;
+ break;
+ default:
+ goto invalid_enum;
+ }
+ }
+
+ if (ctx-Driver.DiscardFramebuffer)
+ ctx-Driver.DiscardFramebuffer(ctx, target, numAttachments, attachments);
+
+ return;
+
+invalid_enum:
+ _mesa_error(ctx, GL_INVALID_ENUM,
+ glDiscardFramebufferEXT(attachment %s),
+ _mesa_lookup_enum_by_nr(attachments[i]));
+}
Looks good otherwise.
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61026] Segfault in glBitmap when called with PBO source
https://bugs.freedesktop.org/show_bug.cgi?id=61026 --- Comment #3 from Brian Paul bri...@vmware.com --- OK, I've found/fixed the problem. Your patch was incorrect. And your test program has a few bugs too (I'll attach a fixed version). After the patch has been reviewed I'll commit it. Thanks for the test program! -- 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 61026] Segfault in glBitmap when called with PBO source
https://bugs.freedesktop.org/show_bug.cgi?id=61026 --- Comment #4 from Brian Paul bri...@vmware.com --- Created attachment 75047 -- https://bugs.freedesktop.org/attachment.cgi?id=75047action=edit Fixed test program. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: implement glBitmap unpacking from a PBO, for the cache path
We weren't mapping the PBO when using the bitmap cache (but we had
the PBO code for the non-cache path.)
Fixes ttps://bugs.freedesktop.org/show_bug.cgi?id=61026
Note: This is a candidate for the stable branches.
---
src/mesa/state_tracker/st_cb_bitmap.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_cb_bitmap.c
b/src/mesa/state_tracker/st_cb_bitmap.c
index 63dbdb2..36fffe9 100644
--- a/src/mesa/state_tracker/st_cb_bitmap.c
+++ b/src/mesa/state_tracker/st_cb_bitmap.c
@@ -675,11 +675,12 @@ st_flush_bitmap_cache(struct st_context *st)
* \return GL_TRUE for success, GL_FALSE if bitmap is too large, etc.
*/
static GLboolean
-accum_bitmap(struct st_context *st,
+accum_bitmap(struct gl_context *ctx,
GLint x, GLint y, GLsizei width, GLsizei height,
const struct gl_pixelstore_attrib *unpack,
const GLubyte *bitmap )
{
+ struct st_context *st = ctx-st;
struct bitmap_cache *cache = st-bitmap.cache;
int px = -999, py = -999;
const GLfloat z = st-ctx-Current.RasterPos[2];
@@ -729,9 +730,17 @@ accum_bitmap(struct st_context *st,
/* create the transfer if needed */
create_cache_trans(st);
+ /* PBO source... */
+ bitmap = _mesa_map_pbo_source(ctx, unpack, bitmap);
+ if (!bitmap) {
+ return FALSE;
+ }
+
unpack_bitmap(st, px, py, width, height, unpack, bitmap,
cache-buffer, BITMAP_CACHE_WIDTH);
+ _mesa_unmap_pbo_source(ctx, unpack);
+
return GL_TRUE; /* accumulated */
}
@@ -764,7 +773,7 @@ st_Bitmap(struct gl_context *ctx, GLint x, GLint y,
semantic_indexes);
}
- if (UseBitmapCache accum_bitmap(st, x, y, width, height, unpack, bitmap))
+ if (UseBitmapCache accum_bitmap(ctx, x, y, width, height, unpack,
bitmap))
return;
pt = make_bitmap_texture(ctx, width, height, unpack, bitmap);
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/3] mesa: helper for checking renderbuffer sample count
On 02/17/2013 03:35 AM, Chris Forbes wrote:
Pulls the checking of the sample count into a helper function, and
extends the existing logic to include the interactions with both
ARB_texture_multisample and ARB_internalformat_query.
_mesa_check_sample_count() checks a desired sample count against a
a combination of target/internalformat, and returns the error enum
to be produced, if any. Unfortunately the conditions are messy and the
errors vary:
On p205 of the GL3.1 spec:
... or if samples is greater than MAX_SAMPLES, then the error
INVALID_VALUE is generated.
Or with ARB_texture_multisample (or GL3.2):
... or ifsamples is greater than the value of MAX_SAMPLES, then
the error INVALID_VALUE is generated.
Ifinternalformat is a signed or unsigned integer format and
samples is greater than the value of MAX_INTEGER_SAMPLES, then the
error INVALID_OPERATION is generated.
Or with ARB_internalformat_query (or GL4.2):
Ifsamples is greater than the maximum number of samples supported
forinternalformat then the error INVALID_OPERATION is generated
(see GetInternalformativ in section 6.X).
Signed-off-by: Chris Forbeschr...@ijw.co.nz
---
src/mesa/main/fbobject.c | 43 +++
src/mesa/main/fbobject.h | 4
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index c89e728..50339c2 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1449,6 +1449,35 @@ invalidate_rb(GLuint key, void *data, void *userData)
}
There should be a comment on this function explaining what it does and
what it returns.
+GLenum
+_mesa_check_sample_count(struct gl_context *ctx, GLenum target,
+ GLenum internalFormat, GLsizei samples)
Can ctx be const-qualified? It looks like the context shouldn't be
changed by this function.
+{
+ /* If ARB_internalformat_query is supported, then treat its highest
returned sample
+* count as the absolute maximum for this format; it is allowed to exceed
MAX_SAMPLES.
+*/
+ if (ctx-Extensions.ARB_internalformat_query) {
+ GLint buffer[16];
+ int count = ctx-Driver.QuerySamplesForFormat(ctx, target,
internalFormat, buffer);
+ int limit = count ? buffer[0] : -1;
+
+ return (samples limit) ? GL_INVALID_OPERATION : GL_NO_ERROR;
+ }
+
+ /* If ARB_texture_multisample is supported, we have separate limits for
+* integer formats.
+*/
+
+ if (ctx-Extensions.ARB_texture_multisample) {
+ if (_mesa_is_enum_format_integer(internalFormat))
+ return samples ctx-Const.MaxIntegerSamples ? GL_INVALID_OPERATION
: GL_NO_ERROR;
+ }
+
+ /* No more specific limit is available, so just use MAX_SAMPLES */
+ return samples ctx-Const.MaxSamples ? GL_INVALID_VALUE : GL_NO_ERROR;
+}
+
+
/** sentinal value, see below */
#define NO_SAMPLES 1000
@@ -1509,10 +1538,16 @@ renderbuffer_storage(GLenum target, GLenum
internalFormat,
/* NumSamples == 0 indicates non-multisampling */
samples = 0;
}
- else if (samples (GLsizei) ctx-Const.MaxSamples) {
- /* note: driver may choose to use more samples than what's requested */
- _mesa_error(ctx, GL_INVALID_VALUE, %s(samples), func);
- return;
+
+ { /* check the sample count;
+ * note: driver may choose to use more samples than what's requested
+ */
+ GLenum sample_count_error = _mesa_check_sample_count(ctx, target,
+internalFormat, samples);
+ if (sample_count_error != GL_NO_ERROR) {
+ _mesa_error(ctx, sample_count_error, %s(samples), func);
+ return;
+ }
Minor style nit: I'd simply declare sample_count_error at the top of
the function and get rid of the {}-block.
}
rb = ctx-CurrentRenderbuffer;
diff --git a/src/mesa/main/fbobject.h b/src/mesa/main/fbobject.h
index 9207f59..9adee3a 100644
--- a/src/mesa/main/fbobject.h
+++ b/src/mesa/main/fbobject.h
@@ -123,6 +123,10 @@ _mesa_is_legal_color_format(const struct gl_context *ctx,
GLenum baseFormat);
extern GLenum
_mesa_base_fbo_format(struct gl_context *ctx, GLenum internalFormat);
+extern GLenum
+_mesa_check_sample_count(struct gl_context *ctx, GLenum target,
+ GLenum internalFormat, GLsizei samples);
+
extern GLboolean GLAPIENTRY
_mesa_IsRenderbuffer(GLuint renderbuffer);
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] mesa: use _mesa_check_sample_count() for multisample textures
On 02/17/2013 03:35 AM, Chris Forbes wrote:
Extends _mesa_check_sample_count() to properly support the
TEXTURE_2D_MULTISAMPLE and TEXTURE_2D_MULTISAMPLE_ARRAY targets, which
have subtly different limits than renderbuffers:
The ARB_texture_multisample spec (or GL3.2) says, when describing the
operation of TexImage*DMultisample:
The error INVALID_OPERATION may be generated if any of the following
are true:
*internalformat is a depth/stencil-renderable format andsamples
is greater than the value of MAX_DEPTH_TEXTURE_SAMPLES
*internalformat is a color-renderable format andsamples is
greater than the value of MAX_COLOR_TEXTURE_SAMPLES
*internalformat is a signed or unsigned integer format and
samples is greater than the value of MAX_INTEGER_SAMPLES
And additionally, slightly later:
... or ifsamples is greater than MAX_SAMPLES, then the error
INVALID_VALUE is generated.
If ARB_internalformat_query (or GL4.2) is supported, all of these limits
are replaced by:
The error INVALID_OPERATION will be generated ifsamples is
greater than the maximum number of samples supported for this
target andinternalformat, which can be determined by calling
GetInternalformativ with apname of SAMPLES (see section 6.X).
Shouldn't spec quotes like that go into the code instead for future
reference?
This resolves the remaining TODO in the implementation of
TexImage*DMultisample.
Signed-off-by: Chris Forbeschr...@ijw.co.nz
---
src/mesa/main/fbobject.c | 11 +++
src/mesa/main/teximage.c | 30 +-
2 files changed, 16 insertions(+), 25 deletions(-)
diff --git a/src/mesa/main/fbobject.c b/src/mesa/main/fbobject.c
index 50339c2..208cf0d 100644
--- a/src/mesa/main/fbobject.c
+++ b/src/mesa/main/fbobject.c
@@ -1471,6 +1471,17 @@ _mesa_check_sample_count(struct gl_context *ctx, GLenum
target,
if (ctx-Extensions.ARB_texture_multisample) {
if (_mesa_is_enum_format_integer(internalFormat))
return samples ctx-Const.MaxIntegerSamples ? GL_INVALID_OPERATION
: GL_NO_ERROR;
+
+ if (target == GL_TEXTURE_2D_MULTISAMPLE ||
+ target == GL_TEXTURE_2D_MULTISAMPLE_ARRAY) {
+
+ if (_mesa_is_depth_or_stencil_format(internalFormat))
+return samples ctx-Const.MaxDepthTextureSamples
+ ? GL_INVALID_OPERATION : GL_NO_ERROR;
+ else
+return samples ctx-Const.MaxColorTextureSamples
+ ? GL_INVALID_OPERATION : GL_NO_ERROR;
+ }
}
/* No more specific limit is available, so just use MAX_SAMPLES */
diff --git a/src/mesa/main/teximage.c b/src/mesa/main/teximage.c
index dc9543f..edf0a4c 100644
--- a/src/mesa/main/teximage.c
+++ b/src/mesa/main/teximage.c
@@ -4216,35 +4216,15 @@ teximagemultisample(GLuint dims, GLenum target, GLsizei
samples,
return;
}
- if (_mesa_is_enum_format_integer(internalformat)) {
- if (samples ctx-Const.MaxIntegerSamples) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
- glTexImage%uDMultisample(samplesGL_MAX_INTEGER_SAMPLES),
- dims);
- return;
- }
- }
- else if (_mesa_is_depth_or_stencil_format(internalformat)) {
- if (samples ctx-Const.MaxDepthTextureSamples) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
-
glTexImage%uDMultisample(samplesGL_MAX_DEPTH_TEXTURE_SAMPLES),
- dims);
- return;
- }
- }
- else {
- if (samples ctx-Const.MaxColorTextureSamples) {
- _mesa_error(ctx, GL_INVALID_OPERATION,
-
glTexImage%uDMultisample(samplesGL_MAX_COLOR_TEXTURE_SAMPLES),
- dims);
+ {
+ GLenum sample_count_error = _mesa_check_sample_count(ctx, target,
+internalformat, samples);
+ if (sample_count_error != GL_NO_ERROR) {
+ _mesa_error(ctx, sample_count_error,
glTexImage%uMultisample(samples), dims);
return;
}
}
- /* TODO: should ask the driver for the exact limit for this internalformat
-* once IDR's internalformat_query bits land
-*/
-
texObj = _mesa_get_current_tex_object(ctx, target);
texImage = _mesa_get_tex_image(ctx, texObj, 0, 0);
Other than my nits, looks good!
Reviewed-by: Brian Paul bri...@vmware.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] r600g: status of my work on the shader optimization
Vadim Girlin wrote: Unrelated question wtr heaven 3.0 - does it work properly anyway? For me running 64bit on rv790 with vanilla mesa with or without llvm I have to set shaders to medium, on high it works but I get no lighting/effects. There are also a couple of scenes that render as flared out black and white. Unigine engine has known compatibility problems with mesa, so it requires some workarounds. I use the following environment variables: MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding force_glsl_extensions_warn=true With these settings the rendering seems correct on evergreen with all Unigine demos. I don't know if it works with the non-evergreen chips though. Thanks, with those both issues are fixed. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/6] R600: Use MUL_IEEE for trig/fdiv intrinsic
---
lib/Target/R600/R600Instructions.td | 8
test/CodeGen/R600/fdiv.v4f32.ll | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index 0a01400..e4cc06e 100644
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@@ -1090,12 +1090,12 @@ class COS_Common bits11 inst : R600_1OP
multiclass DIV_Common InstR600 recip_ieee {
def : Pat
(int_AMDGPU_div R600_Reg32:$src0, R600_Reg32:$src1),
- (MUL R600_Reg32:$src0, (recip_ieee R600_Reg32:$src1))
+ (MUL_IEEE R600_Reg32:$src0, (recip_ieee R600_Reg32:$src1))
;
def : Pat
(fdiv R600_Reg32:$src0, R600_Reg32:$src1),
- (MUL R600_Reg32:$src0, (recip_ieee R600_Reg32:$src1))
+ (MUL_IEEE R600_Reg32:$src0, (recip_ieee R600_Reg32:$src1))
;
}
@@ -1169,12 +1169,12 @@ let Predicates = [isR600] in {
// cards.
class COS_PAT InstR600 trig : Pat
(fcos R600_Reg32:$src),
- (trig (MUL (MOV_IMM_I32 CONST.TWO_PI_INV), R600_Reg32:$src))
+ (trig (MUL_IEEE (MOV_IMM_I32 CONST.TWO_PI_INV), R600_Reg32:$src))
;
class SIN_PAT InstR600 trig : Pat
(fsin R600_Reg32:$src),
- (trig (MUL (MOV_IMM_I32 CONST.TWO_PI_INV), R600_Reg32:$src))
+ (trig (MUL_IEEE (MOV_IMM_I32 CONST.TWO_PI_INV), R600_Reg32:$src))
;
//===--===//
diff --git a/test/CodeGen/R600/fdiv.v4f32.ll b/test/CodeGen/R600/fdiv.v4f32.ll
index b013fd6..459fd11 100644
--- a/test/CodeGen/R600/fdiv.v4f32.ll
+++ b/test/CodeGen/R600/fdiv.v4f32.ll
@@ -1,13 +1,13 @@
;RUN: llc %s -march=r600 -mcpu=redwood | FileCheck %s
;CHECK: RECIP_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
-;CHECK: MUL NON-IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: MUL_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
;CHECK: RECIP_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
-;CHECK: MUL NON-IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: MUL_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
;CHECK: RECIP_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
-;CHECK: MUL NON-IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: MUL_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
;CHECK: RECIP_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
-;CHECK: MUL NON-IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
+;CHECK: MUL_IEEE T{{[0-9]+\.[XYZW], T[0-9]+\.[XYZW], T[0-9]+\.[XYZW]}}
define void @test(4 x float addrspace(1)* %out, 4 x float addrspace(1)*
%in) {
%b_ptr = getelementptr 4 x float addrspace(1)* %in, i32 1
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/6] R600: CONST_ADDRESS node is not marked as mayLoad anymore
mayLoad complexify scheduling and does not bring any usefull info as the location is not writeable at all. --- lib/Target/R600/R600Instructions.td | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Target/R600/R600Instructions.td b/lib/Target/R600/R600Instructions.td index e4cc06e..0a777f1 100644 --- a/lib/Target/R600/R600Instructions.td +++ b/lib/Target/R600/R600Instructions.td @@ -513,7 +513,7 @@ def INTERP_PAIR_ZW : AMDGPUShaderInst def CONST_ADDRESS: SDNodeAMDGPUISD::CONST_ADDRESS, SDTypeProfile1, -1, [SDTCisInt0, SDTCisPtrTy1], - [SDNPMayLoad, SDNPVariadic] + [SDNPVariadic] ; //===--===// -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 3/6] R600: Turn BUILD_VECTOR into Reg_Sequence
---
lib/Target/R600/AMDILISelDAGToDAG.cpp | 29 +
1 file changed, 29 insertions(+)
diff --git a/lib/Target/R600/AMDILISelDAGToDAG.cpp
b/lib/Target/R600/AMDILISelDAGToDAG.cpp
index 2e726e9..6b24117 100644
--- a/lib/Target/R600/AMDILISelDAGToDAG.cpp
+++ b/lib/Target/R600/AMDILISelDAGToDAG.cpp
@@ -160,6 +160,35 @@ SDNode *AMDGPUDAGToDAGISel::Select(SDNode *N) {
}
switch (Opc) {
default: break;
+ case ISD::BUILD_VECTOR: {
+const AMDGPUSubtarget ST = TM.getSubtargetAMDGPUSubtarget();
+if (ST.device()-getGeneration() AMDGPUDeviceInfo::HD6XXX) {
+ break;
+}
+// BUILD_VECTOR is usually lowered into an IMPLICIT_DEF + 4 INSERT_SUBREG
+// that adds a 128 bits reg copy when going through TwoAddressInstructions
+// pass. We want to avoid 128 bits copies as much as possible because they
+// can't be bundled by our scheduler.
+SDValue RegSeqArgs[9] = {
+ CurDAG-getTargetConstant(AMDGPU::R600_Reg128RegClassID, MVT::i32),
+ SDValue(), CurDAG-getTargetConstant(AMDGPU::sub0, MVT::i32),
+ SDValue(), CurDAG-getTargetConstant(AMDGPU::sub1, MVT::i32),
+ SDValue(), CurDAG-getTargetConstant(AMDGPU::sub2, MVT::i32),
+ SDValue(), CurDAG-getTargetConstant(AMDGPU::sub3, MVT::i32)
+};
+bool IsRegSeq = true;
+for (unsigned i = 0; i N-getNumOperands(); i++) {
+ if (dyn_castRegisterSDNode(N-getOperand(i))) {
+IsRegSeq = false;
+break;
+ }
+ RegSeqArgs[2 * i + 1] = N-getOperand(i);
+}
+if (!IsRegSeq)
+ break;
+return CurDAG-SelectNodeTo(N, AMDGPU::REG_SEQUENCE, N-getVTList(),
+RegSeqArgs, 2 * N-getNumOperands() + 1);
+ }
case ISD::ConstantFP:
case ISD::Constant: {
const AMDGPUSubtarget ST = TM.getSubtargetAMDGPUSubtarget();
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 4/6] R600: Fix for Unigine when MachineSched is enabled
---
lib/Target/R600/R600Instructions.td | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index 0a777f1..74106c9 100644
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@@ -1587,6 +1587,7 @@ def PRED_X : InstR600
(ins R600_Reg32:$src0, i32imm:$src1, i32imm:$flags),
, [], NullALU {
let FlagOperandIdx = 3;
+ let isTerminator = 1;
}
let isTerminator = 1, isBranch = 1, isBarrier = 1 in {
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 5/6] R600: Remove LowerConstCopyPass and lower CONST_COPY right after ISel.
Maintaining CONST_COPY Instructions until Pre Emit may prevent some ifcvt case
and taking them in account for scheduling is difficult for no real benefit.
---
lib/Target/R600/AMDGPU.h| 1 -
lib/Target/R600/AMDGPUTargetMachine.cpp | 1 -
lib/Target/R600/R600ISelLowering.cpp| 8 +-
lib/Target/R600/R600Instructions.td | 7 +-
lib/Target/R600/R600LowerConstCopy.cpp | 222
5 files changed, 11 insertions(+), 228 deletions(-)
delete mode 100644 lib/Target/R600/R600LowerConstCopy.cpp
diff --git a/lib/Target/R600/AMDGPU.h b/lib/Target/R600/AMDGPU.h
index ba87918..67073ab 100644
--- a/lib/Target/R600/AMDGPU.h
+++ b/lib/Target/R600/AMDGPU.h
@@ -23,7 +23,6 @@ class AMDGPUTargetMachine;
// R600 Passes
FunctionPass* createR600KernelParametersPass(const DataLayout *TD);
FunctionPass *createR600ExpandSpecialInstrsPass(TargetMachine tm);
-FunctionPass *createR600LowerConstCopy(TargetMachine tm);
// SI Passes
FunctionPass *createSIAnnotateControlFlowPass();
diff --git a/lib/Target/R600/AMDGPUTargetMachine.cpp
b/lib/Target/R600/AMDGPUTargetMachine.cpp
index e2f00be..70b34b0 100644
--- a/lib/Target/R600/AMDGPUTargetMachine.cpp
+++ b/lib/Target/R600/AMDGPUTargetMachine.cpp
@@ -143,7 +143,6 @@ bool AMDGPUPassConfig::addPreEmitPass() {
addPass(createAMDGPUCFGStructurizerPass(*TM));
addPass(createR600ExpandSpecialInstrsPass(*TM));
addPass(FinalizeMachineBundlesID);
-addPass(createR600LowerConstCopy(*TM));
} else {
addPass(createSILowerControlFlowPass(*TM));
}
diff --git a/lib/Target/R600/R600ISelLowering.cpp
b/lib/Target/R600/R600ISelLowering.cpp
index ece0b9a..f25ced1 100644
--- a/lib/Target/R600/R600ISelLowering.cpp
+++ b/lib/Target/R600/R600ISelLowering.cpp
@@ -150,7 +150,13 @@ MachineBasicBlock *
R600TargetLowering::EmitInstrWithCustomInserter(
TII-buildMovImm(*BB, I, MI-getOperand(0).getReg(),
MI-getOperand(1).getImm());
break;
-
+ case AMDGPU::CONST_COPY: {
+MachineInstr *NewMI = TII-buildDefaultInstruction(*BB, MI, AMDGPU::MOV,
+MI-getOperand(0).getReg(), AMDGPU::ALU_CONST);
+TII-setImmOperand(NewMI, R600Operands::SRC0_SEL,
+MI-getOperand(1).getImm());
+break;
+ }
case AMDGPU::RAT_WRITE_CACHELESS_32_eg:
case AMDGPU::RAT_WRITE_CACHELESS_128_eg: {
diff --git a/lib/Target/R600/R600Instructions.td
b/lib/Target/R600/R600Instructions.td
index 74106c9..10bcdcf 100644
--- a/lib/Target/R600/R600Instructions.td
+++ b/lib/Target/R600/R600Instructions.td
@@ -1650,17 +1650,18 @@ let isTerminator = 1, isReturn = 1, isBarrier = 1,
hasCtrlDep = 1,
// Constant Buffer Addressing Support
//===--===//
-let isCodeGenOnly = 1, isPseudo = 1, Namespace = AMDGPU in {
+let usesCustomInserter = 1, isCodeGenOnly = 1, isPseudo = 1, Namespace =
AMDGPU in {
def CONST_COPY : Instruction {
let OutOperandList = (outs R600_Reg32:$dst);
let InOperandList = (ins i32imm:$src);
- let Pattern = [(set R600_Reg32:$dst, (CONST_ADDRESS
ADDRGA_CONST_OFFSET:$src))];
+ let Pattern =
+ [(set R600_Reg32:$dst, (CONST_ADDRESS ADDRGA_CONST_OFFSET:$src))];
let AsmString = CONST_COPY;
let neverHasSideEffects = 1;
let isAsCheapAsAMove = 1;
let Itinerary = NullALU;
}
-} // end isCodeGenOnly = 1, isPseudo = 1, Namespace = AMDGPU
+} // end usesCustomInserter = 1, isCodeGenOnly = 1, isPseudo = 1, Namespace =
AMDGPU
def TEX_VTX_CONSTBUF :
InstR600ISA (outs R600_Reg128:$dst), (ins MEMxi:$ptr, i32imm:$BUFFER_ID),
VTX_READ_eg $dst, $ptr,
diff --git a/lib/Target/R600/R600LowerConstCopy.cpp
b/lib/Target/R600/R600LowerConstCopy.cpp
deleted file mode 100644
index 3ebe653..000
--- a/lib/Target/R600/R600LowerConstCopy.cpp
+++ /dev/null
@@ -1,222 +0,0 @@
-//===-- R600LowerConstCopy.cpp - Propagate ConstCopy / lower them to
MOV---===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-/// \file
-/// This pass is intended to handle remaining ConstCopy pseudo MachineInstr.
-/// ISel will fold each Const Buffer read inside scalar ALU. However it cannot
-/// fold them inside vector instruction, like DOT4 or Cube ; ISel emits
-/// ConstCopy instead. This pass (executed after ExpandingSpecialInstr) will
try
-/// to fold them if possible or replace them by MOV otherwise.
-//
-//===--===//
-
-#include AMDGPU.h
-#include R600InstrInfo.h
-#include llvm/CodeGen/MachineFunction.h
-#include llvm/CodeGen/MachineFunctionPass.h
-#include llvm/CodeGen/MachineInstrBuilder.h
-#include llvm/IR/GlobalValue.h
-
-namespace llvm {
-
-class R600LowerConstCopy : public MachineFunctionPass {
-private:
- static char ID;
- const
[Mesa-dev] [PATCH 6/6] R600: initial scheduler code
From: Vadim Girlin vadimgir...@gmail.com
This is a skeleton for a pre-RA MachineInstr scheduler strategy. Currently
it only tries to expose more parallelism for ALU instructions (this also
makes the distribution of GPR channels more uniform and increases the
chances of ALU instructions to be packed together in a single VLIW group).
Also it tries to reduce clause switching by grouping instruction of the
same kind (ALU/FETCH/CF) together.
Vincent Lejeune:
- Support for VLIW4 Slot assignement
- Recomputation of ScheduleDAG to get more parallelism opportunities
Tom Stellard:
- Fix assertion failure when trying to determine an instruction's slot
based on its destination register's class
- Fix some compiler warnings
Vincent Lejeune: [v2]
- Remove recomputation of ScheduleDAG (will be provided in a later patch)
- Improve estimation of an ALU clause size so that heuristic does not emit cf
instructions at the wrong position.
- Make schedule heuristic smarter using SUnit Depth
- Take constant read limitations into account
---
lib/Target/R600/AMDGPUTargetMachine.cpp | 17 +-
lib/Target/R600/R600MachineScheduler.cpp | 483 +++
lib/Target/R600/R600MachineScheduler.h | 121
test/CodeGen/R600/fdiv.v4f32.ll | 6 +-
4 files changed, 623 insertions(+), 4 deletions(-)
create mode 100644 lib/Target/R600/R600MachineScheduler.cpp
create mode 100644 lib/Target/R600/R600MachineScheduler.h
diff --git a/lib/Target/R600/AMDGPUTargetMachine.cpp
b/lib/Target/R600/AMDGPUTargetMachine.cpp
index 70b34b0..eb58853 100644
--- a/lib/Target/R600/AMDGPUTargetMachine.cpp
+++ b/lib/Target/R600/AMDGPUTargetMachine.cpp
@@ -17,6 +17,7 @@
#include AMDGPU.h
#include R600ISelLowering.h
#include R600InstrInfo.h
+#include R600MachineScheduler.h
#include SIISelLowering.h
#include SIInstrInfo.h
#include llvm/Analysis/Passes.h
@@ -39,6 +40,14 @@ extern C void LLVMInitializeR600Target() {
RegisterTargetMachineAMDGPUTargetMachine X(TheAMDGPUTarget);
}
+static ScheduleDAGInstrs *createR600MachineScheduler(MachineSchedContext *C) {
+ return new ScheduleDAGMI(C, new R600SchedStrategy());
+}
+
+static MachineSchedRegistry
+SchedCustomRegistry(r600, Run R600's custom scheduler,
+createR600MachineScheduler);
+
AMDGPUTargetMachine::AMDGPUTargetMachine(const Target T, StringRef TT,
StringRef CPU, StringRef FS,
TargetOptions Options,
@@ -70,7 +79,13 @@ namespace {
class AMDGPUPassConfig : public TargetPassConfig {
public:
AMDGPUPassConfig(AMDGPUTargetMachine *TM, PassManagerBase PM)
-: TargetPassConfig(TM, PM) {}
+: TargetPassConfig(TM, PM) {
+const AMDGPUSubtarget ST = TM-getSubtargetAMDGPUSubtarget();
+if (ST.device()-getGeneration() = AMDGPUDeviceInfo::HD6XXX) {
+ enablePass(MachineSchedulerID);
+ MachineSchedRegistry::setDefault(createR600MachineScheduler);
+}
+ }
AMDGPUTargetMachine getAMDGPUTargetMachine() const {
return getTMAMDGPUTargetMachine();
diff --git a/lib/Target/R600/R600MachineScheduler.cpp
b/lib/Target/R600/R600MachineScheduler.cpp
new file mode 100644
index 000..efd9490
--- /dev/null
+++ b/lib/Target/R600/R600MachineScheduler.cpp
@@ -0,0 +1,483 @@
+//===-- R600MachineScheduler.cpp - R600 Scheduler Interface -*- C++
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+/// \file
+/// \brief R600 Machine Scheduler interface
+// TODO: Scheduling is optimised for VLIW4 arch, modify it to support TRANS
slot
+//
+//===--===//
+
+#define DEBUG_TYPE misched
+
+#include R600MachineScheduler.h
+#include llvm/CodeGen/MachineRegisterInfo.h
+#include llvm/CodeGen/LiveIntervalAnalysis.h
+#include llvm/Pass.h
+#include llvm/PassManager.h
+#include set
+#include iostream
+using namespace llvm;
+
+void R600SchedStrategy::initialize(ScheduleDAGMI *dag) {
+
+ DAG = dag;
+ TII = static_castconst R600InstrInfo*(DAG-TII);
+ TRI = static_castconst R600RegisterInfo*(DAG-TRI);
+ MRI = DAG-MRI;
+ Available[IDAlu]-clear();
+ Available[IDFetch]-clear();
+ Available[IDOther]-clear();
+ CurInstKind = IDOther;
+ CurEmitted = 0;
+ memset(InstructionsGroupCandidate, 0, sizeof(InstructionsGroupCandidate));
+ InstKindLimit[IDAlu] = 120; // 120 minus 8 for security
+
+
+ const AMDGPUSubtarget ST = DAG-TM.getSubtargetAMDGPUSubtarget();
+ if (ST.device()-getGeneration() = AMDGPUDeviceInfo::HD5XXX) {
+InstKindLimit[IDFetch] = 7; // 8 minus 1 for security
+ } else {
+InstKindLimit[IDFetch] = 15; // 16 minus 1 for security
+ }
+}
+
+void R600SchedStrategy::MoveUnits(ReadyQueue *QSrc, ReadyQueue *QDst)
+{
+ if (QSrc-empty())
+return;
+ for (ReadyQueue::iterator I = QSrc-begin(),
+ E = QSrc-end();
Re: [Mesa-dev] [PATCH] r600g: don't reserve more stack space than required v2
Vadim Girlin wrote: Overcautious stack reservation caused significant loss of performance. v2: fix stack depth computation I get some corruption with this patch and heaven 3.0 with llvm on HD4890, R600_LLVM=0 is OK. It appears on sunlit areas over a certain distance and the patches move around. http://www.andyqos.ukfsn.org/heaven-corrupt.jpg that was taken with these settings http://www.andyqos.ukfsn.org/unigine_20130218_1304-llvm-1-patched.html I also retested with shaders high using the envs you gave - MESA_EXTENSION_OVERRIDE=-GL_ARB_shader_bit_encoding force_glsl_extensions_warn=true and saw the same issue. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current
https://bugs.freedesktop.org/show_bug.cgi?id=61012 --- Comment #2 from Brian Paul bri...@vmware.com --- Created attachment 75059 -- https://bugs.freedesktop.org/attachment.cgi?id=75059action=edit llvmpipe texture size patch Can you test the attached patch? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current
https://bugs.freedesktop.org/show_bug.cgi?id=61012 --- Comment #3 from Roland Scheidegger srol...@vmware.com --- (In reply to comment #0) The following(ish) code produces an assertion failure using llvmpipe libGL from Mesa 9.0.2: Near as I can tell, the call responsible for storing that state with the pbuffer is this code: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/glx/ xlib/xm_api.c?id=369e46888904c6d379b8b477d9242cff1608e30e#n460 A call to get_drawable_size retrieves the size of the pbuffer drawable into local variables width and height, but these values never make it into the XMesaBuffer structure. This isn't llvmpipe specific right? That call you mention indeed looks a bit odd. The function comment explicitly states Width/Height of the new buffer will be 0 so I don't know why it calls get_drawable_size() there in the first place (probably some leftover from older code). It looks like for pixmaps/windows that information will be filled out later at MakeCurrent time, which will eventually call xmesa_check_buffer_size() which will fill it in. However, for pbuffers this is a noop. My guess is it should be filled out in XMesaCreatePBuffer() instead since pbuffers have fixed size (?). -- 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] GMA3150 - OpenVG - QT - Embedded
On Sun, Feb 17, 2013 at 9:34 AM, Einar Már Björgvinsson einar.bjorgvins...@marel.com wrote: Hi there I'm currently trying to cross-compile the Mesa-9.0.1 before compiling QT 4.8 with OpenVG support. I've tried some variation of compiling both the Mesa library and the libdrm with several build complaints. My main question here is that I feel like I need a brief overview of what I should be building and with which options ?? What I'm trying to accomplish is to compile QT 4.8 with OpenVG support to run on Intel Atom D525 without any X11 support We maintain our own Ubuntu based Linux distro where all graphics are using framebuffer. We are trying to move from that and into using the 2D acceleration on the Intel Atom (GMA3150). I haven't managed to go passed the 'configure' stage of the Mesa build, it complains of not finding the libdrm, so I downloaded the libdrm and started to cross-compile. That stopped on build failure complaining about not finding 'pciaccess'. With this email I'm just trying to get answers on which course I should focus on because I have a feeling that there are several libraries I need to cross-compile in order to get this work done. I want to minimize that work as possible. Hope you can assist. Regards Einar M. Bjorgvinsson Embedded Software Engineer Marel ehf Iceland Hi, OpenVG is implemented as a state tracker for Gallium3D, so only Gallium3D drivers are able to use it. Pineview is i915, so in order to use OpenVG you'll have to use the Gallium/i915 driver that isn't maintained by Intel. (Intel maintains the classic-style i915 driver) I'd try to configure with these options: ./configure --with-dri-drivers= --with-gallium-drivers=i915 --enable-gallium-llvm --enable-openvg --enable-gallium-egl (--enable-gallium-llvm gives i915 better performance, but adds the dependency of LLVM) You might be able to avoid some dependencies by adding --disable-opengl --disable-gles1 --disable-gles2 --disable-dri --disable-glx but I'm not really sure how Gallium works, so you might need DRI to get any acceleration. libdrm built with Intel support, which Gallium/i915 needs, does indeed depend on libpciaccess. libpciaccess is a rather small library though. I wouldn't expect trouble with it. Matt ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Need bench mark application for Opengles2 on mesa-8.0.4 with Linux
On Mon, Feb 18, 2013 at 2:31 AM, Ramesh Reddy Emmadi ramesh_emm...@infosys.com wrote: Hi, Can you please let us know is there any benchmark tool for opengles2 API's in Linux and Windows. Thanks and Regards, Ramesh glmark2, maybe: https://launchpad.net/glmark2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61003] gluSurface with Nurbs spits out C code arc_ccw_turn...
https://bugs.freedesktop.org/show_bug.cgi?id=61003 Brian Paul bri...@vmware.com changed: What|Removed |Added Assignee|mesa-dev@lists.freedesktop. |matts...@gmail.com |org | --- Comment #2 from Brian Paul bri...@vmware.com --- Matt, when glu is configured without --enable-debug we should probably have -DNDEBUG in our CFLAGS. Can you look into that? -- 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 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current
https://bugs.freedesktop.org/show_bug.cgi?id=61012 --- Comment #4 from Brian Paul bri...@vmware.com --- Created attachment 75065 -- https://bugs.freedesktop.org/attachment.cgi?id=75065action=edit Initialize the buffer's size in create_xmesa_buffer() Here's another patch to try. It uses the results of get_drawable_size() to initialize the buffer's dimensions. I've run other test programs and it seems to be OK. I think my previous patch for llvmpipe is also needed since it's possible to create a pbuffer of size 0 x 0. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] fix bfo#59876: glGetTexLevelParameteriv broken for indirect rendering
On 02/18/2013 10:48 AM, Roland Scheidegger wrote: Am 05.02.2013 17:29, schrieb Stefan Brüns: A single element in a GLX reply is contained in the header itself. The number of elements is denoted in the n field of the reply, if n is 1, the length of additional data is 0. The XXX_data_length() function of xcb does not return the length of the (optional, n1) data but the number of elements. Signed-off-by: Stefan Brünsstefan.bru...@rwth-aachen.de --- src/mapi/glapi/gen/glX_proto_send.py |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/mapi/glapi/gen/glX_proto_send.py b/src/mapi/glapi/gen/glX_proto_send.py index fbc0dd3..ae6b8d9 100644 --- a/src/mapi/glapi/gen/glX_proto_send.py +++ b/src/mapi/glapi/gen/glX_proto_send.py @@ -700,7 +700,9 @@ generic_%u_byte( GLint rop, const void * ptr ) if f.reply_always_array: print '(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, xcb_name, output.get_base_type_string()) else: -print 'if (%s_data_length(reply) == 0)' % (xcb_name) +print '// the XXX_data_length() xcb function name is misleading, it returns the number' +print '// of elements, not the lenght of the data part. A single element is embedded.' s/lenght/length. +print 'if (%s_data_length(reply) == 1)' % (xcb_name) print '(void)memcpy(%s,reply-datum, sizeof(reply-datum));' % (output.name) print 'else' print '(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, xcb_name, output.get_base_type_string()) Looks good to me otherwise though this is not my area of expertise. I think this should be stable branch candidate. Yeah, I noticed the typo and was going to clean-up the commit message a bit. I'll post the updated patch for one more review. If there's no other feedback I'll push it later. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH mesa] freedreno: gallium driver for adreno
On Mon, Feb 18, 2013 at 12:47 PM, Matt Turner matts...@gmail.com wrote: On Sun, Feb 17, 2013 at 11:33 AM, Rob Clark robdcl...@gmail.com wrote: diff --git a/src/gallium/drivers/freedreno/Makefile.am b/src/gallium/drivers/freedreno/Makefile.am new file mode 100644 index 000..10abdfb --- /dev/null +++ b/src/gallium/drivers/freedreno/Makefile.am @@ -0,0 +1,35 @@ +include $(top_srcdir)/src/gallium/Automake.inc + +noinst_LTLIBRARIES = libfreedreno.la + +AM_CFLAGS = \ + -Werror -Wno-packed-bitfield-compat \ + -I$(top_srcdir)/src/gallium/include \ -- + -I$(top_srcdir)/src/gallium/auxiliary \ -- + -I$(top_srcdir)/src/gallium/drivers \ + -I$(top_srcdir)/include \ -- + $(FREEDRENO_CFLAGS) \ + $(DEFINES) \ -- + $(PIC_FLAGS) \ + $(VISIBILITY_CFLAGS) The -- mark things that are provided by the GALLIUM_CFLAGS variable in Automake.inc that you've already included. PIC_FLAGS is now dead. Distributions don't like -Werror being hardcoded into upstream's CFLAGS. Hmm, is there a better way to get -Werror for just freedreno when I am building myself? I do find that it is pretty useful to let the compiler help me catch problems rather than debugging them the hard way ;-) diff --git a/src/gallium/drivers/freedreno/a2xx_reg.h b/src/gallium/drivers/freedreno/a2xx_reg.h new file mode 100644 index 000..27403ec --- /dev/null +++ b/src/gallium/drivers/freedreno/a2xx_reg.h @@ -0,0 +1,455 @@ +/* Copyright (c) 2002,2007-2012, Code Aurora Forum. All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 and + * only version 2 as published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. GPL? yeah, this and a couple other headers are coming from qcom kernel driver, so it wouldn't be right for me to change the license. I guess I could just re-implement these headers myself. But IANAL so wasn't quite clear about what to do for these.. diff --git a/src/gallium/targets/dri-freedreno/Makefile.am b/src/gallium/targets/dri-freedreno/Makefile.am new file mode 100644 index 000..59293a6 --- /dev/null +++ b/src/gallium/targets/dri-freedreno/Makefile.am @@ -0,0 +1,71 @@ +# Copyright © 2012 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the Software), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, +# EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +# MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND +# NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT +# HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, +# WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. + +include $(top_srcdir)/src/gallium/Automake.inc + +AM_CFLAGS = \ + $(GALLIUM_CFLAGS) \ + $(PTHREAD_CFLAGS) \ + $(LIBDRM_CFLAGS) +AM_CPPFLAGS = \ + -I$(top_srcdir)/src/gallium/drivers \ + -I$(top_srcdir)/src/gallium/winsys \ + -I$(top_srcdir)/src/mesa \ + -I$(top_srcdir)/src/mapi \ + -I$(top_builddir)/src/mesa/drivers/dri/common \ + -DGALLIUM_RBUG \ + -DGALLIUM_TRACE + +dridir = $(DRI_DRIVER_INSTALL_DIR) +dri_LTLIBRARIES = kgsl_dri.la + +nodist_EXTRA_kgsl_dri_la_SOURCES = dummy.cpp +kgsl_dri_la_SOURCES = \ + target.c \ + $(top_srcdir)/src/mesa/drivers/dri/common/utils.c \ + $(top_srcdir)/src/mesa/drivers/dri/common/dri_util.c \ + $(top_srcdir)/src/mesa/drivers/dri/common/xmlconfig.c + +kgsl_dri_la_LDFLAGS = -module -avoid-version -shared -no-undefined + +kgsl_dri_la_LIBADD = \ + $(top_builddir)/src/mesa/libmesagallium.la \ + $(top_builddir)/src/gallium/auxiliary/libgallium.la \ + $(top_builddir)/src/gallium/state_trackers/dri/drm/libdridrm.la \ + $(top_builddir)/src/gallium/winsys/freedreno/drm/libfreedrenodrm.la \ + $(top_builddir)/src/gallium/drivers/freedreno/libfreedreno.la \ +
[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current
https://bugs.freedesktop.org/show_bug.cgi?id=61012 --- Comment #6 from Brian Paul bri...@vmware.com --- (In reply to comment #5) Created attachment 75068 [details] [review] another attempt to fix pbuffer initialization Hmm is it legal to use XGetGeometry() with pbuffers? Not normally, but in the glx/xlib code we create a dummy pixmap for each pbuffer so that we have an XID that we can pass around. I think something like this patch would be better. That would be fine too. It's what I first tried. Not sure if guarding against zero-sized buffers in drivers is needed. Might be but there are other instances where we hack up such windows to have width/height of 1 for that reason so we don't have to do it in drivers. I hacked up a test for a 0x0 surface. Softpipe worked but the llvmpipe assertion failed. I guess I'd consider the llvmpipe change to be a defensive coding check. One less way for llvmpipe to fail is good thing. -- 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] radeonsi: Fix blending using destination alpha factor but non-alpha destination
Am 18.02.2013 19:14, schrieb Michel Dänzer:
From: Michel Dänzer michel.daen...@amd.com
11 more little piglits.
NOTE: This is a candidate for the 9.1 branch.
Signed-off-by: Michel Dänzer michel.daen...@amd.com
---
Any ideas why this seems necessary with radeonsi but not with r600g?
Maybe the hw uses an implicit 1 if the format has no alpha (though I'm
not sure if it can always know with bgrx formats and the like).
I'm wondering if there should be a helper for those fixups. Looks to me
like quite some drivers need it (though well so far I think just
non-gallium i965 does this plus llvmpipe, but for some of the others I'm
skeptical if not doing it is really correct...).
src/gallium/drivers/radeonsi/si_state.c | 116
+---
src/gallium/drivers/radeonsi/si_state.h | 3 +-
2 files changed, 61 insertions(+), 58 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index d20e3ff..144a29d 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -36,33 +36,6 @@
#include si_state.h
#include sid.h
-/*
- * inferred framebuffer and blender state
- */
-static void si_update_fb_blend_state(struct r600_context *rctx)
-{
- struct si_pm4_state *pm4;
- struct si_state_blend *blend = rctx-queued.named.blend;
- uint32_t mask;
-
- if (blend == NULL)
- return;
-
- pm4 = CALLOC_STRUCT(si_pm4_state);
- if (pm4 == NULL)
- return;
-
- mask = (1ULL ((unsigned)rctx-framebuffer.nr_cbufs * 4)) - 1;
- mask = blend-cb_target_mask;
- si_pm4_set_reg(pm4, R_028238_CB_TARGET_MASK, mask);
-
- si_pm4_set_state(rctx, fb_blend, pm4);
-}
-
-/*
- * Blender functions
- */
-
static uint32_t si_translate_blend_function(int blend_func)
{
switch (blend_func) {
@@ -84,7 +57,7 @@ static uint32_t si_translate_blend_function(int blend_func)
return 0;
}
-static uint32_t si_translate_blend_factor(int blend_fact)
+static uint32_t si_translate_blend_factor(int blend_fact, bool dst_alpha)
{
switch (blend_fact) {
case PIPE_BLENDFACTOR_ONE:
@@ -94,7 +67,7 @@ static uint32_t si_translate_blend_factor(int blend_fact)
case PIPE_BLENDFACTOR_SRC_ALPHA:
return V_028780_BLEND_SRC_ALPHA;
case PIPE_BLENDFACTOR_DST_ALPHA:
- return V_028780_BLEND_DST_ALPHA;
+ return dst_alpha ? V_028780_BLEND_DST_ALPHA :
V_028780_BLEND_ONE;
case PIPE_BLENDFACTOR_DST_COLOR:
return V_028780_BLEND_DST_COLOR;
case PIPE_BLENDFACTOR_SRC_ALPHA_SATURATE:
@@ -110,7 +83,7 @@ static uint32_t si_translate_blend_factor(int blend_fact)
case PIPE_BLENDFACTOR_INV_SRC_ALPHA:
return V_028780_BLEND_ONE_MINUS_SRC_ALPHA;
case PIPE_BLENDFACTOR_INV_DST_ALPHA:
- return V_028780_BLEND_ONE_MINUS_DST_ALPHA;
+ return dst_alpha ? V_028780_BLEND_ONE_MINUS_DST_ALPHA :
V_028780_BLEND_ZERO;
case PIPE_BLENDFACTOR_INV_DST_COLOR:
return V_028780_BLEND_ONE_MINUS_DST_COLOR;
case PIPE_BLENDFACTOR_INV_CONST_COLOR:
@@ -133,30 +106,25 @@ static uint32_t si_translate_blend_factor(int
blend_fact)
return 0;
}
I think you might also need to patch up SRC_ALPHA_SATURATE (to zero).
Can't comment on the hw stuff but at least llvmpipe does the same
otherwise :-).
Roland
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current
https://bugs.freedesktop.org/show_bug.cgi?id=61012 --- Comment #7 from Roland Scheidegger srol...@vmware.com --- (In reply to comment #6) (In reply to comment #5) Created attachment 75068 [details] [review] [review] another attempt to fix pbuffer initialization Hmm is it legal to use XGetGeometry() with pbuffers? Not normally, but in the glx/xlib code we create a dummy pixmap for each pbuffer so that we have an XID that we can pass around. Ah ok then that should be fine too. I think though in this case the function comment should be updated too (which is why I was thinking this function shouldn't really set up size for whatever reason). I think something like this patch would be better. That would be fine too. It's what I first tried. Not sure if guarding against zero-sized buffers in drivers is needed. Might be but there are other instances where we hack up such windows to have width/height of 1 for that reason so we don't have to do it in drivers. I hacked up a test for a 0x0 surface. Softpipe worked but the llvmpipe assertion failed. I guess I'd consider the llvmpipe change to be a defensive coding check. One less way for llvmpipe to fail is good thing. Yeah probably. Though zero-sized resources are a pretty nasty thing. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] draw: make sure key size is calculated consistently.
From: Roland Scheidegger srol...@vmware.com
Some parts calculated key size by using shader information, others by using
the pipe_vertex_element information. Since it is perfectly valid to have more
vertex_elements set than the vertex shader is using those may not be the same,
so we weren't copying over all vertex_element state - this caused the tgsi dump
to assert (iterates over all vertex elements). With some luck it didn't
crash otherwise even though the llvm generate_fetch code also iterates over
all vertex elements (probably because llvm threw away the unused inputs anyway),
but if in this situation vertex texturing would be used things would definitely
go wrong (as the sampler information wouldn't be copied).
So drop the key size calculation using shader information.
---
src/gallium/auxiliary/draw/draw_llvm.c | 13 -
src/gallium/auxiliary/draw/draw_llvm.h |1 -
.../draw/draw_pt_fetch_shade_pipeline_llvm.c |7 ++-
src/gallium/auxiliary/draw/draw_vs_llvm.c |6 --
4 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/src/gallium/auxiliary/draw/draw_llvm.c
b/src/gallium/auxiliary/draw/draw_llvm.c
index f3b..df57358 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_llvm.c
@@ -420,17 +420,20 @@ draw_llvm_destroy(struct draw_llvm *llvm)
*/
struct draw_llvm_variant *
draw_llvm_create_variant(struct draw_llvm *llvm,
-unsigned num_inputs,
-const struct draw_llvm_variant_key *key)
+ unsigned num_inputs,
+ const struct draw_llvm_variant_key *key)
{
struct draw_llvm_variant *variant;
struct llvm_vertex_shader *shader =
llvm_vertex_shader(llvm-draw-vs.vertex_shader);
LLVMTypeRef vertex_header;
+ unsigned key_size = draw_llvm_variant_key_size(key-nr_vertex_elements,
+ MAX2(key-nr_samplers,
+ key-nr_sampler_views));
variant = MALLOC(sizeof *variant +
- shader-variant_key_size -
- sizeof variant-key);
+key_size -
+sizeof variant-key);
if (variant == NULL)
return NULL;
@@ -440,7 +443,7 @@ draw_llvm_create_variant(struct draw_llvm *llvm,
create_jit_types(variant);
- memcpy(variant-key, key, shader-variant_key_size);
+ memcpy(variant-key, key, key_size);
vertex_header = create_jit_vertex_header(variant-gallivm, num_inputs);
diff --git a/src/gallium/auxiliary/draw/draw_llvm.h
b/src/gallium/auxiliary/draw/draw_llvm.h
index 17ca304..b20cee5 100644
--- a/src/gallium/auxiliary/draw/draw_llvm.h
+++ b/src/gallium/auxiliary/draw/draw_llvm.h
@@ -281,7 +281,6 @@ struct draw_llvm_variant
struct llvm_vertex_shader {
struct draw_vertex_shader base;
- unsigned variant_key_size;
struct draw_llvm_variant_list_item variants;
unsigned variants_created;
unsigned variants_cached;
diff --git a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
index b0c18ed..d7f855f 100644
--- a/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c
@@ -127,13 +127,18 @@ llvm_middle_end_prepare( struct draw_pt_middle_end
*middle,
struct llvm_vertex_shader *shader = llvm_vertex_shader(vs);
char store[DRAW_LLVM_MAX_VARIANT_KEY_SIZE];
unsigned i;
+ unsigned key_size;
key = draw_llvm_make_variant_key(fpme-llvm, store);
+ key_size = draw_llvm_variant_key_size(key-nr_vertex_elements,
+MAX2(key-nr_samplers,
+ key-nr_sampler_views));
+
/* Search shader's list of variants for the key */
li = first_elem(shader-variants);
while (!at_end(shader-variants, li)) {
- if (memcmp(li-base-key, key, shader-variant_key_size) == 0) {
+ if (memcmp(li-base-key, key, key_size) == 0) {
variant = li-base;
break;
}
diff --git a/src/gallium/auxiliary/draw/draw_vs_llvm.c
b/src/gallium/auxiliary/draw/draw_vs_llvm.c
index ac3999e..50cef79 100644
--- a/src/gallium/auxiliary/draw/draw_vs_llvm.c
+++ b/src/gallium/auxiliary/draw/draw_vs_llvm.c
@@ -98,12 +98,6 @@ draw_create_vs_llvm(struct draw_context *draw,
tgsi_scan_shader(state-tokens, vs-base.info);
- vs-variant_key_size =
- draw_llvm_variant_key_size(
- vs-base.info.file_max[TGSI_FILE_INPUT]+1,
- MAX2(vs-base.info.file_max[TGSI_FILE_SAMPLER]+1,
- vs-base.info.file_max[TGSI_FILE_SAMPLER_VIEW]+1));
-
vs-base.state.stream_output = state-stream_output;
vs-base.draw = draw;
vs-base.prepare = vs_llvm_prepare;
--
1.7.9.5
[Mesa-dev] [PATCH] glsl: Initialize parcel_out_uniform_storage member variables.
Fixes uninitialized scalar field defect reported by Coverity.
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/glsl/link_uniforms.cpp | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/glsl/link_uniforms.cpp b/src/glsl/link_uniforms.cpp
index d457e4d..5e391ee 100644
--- a/src/glsl/link_uniforms.cpp
+++ b/src/glsl/link_uniforms.cpp
@@ -263,9 +263,11 @@ public:
parcel_out_uniform_storage(struct string_to_uint_map *map,
struct gl_uniform_storage *uniforms,
union gl_constant_value *values)
- : map(map), uniforms(uniforms), next_sampler(0), values(values)
+ : ubo_block_index(0), ubo_byte_offset(0), ubo_row_major(false),
+map(map) uniforms(uniforms), next_sampler(0), values(values),
+targets(), shader_samplers_used(0), shader_shadow_samplers(0)
{
- memset(this-targets, 0, sizeof(this-targets));
+ /* empty */
}
void start_shader()
--
1.8.1.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 61093] New: [llvmpipe] lp_surface.c:68:lp_resource_copy: Assertion `src_box-depth == 1' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=61093 Priority: medium Bug ID: 61093 Keywords: regression CC: mar...@gmail.com Assignee: mesa-dev@lists.freedesktop.org Summary: [llvmpipe] lp_surface.c:68:lp_resource_copy: Assertion `src_box-depth == 1' failed. Severity: critical Classification: Unclassified OS: Linux (All) Reporter: v...@freedesktop.org Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Other Product: Mesa mesa: 07cdfdb708ac28aa487a738db30b128cb0df1dc3 (master) Run piglit test texsubimage on llvmpipe. $ ./bin/texsubimage -auto Using test set: Core formats src/gallium/drivers/llvmpipe/lp_surface.c:68:lp_resource_copy: Assertion `src_box-depth == 1' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x7f45cd5c145f in _debug_assert_fail (expr=0x7f45cdef06aa src_box-depth == 1, file=0x7f45cdef0680 src/gallium/drivers/llvmpipe/lp_surface.c, line=68, function=0x7f45cdef0850 __FUNCTION__.11411 lp_resource_copy) at src/gallium/auxiliary/util/u_debug.c:278 #1 0x7f45cd284d9c in lp_resource_copy (pipe=0x23fd280, dst=0x98eeeb0, dst_level=0, dstx=0, dsty=0, dstz=0, src=0x977c930, src_level=0, src_box=0x7fff1362c374) at src/gallium/drivers/llvmpipe/lp_surface.c:68 #2 0x7f45cd5dfcd9 in util_try_blit_via_copy_region (ctx=0x23fd280, blit=0x7fff1362c340) at src/gallium/auxiliary/util/u_surface.c:630 #3 0x7f45cd285220 in lp_blit (pipe=0x23fd280, blit_info=0x7fff1362c4f0) at src/gallium/drivers/llvmpipe/lp_surface.c:189 #4 0x7f45cd3c31d6 in st_TexSubImage (ctx=0x246bcf0, dims=3, texImage=0x9b33bf0, xoffset=0, yoffset=0, zoffset=0, width=128, height=64, depth=8, format=6408, type=5121, pixels=0x9bb0c30, unpack=0x2472688) at src/mesa/state_tracker/st_cb_texture.c:776 #5 0x7f45cd3c33b2 in st_TexImage (ctx=0x246bcf0, dims=3, texImage=0x9b33bf0, format=6408, type=5121, pixels=0x9bb0c30, unpack=0x2472688) at src/mesa/state_tracker/st_cb_texture.c:806 #6 0x7f45cd37d7f7 in teximage (ctx=0x246bcf0, compressed=0 '\000', dims=3, target=32879, level=0, internalFormat=3, width=128, height=64, depth=8, border=0, format=6408, type=5121, imageSize=0, pixels=0x9bb0c30) at src/mesa/main/teximage.c:3091 #7 0x7f45cd37da7d in _mesa_TexImage3D (target=32879, level=0, internalFormat=3, width=128, height=64, depth=8, border=0, format=6408, type=5121, pixels=0x9bb0c30) at src/mesa/main/teximage.c:3146 #8 0x7f45cfb59f11 in stub_glTexImage3D (target=32879, level=0, internalformat=3, width=128, height=64, depth=8, border=0, format=6408, type=5121, pixels=0x9bb0c30) at piglit/tests/util/generated_dispatch.c:27319 #9 0x004023d1 in test_format (target=32879, intFormat=3) at piglit/tests/texturing/texsubimage.c:262 #10 0x0040293b in test_formats (target=32879) at piglit/tests/texturing/texsubimage.c:369 #11 0x00402999 in piglit_display () at piglit/tests/texturing/texsubimage.c:393 #12 0x7f45cfb21680 in display () at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:60 #13 0x7f45cf4ccfc4 in ?? () from /usr/lib/x86_64-linux-gnu/libglut.so.3 #14 0x7f45cf4d0719 in fgEnumWindows () from /usr/lib/x86_64-linux-gnu/libglut.so.3 #15 0x7f45cf4cd45c in glutMainLoopEvent () from /usr/lib/x86_64-linux-gnu/libglut.so.3 #16 0x7f45cf4cdd81 in glutMainLoop () from /usr/lib/x86_64-linux-gnu/libglut.so.3 #17 0x7f45cfb21852 in run_test (gl_fw=0x7f45cfdf3c00 glut_fw, argc=1, argv=0x7fff1362cd68) at piglit/tests/util/piglit-framework-gl/piglit_glut_framework.c:127 #18 0x7f45cfb1f971 in piglit_gl_test_run (argc=1, argv=0x7fff1362cd68, config=0x7fff1362cc50) at piglit/tests/util/piglit-framework-gl.c:127 #19 0x00401d8e in main (argc=2, argv=0x7fff1362cd68) at piglit/tests/texturing/texsubimage.c:46 (gdb) frame 1 #1 0x7f45cd284d9c in lp_resource_copy (pipe=0x23fd280, dst=0x98eeeb0, dst_level=0, dstx=0, dsty=0, dstz=0, src=0x977c930, src_level=0, src_box=0x7fff1362c374) at src/gallium/drivers/llvmpipe/lp_surface.c:68 68 assert(src_box-depth == 1); (gdb) print src_box-depth $1 = 8 0a1479c829ed34a65e60c6619a8164e1b079aaee is the first bad commit commit 0a1479c829ed34a65e60c6619a8164e1b079aaee Author: Marek Olšák mar...@gmail.com Date: Thu Feb 14 01:03:55 2013 +0100 st/mesa: implement blit-based TexImage and TexSubImage A temporary texture is created such that it matches the format and type combination and pixels are copied to it using memcpy. Then the blit is used to copy the temporary texture to the texture image being modified by TexImage or TexSubImage. The blit takes care of the format and type conversion and swizzling. The result is a very fast texture upload involving as little CPU as possible. This improves
Re: [Mesa-dev] [PATCH] i965/gen[45]: Do point coord logic whenever gl_PointCoord is asked for.
On 02/15/2013 10:46 PM, Eric Anholt wrote:
The desktop spec asks for gl_PointCoord to be defined only when
GL_POINT_SPRITE is enabled, and it's undefined otherwise (why?!). The
ES spec doesn't have GL_POINT_SPRITE and gl_PointCoord is always
defined. So just make our implementation always give you gl_PointCoord
regardless of the enable.
We had a similar issue with core-profiles, which also lack the enable.
I seem to recall that we just changed the default state to enabled...
which would also fix this issue for i915. Right?
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=32429
---
src/mesa/drivers/dri/i965/brw_sf.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_sf.c
b/src/mesa/drivers/dri/i965/brw_sf.c
index eb361a9..6e5bfe5 100644
--- a/src/mesa/drivers/dri/i965/brw_sf.c
+++ b/src/mesa/drivers/dri/i965/brw_sf.c
@@ -181,8 +181,11 @@ brw_upload_sf_prog(struct brw_context *brw)
key.point_sprite_coord_replace |= (1 i);
}
}
- if (brw-fragment_program-Base.InputsRead
BITFIELD64_BIT(FRAG_ATTRIB_PNTC))
+ if (brw-fragment_program-Base.InputsRead FRAG_BIT_PNTC) {
key.do_point_coord = 1;
+ key.do_point_sprite = 1;
+ }
+
/*
* Window coordinates in a FBO are inverted, which means point
* sprite origin must be inverted, too.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glx: fix glGetTexLevelParameteriv for indirect rendering
On 02/18/2013 10:16 AM, Brian Paul wrote: From: Stefan Brüns stefan.bru...@rwth-aachen.de A single element in a GLX reply is contained in the header itself. The number of elements is denoted in the n field of the reply. If n is 1, the length of additional data is 0. The XXX_data_length() function of xcb does not return the length of the (optional, n1) data but the number of elements. Fixes http://bugs.freedesktop.org/show_bug.cgi?id=59876 Note: This is a candidate for the stable branches. Signed-off-by: Stefan Brüns stefan.bru...@rwth-aachen.de Signed-off-by: Brian Paul bri...@vmware.com Reviewed-by: Ian Romanick ian.d.roman...@intel.com Sorry for the lag. I missed the first patch while I was out with the FOSDEM flu. If nobody beats me to it, I'll commit it to master tomorrow morning. --- src/mapi/glapi/gen/glX_proto_send.py |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/src/mapi/glapi/gen/glX_proto_send.py b/src/mapi/glapi/gen/glX_proto_send.py index fbc0dd3..f4d519f 100644 --- a/src/mapi/glapi/gen/glX_proto_send.py +++ b/src/mapi/glapi/gen/glX_proto_send.py @@ -700,7 +700,9 @@ generic_%u_byte( GLint rop, const void * ptr ) if f.reply_always_array: print '(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, xcb_name, output.get_base_type_string()) else: -print 'if (%s_data_length(reply) == 0)' % (xcb_name) +print '/* the XXX_data_length() xcb function name is misleading, it returns the number */' +print '/* of elements, not the length of the data part. A single element is embedded. */' +print 'if (%s_data_length(reply) == 1)' % (xcb_name) print '(void)memcpy(%s, reply-datum, sizeof(reply-datum));' % (output.name) print 'else' print '(void)memcpy(%s, %s_data(reply), %s_data_length(reply) * sizeof(%s));' % (output.name, xcb_name, xcb_name, output.get_base_type_string()) ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] configure.ac: Do not check for clock_gettime on MinGW.
MinGW does not have clock_gettime. Signed-off-by: Vinson Lee v...@freedesktop.org --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 16c2f8c..57d3a70 100644 --- a/configure.ac +++ b/configure.ac @@ -502,6 +502,8 @@ AC_SUBST([DLOPEN_LIBS]) case $host_os in darwin*) ;; +mingw*) +;; *) AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=], [AC_CHECK_LIB([rt], [clock_gettime], [CLOCK_LIB=-lrt], -- 1.8.1.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Do not check for clock_gettime on MinGW.
On Mon, Feb 18, 2013 at 10:06 PM, Vinson Lee v...@freedesktop.org wrote: MinGW does not have clock_gettime. Signed-off-by: Vinson Lee v...@freedesktop.org --- configure.ac | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configure.ac b/configure.ac index 16c2f8c..57d3a70 100644 --- a/configure.ac +++ b/configure.ac @@ -502,6 +502,8 @@ AC_SUBST([DLOPEN_LIBS]) case $host_os in darwin*) ;; +mingw*) +;; *) AC_CHECK_FUNCS([clock_gettime], [CLOCK_LIB=], [AC_CHECK_LIB([rt], [clock_gettime], [CLOCK_LIB=-lrt], -- 1.8.1.2 I think you can just do darwin*|mingw*) ;; ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
