Re: [Mesa-dev] [PATCH] i965: fix mask used to write to clip distance registers when gen>6
On Mon, 13 Jun 2011 11:30:56 -0700, Paul Berry wrote: > On 13 June 2011 09:58, Eric Anholt wrote: > > On Sun, 12 Jun 2011 21:14:50 -0700, Paul Berry > > wrote: > >> In gen6 and above, clip distances 0-3 are written to message register > >> 3's xyzw components, and 4-7 to message register 4's xyzw components. > >> Therefore when when writing the clip distances we need to examine the > >> lower 2 bits of the clip distance index to see which component to > >> write to. > >> > >> emit_vertex_write() was examining the lower 3 bits, causing clip > >> distances 4-7 not to be written correctly. > > > > Reviewed-by: Eric Anholt > > > > Is this caught by any new testcase? It's not a requirement, just > > thinking that since you were building testcases like this recently, it > > might be easy. > > > > Yes, agreed. It's caught by vs-clip-vertex-01.shader_test, which I > sent to the piglit list earlier that day. The patch hasn't landed > yet. Cool. Even if the test isn't landed, go ahead and mention it in the commit log. pgpwtcISXV7UN.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] linker: Reject shaders that use too many varyings
On Mon, 13 Jun 2011 12:09:04 -0700, "Ian Romanick" wrote: > From: Ian Romanick > > Previously it was up to the driver or later code generator to reject > these shaders. It turns out that nobody did this. > > This will need changes to support geometry shaders. > > NOTE: This is a candidate for the stable branches. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743 I find it odd that arrays/matrices are treated as increments of 4 components while plain vectors aren't. Plain vectors end up occupying 4 components in our current implementation (you won't get more than 16 varying vectors working, since we run out of bits), and I think treating it that way for limits would be more intelligible for users than leaving it to the driver to catch later. pgpwexdP0428a.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38085] Mesa: User error: GL_INVALID_ENUM in glTexParameter(param=0x2901)
https://bugs.freedesktop.org/show_bug.cgi?id=38085 --- Comment #7 from Alexandre Demers 2011-06-13 17:26:28 PDT --- (In reply to comment #6) > It's best to ssh in from another computer and do your debugging from there. That will be a problem, since my netbook was stolen a couple of months ago. Any other suggestion? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Mesa 7.10.3 release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mesa 7.10.3 has been released. This is a stable release containing bug fixes since the 7.10.2 release. The tag in the GIT repository for Mesa 7.10.3 is 'mesa-7.10.3'. Mesa 7.10.3 is available for download at ftp://freedesktop.org/pub/mesa/7.10.3/ md5sums: d77b02034c11d6c2a55c07f82367d780 MesaLib-7.10.3.tar.gz 8c38fe8266be8e1ed1d84076ba5a703b MesaLib-7.10.3.tar.bz2 614d063ecd170940d9ae7b355d365d59 MesaLib-7.10.3.zip 8768fd562ede7ed763d92b2d22232d7a MesaGLUT-7.10.3.tar.gz 1496415b89da9549f0f3b34d9622e2e2 MesaGLUT-7.10.3.tar.bz2 1f29d0e7398fd3bf9f36f5db02941198 MesaGLUT-7.10.3.zip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk32pw8ACgkQX1gOwKyEAw8rNgCfav/49QsR7YCTr81ueCBx1/tR m7wAn2YTzu4DC5CN8znjmsObemcI3mOZ =+Hl1 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] st/mesa: improved is_interleaved_arrays() checking
Check that the difference in array pointers/offsets from the 0th
array are less than the stride, for both VBOs and user-space arrays.
Previously, we were only doing this for the later.
This tightens up the interleaved array test and fixes a problem with
the llvmpipe driver where we were creating way too many vertex fetch
variants only because the pipe_vertex_element::src_offset values were
changing frequently. This change results in a 5x speed-up for one of
the viewperf tests.
Also, clean up the function to make it easier to understand.
---
src/mesa/state_tracker/st_draw.c | 50 ++---
1 files changed, 19 insertions(+), 31 deletions(-)
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index dd26db2..1bb9b80 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -237,7 +237,6 @@ st_pipe_vertex_format(GLenum type, GLuint size, GLenum
format,
/**
* Examine the active arrays to determine if we have interleaved
* vertex arrays all living in one VBO, or all living in user space.
- * \param userSpace returns whether the arrays are in user space.
*/
static GLboolean
is_interleaved_arrays(const struct st_vertex_program *vp,
@@ -247,8 +246,8 @@ is_interleaved_arrays(const struct st_vertex_program *vp,
GLuint attr;
const struct gl_buffer_object *firstBufObj = NULL;
GLint firstStride = -1;
- const GLubyte *client_addr = NULL;
- GLboolean user_memory = GL_FALSE;
+ const GLubyte *firstPtr = NULL;
+ GLboolean userSpaceBuffer = GL_FALSE;
for (attr = 0; attr < vpv->num_inputs; attr++) {
const GLuint mesaAttr = vp->index_to_input[attr];
@@ -256,37 +255,26 @@ is_interleaved_arrays(const struct st_vertex_program *vp,
const struct gl_buffer_object *bufObj = array->BufferObj;
const GLsizei stride = array->StrideB; /* in bytes */
- if (firstStride < 0) {
+ if (attr == 0) {
+ /* save info about the first array */
firstStride = stride;
- user_memory = !bufObj || !bufObj->Name;
- }
- else if (firstStride != stride) {
- return GL_FALSE;
- }
-
- if (!bufObj || !bufObj->Name) {
- /* Try to detect if the client-space arrays are
- * "close" to each other.
- */
- if (!user_memory) {
-return GL_FALSE;
- }
- if (!client_addr) {
-client_addr = array->Ptr;
- }
- else if (abs(array->Ptr - client_addr) > firstStride) {
-/* arrays start too far apart */
-return GL_FALSE;
- }
- }
- else if (!firstBufObj) {
- if (user_memory) {
-return GL_FALSE;
- }
+ firstPtr = array->Ptr;
firstBufObj = bufObj;
+ userSpaceBuffer = !bufObj || !bufObj->Name;
}
- else if (bufObj != firstBufObj) {
- return GL_FALSE;
+ else {
+ /* check if other arrays interleave with the first, in same buffer */
+ if (stride != firstStride)
+return GL_FALSE; /* strides don't match */
+
+ if (bufObj != firstBufObj)
+return GL_FALSE; /* arrays in different VBOs */
+
+ if (abs(array->Ptr - firstPtr) > firstStride)
+return GL_FALSE; /* arrays start too far apart */
+
+ if ((!bufObj || !_mesa_is_bufferobj(bufObj)) != userSpaceBuffer)
+return GL_FALSE; /* mix of VBO and user-space arrays */
}
}
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
On 06/13/2011 03:53 PM, Jeremy Huddleston wrote: b44d13e67bfe81b2d7af4aeda2c3caf7f252bd0f should work for you. Thanks for letting me know. Another warning: glapi_gentable.c: In function ‘_glapi_create_table_from_handle’: glapi_gentable.c:54:9: warning: ISO C90 forbids mixed declarations and code glapi_gentable.c:55:18: warning: ISO C forbids conversion of object pointer to f unction pointer type glapi_gentable.c:61:9: warning: ISO C90 forbids mixed declarations and code glapi_gentable.c:62:18: warning: ISO C forbids conversion of object pointer to f unction pointer type glapi_gentable.c:68:9: warning: ISO C90 forbids mixed declarations and code glapi_gentable.c:69:18: warning: ISO C forbids conversion of object pointer to f unction pointer type Need to put the _glapi_proc declaration first. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Bind to our context before __glXSetCurrentContext
We want to bind to our context before calling __glXSetCurrentContext or
messing with the gc rect in order to properly handle error conditions.
Signed-off-by: Jeremy Huddleston
---
src/glx/glxcurrent.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/src/glx/glxcurrent.c b/src/glx/glxcurrent.c
index 064fd71..9027734 100644
--- a/src/glx/glxcurrent.c
+++ b/src/glx/glxcurrent.c
@@ -212,7 +212,6 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
{
struct glx_context *gc = (struct glx_context *) gc_user;
struct glx_context *oldGC = __glXGetCurrentContext();
- int ret = Success;
/* XXX: If this is left out, then libGL ends up not having this
* symbol, and drivers using it fail to load. Compare the
@@ -268,24 +267,32 @@ MakeContextCurrent(Display * dpy, GLXDrawable draw,
}
if (gc) {
+ /* Attempt to bind the context. We do this before mucking with
+ * gc and __glXSetCurrentContext to properly handle our state in
+ * case of an error.
+ *
+ * If an error occurs, set the Null context since we've already
+ * blown away our old context. The caller is responsible for
+ * figuring out how to handle setting a valid context.
+ */
+ if (gc->vtable->bind(gc, oldGC, draw, read) != Success) {
+ __glXSetCurrentContextNull();
+ __glXUnlock();
+ __glXGenerateError(dpy, None, GLXBadContext, X_GLXMakeContextCurrent);
+ return GL_FALSE;
+ }
+
if (gc->thread_refcount++ == 0) {
gc->currentDpy = dpy;
gc->currentDrawable = draw;
gc->currentReadable = read;
}
__glXSetCurrentContext(gc);
- ret = gc->vtable->bind(gc, oldGC, draw, read);
} else {
__glXSetCurrentContextNull();
}
__glXUnlock();
-
- if (ret) {
- __glXGenerateError(dpy, None, ret, X_GLXMakeContextCurrent);
- return GL_FALSE;
- }
-
return GL_TRUE;
}
--
1.7.5.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
b44d13e67bfe81b2d7af4aeda2c3caf7f252bd0f should work for you. Thanks for
letting me know.
--Jeremy
On Jun 13, 2011, at 2:27 PM, Brian Paul wrote:
> On 06/13/2011 02:05 PM, Jeremy Huddleston wrote:
>> Hi Brian,
>>
>> Does this get rid of your warnings? (you'll need to regenerate the
>> glapi_gentable.c)
>>
>
> Getting a different warning now:
>
> glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
> glapi_gentable.c:54:24: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:60:24: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:66:25: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:72:26: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:78:28: warning: ISO C forbids assignment between function
> point
>
>
> I think you'll need to use a casting function along the lines of this from
> gallium's u_pointer.h:
>
> typedef void (*func_pointer)(void);
>
> static INLINE func_pointer
> pointer_to_func( void *p )
> {
> union {
> void *p;
> func_pointer f;
> } pf;
> pf.p = p;
> return pf.f;
> }
>
>
> -Brian
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
On Mon, Jun 13, 2011 at 3:23 PM, Jose Fonseca wrote:
>
> - Original Message -
>> Am 05.06.2011 06:31, schrieb Younes Manton:
>> > 2011/6/4 Jose Fonseca :
>> >> At very least there are ovious things that need to be fixed:
>> >>
>> >> - get_param / is_format_supported should not be duplicated from
>> >> screen.
>> >
>> > This is also deliberate.
>
>> > Params and surface formats may depend on
>> > the
>> > codec/profile/dimensions of the video stream the context was
>> > created
>> > to decode. There is not always enough info available in pipe_screen
>> > alone to determine if a particular cap or surface is supported. The
>> > current implementation largely wraps pipe_screen because again it's
>> > using the 3D pipeline and we don't have to deal with funny decoding
>> > hardware constraints.
>>
>> I'm not sure if that's the right answer though, couldn't you just as
>> well require a driver to handle all dimensions etc. for a given
>> codec?
>> If necessary should just use the shader stages (or cpu...) instead?
>>
>> Also, just glancing over the interface changes:
>> +enum pipe_video_codec
>> +{
>> + PIPE_VIDEO_CODEC_UNKNOWN = 0,
>> + PIPE_VIDEO_CODEC_MPEG12, /**< MPEG1, MPEG2 */
>> + PIPE_VIDEO_CODEC_MPEG4, /**< DIVX, XVID */
>> + PIPE_VIDEO_CODEC_VC1, /**< WMV */
>> + PIPE_VIDEO_CODEC_MPEG4_AVC /**< H.264 */
>> +};
>> +
>> +enum pipe_video_profile
>> +{
>> + PIPE_VIDEO_PROFILE_UNKNOWN,
>> + PIPE_VIDEO_PROFILE_MPEG1,
>> + PIPE_VIDEO_PROFILE_MPEG2_SIMPLE,
>> + PIPE_VIDEO_PROFILE_MPEG2_MAIN,
>> + PIPE_VIDEO_PROFILE_MPEG4_SIMPLE,
>> + PIPE_VIDEO_PROFILE_MPEG4_ADVANCED_SIMPLE,
>> + PIPE_VIDEO_PROFILE_VC1_SIMPLE,
>> + PIPE_VIDEO_PROFILE_VC1_MAIN,
>> + PIPE_VIDEO_PROFILE_VC1_ADVANCED,
>> + PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE,
>> + PIPE_VIDEO_PROFILE_MPEG4_AVC_MAIN,
>> + PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH
>> +};
>> Do you really need both here?
>>
>> @@ -229,9 +229,27 @@ enum pipe_format {
>> PIPE_FORMAT_L32A32_FLOAT = 161,
>> PIPE_FORMAT_I32_FLOAT = 162,
>>
>> + PIPE_FORMAT_YV12 = 163,
>> + PIPE_FORMAT_YV16 = 164,
>> + PIPE_FORMAT_IYUV = 165, /**< aka I420 */
>> + PIPE_FORMAT_NV12 = 166,
>> + PIPE_FORMAT_NV21 = 167,
>> + PIPE_FORMAT_AYUV = PIPE_FORMAT_A8R8G8B8_UNORM,
>> + PIPE_FORMAT_VUYA = PIPE_FORMAT_B8G8R8A8_UNORM,
>> + PIPE_FORMAT_XYUV = PIPE_FORMAT_X8R8G8B8_UNORM,
>> + PIPE_FORMAT_VUYX = PIPE_FORMAT_B8G8R8X8_UNORM,
>> + PIPE_FORMAT_IA44 = 168,
>> + PIPE_FORMAT_AI44 = 169,
>> +
>> PIPE_FORMAT_COUNT
>> };
>> Defining these formats as another format feels wrong. There might be
>> reasons why you'd want to use them in normal 3d contexts (ok maybe
>> not
>> really) but if you can't distinguish the format that's a no go.
>
> Yes this is also incorrect. Blitting from PIPE_FORMAT_AYUV to
> PIPE_FORMAT_A8R8G8B8_UNORM is not a no-op.
> I actually have llvmpipe AYUV support implemented in a private branch.
This wasn't intended to be permanent, just a quick hack that worked
for softpipe and 3D decoding, since for the 3D decoding case you'll
end up substituting an RGBA surface for AYUV anyhow.
>> Frankly I'm not sure if all these formats really should be simple
>> PIPE_FORMATs even, since chances you can use them in normal 3d
>> contexts
>> are next to zero anyway (especially the planar stuff hurts).
>
> That's fine. Pixel formats just need to uniquely describe out to interpret
> the pixels. A 3d context doesn't need to support all of them.
>
> I'll see
>> though where that's coming from (as pipe_surface, pipe_sampler_state
>> and
>> friends are reused, even though the entry points are not). Though I'm
>> not sure the all-new-entry points with reused gallium structs is
>> really
>> the right approach. Maybe if you need separate contexts etc. anyway
>> (to
>> be able to exploit video hardware) it would be better if you'd just
>> use
>> all your own structs better suited for video tasks. The vl code could
>> then translate that stuff to "normal" gallium.
>> If others are happy with the interface, I won't object though. I've
>> no
>> clue really how a better interface would look like...
>
> My gut feel looking at [1] is that pipe_video_context interface should be
> either an extension of pipe_context, or optional entry-points in
> pipe_context. Because there's a lot of functionality needed for a
> pipe_context (low level resource management, relocations, fences), that will
> be definitely useful for video processing too. And instead of
> duplicating/mirroring entry-points the existing entry-points should be
> enlarged to convey the necessary semantics.
>
> But honestly, why don't we simply move pipe_video_context out of
> src/gallium/include into the state tracker for the time being, and leave t
Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
Alright... looks like it needs the cast.
Thanks.
On Jun 13, 2011, at 2:27 PM, Brian Paul wrote:
> On 06/13/2011 02:05 PM, Jeremy Huddleston wrote:
>> Hi Brian,
>>
>> Does this get rid of your warnings? (you'll need to regenerate the
>> glapi_gentable.c)
>>
>
> Getting a different warning now:
>
> glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
> glapi_gentable.c:54:24: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:60:24: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:66:25: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:72:26: warning: ISO C forbids assignment between function
> point
> er and ‘void *’
> glapi_gentable.c:78:28: warning: ISO C forbids assignment between function
> point
>
>
> I think you'll need to use a casting function along the lines of this from
> gallium's u_pointer.h:
>
> typedef void (*func_pointer)(void);
>
> static INLINE func_pointer
> pointer_to_func( void *p )
> {
> union {
> void *p;
> func_pointer f;
> } pf;
> pf.p = p;
> return pf.f;
> }
>
>
> -Brian
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
On 06/13/2011 02:05 PM, Jeremy Huddleston wrote:
Hi Brian,
Does this get rid of your warnings? (you'll need to regenerate the
glapi_gentable.c)
Getting a different warning now:
glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
glapi_gentable.c:54:24: warning: ISO C forbids assignment between
function point
er and ‘void *’
glapi_gentable.c:60:24: warning: ISO C forbids assignment between
function point
er and ‘void *’
glapi_gentable.c:66:25: warning: ISO C forbids assignment between
function point
er and ‘void *’
glapi_gentable.c:72:26: warning: ISO C forbids assignment between
function point
er and ‘void *’
glapi_gentable.c:78:28: warning: ISO C forbids assignment between
function point
I think you'll need to use a casting function along the lines of this
from gallium's u_pointer.h:
typedef void (*func_pointer)(void);
static INLINE func_pointer
pointer_to_func( void *p )
{
union {
void *p;
func_pointer f;
} pf;
pf.p = p;
return pf.f;
}
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
On Mon, Jun 6, 2011 at 12:52 PM, Roland Scheidegger wrote: > Am 05.06.2011 06:31, schrieb Younes Manton: >> 2011/6/4 Jose Fonseca : >>> At very least there are ovious things that need to be fixed: >>> >>> - get_param / is_format_supported should not be duplicated from screen. >> >> This is also deliberate. Params and surface formats may depend on the >> codec/profile/dimensions of the video stream the context was created >> to decode. There is not always enough info available in pipe_screen >> alone to determine if a particular cap or surface is supported. The >> current implementation largely wraps pipe_screen because again it's >> using the 3D pipeline and we don't have to deal with funny decoding >> hardware constraints. > > I'm not sure if that's the right answer though, couldn't you just as > well require a driver to handle all dimensions etc. for a given codec? > If necessary should just use the shader stages (or cpu...) instead? That implies that every driver wanting to do HW decoding will also have to implement 3D decoding. But anyhow, it's really not a question of falling back. HW decoders will have different caps based on which codec they're decoding (and sometimes based on how many streams) and there needs to be a way for a state tracker to get that info. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
Hi Brian,
Does this get rid of your warnings? (you'll need to regenerate the
glapi_gentable.c)
diff --git a/src/mapi/glapi/gen/gl_gentable.py
b/src/mapi/glapi/gen/gl_gentable.py
index 0dfebf8..1681a80 100644
--- a/src/mapi/glapi/gen/gl_gentable.py
+++ b/src/mapi/glapi/gen/gl_gentable.py
@@ -42,7 +42,6 @@ header = """
#include "glapi.h"
#include "glapitable.h"
-#include "main/dispatch.h"
struct _glapi_table *
_glapi_create_table_from_handle(void *handle, const char *symbol_prefix) {
@@ -50,7 +49,10 @@ _glapi_create_table_from_handle(void *handle, const char
*symbol_prefix) {
char symboln[512];
if(!disp)
- return NULL;
+return NULL;
+
+if(symbol_prefix == NULL)
+symbol_prefix = "";
"""
footer = """
@@ -61,7 +63,7 @@ footer = """
body_template = """
if(!disp->%(name)s) {
snprintf(symboln, sizeof(symboln), "%%s%(entry_point)s",
symbol_prefix);
- SET_%(name)s(disp, dlsym(handle, symboln));
+ disp->%(name)s = dlsym(handle, symboln);
}
"""
On Jun 13, 2011, at 7:22 AM, Brian Paul wrote:
> On 06/11/2011 11:18 PM, Jeremy Huddleston wrote:
>> Module: Mesa
>> Branch: master
>> Commit: 85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b
>> URL:
>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b
>>
>> Author: Jeremy Huddleston
>> Date: Thu Jun 9 16:59:49 2011 -0700
>>
>> glapi: Add API that can create a _glapi_table from a dlfcn handle
>>
>> Example usage:
>>
>> void *handle = dlopen(opengl_library_path, RTLD_LOCAL);
>> struct _glapi_table *disp = _glapi_create_table_from_handle(handle, "gl");
>>
>> Signed-off-by: Jeremy Huddleston
>>
>> ---
>>
>> src/mapi/glapi/gen/Makefile |9 +-
>> src/mapi/glapi/gen/gl_gentable.py | 131 +
>> src/mapi/glapi/glapi.h|4 +
>> src/mapi/glapi/glapi_gentable.c | 7804
>> +
>> src/mapi/glapi/sources.mak|1 +
>> 5 files changed, 7947 insertions(+), 2 deletions(-)
>>
>> Diff:
>> http://cgit.freedesktop.org/mesa/mesa/diff/?id=85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b
>> ___
>> mesa-commit mailing list
>> mesa-com...@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-commit
>
>
> Jeremy,
>
> I'm getting a ton of warnings when glapi_gentable.c is compiled:
>
> glapi_gentable.c: In function ‘_glapi_create_table_from_handle’:
> glapi_gentable.c:52:10: warning: ISO C forbids passing argument 2 of
> ‘SET_NewLis
> t’ between function pointer and ‘void *’
> ../../../src/mesa/main/dispatch.h:2055:20: note: expected ‘void (*)(GLuint,
> GLe
> num)’ but argument is of type ‘void *’
> glapi_gentable.c:58:10: warning: ISO C forbids passing argument 2 of
> ‘SET_EndLis
> t’ between function pointer and ‘void *’
> ../../../src/mesa/main/dispatch.h:2066:20: note: expected ‘void (*)(void)’
> but a
> rgument is of type ‘void *’
> glapi_gentable.c:64:10: warning: ISO C forbids passing argument 2 of
> ‘SET_CallLi
> st’ between function pointer and ‘void *’
> ../../../src/mesa/main/dispatch.h:2077:20: note: expected ‘void (*)(GLuint)’
> but
> argument is of type ‘void *’
> glapi_gentable.c:70:10: warning: ISO C forbids passing argument 2 of
> ‘SET_CallLi
> sts’ between function pointer and ‘void *’
> ../../../src/mesa/main/dispatch.h:2088:20: note: expected ‘void (*)(GLsizei,
> GL
> enum, const GLvoid *)’ but argument is of type ‘void *’
> glapi_gentable.c:76:10: warning: ISO C forbids passing argument 2 of
> ‘SET_Delete
> Lists’ between function pointer and ‘void *’
> ../../../src/mesa/main/dispatch.h:2099:20: note: expected ‘void (*)(GLuint,
> GLs
> izei)’ but argument is of type ‘void *’
>
>
> I think the generator needs to insert some casts to pass the right function
> pointer type rather than void *.
>
> -Brian
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] linker: Reject shaders that use too many varyings
Ian Romanick [2011-06-13 12:09]:
> [...]
> + } else if (var->type->is_matrix()) {
> + varying_vectors += var->type->matrix_columns;
> + float_components += var->type->matrix_columns * 4;
> + } else {
> + varying_vectors++;
> + float_components += var->type->vector_elements;
> + }
> + }
> + }
> +
> + printf("varyings = %u, %u\n", varying_vectors, float_components);
Did you intend to leave this printf there?
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Status of VDPAU and XvMC state-trackers (was Re: Build error on current xvmc-r600 pipe-video)
- Original Message -
> Am 05.06.2011 06:31, schrieb Younes Manton:
> > 2011/6/4 Jose Fonseca :
> >> At very least there are ovious things that need to be fixed:
> >>
> >> - get_param / is_format_supported should not be duplicated from
> >> screen.
> >
> > This is also deliberate.
> > Params and surface formats may depend on
> > the
> > codec/profile/dimensions of the video stream the context was
> > created
> > to decode. There is not always enough info available in pipe_screen
> > alone to determine if a particular cap or surface is supported. The
> > current implementation largely wraps pipe_screen because again it's
> > using the 3D pipeline and we don't have to deal with funny decoding
> > hardware constraints.
>
> I'm not sure if that's the right answer though, couldn't you just as
> well require a driver to handle all dimensions etc. for a given
> codec?
> If necessary should just use the shader stages (or cpu...) instead?
>
> Also, just glancing over the interface changes:
> +enum pipe_video_codec
> +{
> + PIPE_VIDEO_CODEC_UNKNOWN = 0,
> + PIPE_VIDEO_CODEC_MPEG12, /**< MPEG1, MPEG2 */
> + PIPE_VIDEO_CODEC_MPEG4,/**< DIVX, XVID */
> + PIPE_VIDEO_CODEC_VC1, /**< WMV */
> + PIPE_VIDEO_CODEC_MPEG4_AVC /**< H.264 */
> +};
> +
> +enum pipe_video_profile
> +{
> + PIPE_VIDEO_PROFILE_UNKNOWN,
> + PIPE_VIDEO_PROFILE_MPEG1,
> + PIPE_VIDEO_PROFILE_MPEG2_SIMPLE,
> + PIPE_VIDEO_PROFILE_MPEG2_MAIN,
> + PIPE_VIDEO_PROFILE_MPEG4_SIMPLE,
> + PIPE_VIDEO_PROFILE_MPEG4_ADVANCED_SIMPLE,
> + PIPE_VIDEO_PROFILE_VC1_SIMPLE,
> + PIPE_VIDEO_PROFILE_VC1_MAIN,
> + PIPE_VIDEO_PROFILE_VC1_ADVANCED,
> + PIPE_VIDEO_PROFILE_MPEG4_AVC_BASELINE,
> + PIPE_VIDEO_PROFILE_MPEG4_AVC_MAIN,
> + PIPE_VIDEO_PROFILE_MPEG4_AVC_HIGH
> +};
> Do you really need both here?
>
> @@ -229,9 +229,27 @@ enum pipe_format {
> PIPE_FORMAT_L32A32_FLOAT= 161,
> PIPE_FORMAT_I32_FLOAT = 162,
>
> + PIPE_FORMAT_YV12= 163,
> + PIPE_FORMAT_YV16= 164,
> + PIPE_FORMAT_IYUV= 165, /**< aka I420 */
> + PIPE_FORMAT_NV12= 166,
> + PIPE_FORMAT_NV21= 167,
> + PIPE_FORMAT_AYUV= PIPE_FORMAT_A8R8G8B8_UNORM,
> + PIPE_FORMAT_VUYA= PIPE_FORMAT_B8G8R8A8_UNORM,
> + PIPE_FORMAT_XYUV= PIPE_FORMAT_X8R8G8B8_UNORM,
> + PIPE_FORMAT_VUYX= PIPE_FORMAT_B8G8R8X8_UNORM,
> + PIPE_FORMAT_IA44= 168,
> + PIPE_FORMAT_AI44= 169,
> +
> PIPE_FORMAT_COUNT
> };
> Defining these formats as another format feels wrong. There might be
> reasons why you'd want to use them in normal 3d contexts (ok maybe
> not
> really) but if you can't distinguish the format that's a no go.
Yes this is also incorrect. Blitting from PIPE_FORMAT_AYUV to
PIPE_FORMAT_A8R8G8B8_UNORM is not a no-op.
I actually have llvmpipe AYUV support implemented in a private branch.
> Frankly I'm not sure if all these formats really should be simple
> PIPE_FORMATs even, since chances you can use them in normal 3d
> contexts
> are next to zero anyway (especially the planar stuff hurts).
That's fine. Pixel formats just need to uniquely describe out to interpret the
pixels. A 3d context doesn't need to support all of them.
I'll see
> though where that's coming from (as pipe_surface, pipe_sampler_state
> and
> friends are reused, even though the entry points are not). Though I'm
> not sure the all-new-entry points with reused gallium structs is
> really
> the right approach. Maybe if you need separate contexts etc. anyway
> (to
> be able to exploit video hardware) it would be better if you'd just
> use
> all your own structs better suited for video tasks. The vl code could
> then translate that stuff to "normal" gallium.
> If others are happy with the interface, I won't object though. I've
> no
> clue really how a better interface would look like...
My gut feel looking at [1] is that pipe_video_context interface should be
either an extension of pipe_context, or optional entry-points in pipe_context.
Because there's a lot of functionality needed for a pipe_context (low level
resource management, relocations, fences), that will be definitely useful for
video processing too. And instead of duplicating/mirroring entry-points the
existing entry-points should be enlarged to convey the necessary semantics.
But honestly, why don't we simply move pipe_video_context out of
src/gallium/include into the state tracker for the time being, and leave the
admittedly complex problem of designing the gallium interface until there is an
actual use case / proof-of-concept in hardware? This means we can use the video
state tracker without having to make boiler plate changes for every single pipe
driver, nor advertising an interface for which there's no confidence it is
adequate.
Jose
[1] http://msdn.microsoft.
[Mesa-dev] [PATCH] linker: Reject shaders that use too many varyings
From: Ian Romanick
Previously it was up to the driver or later code generator to reject
these shaders. It turns out that nobody did this.
This will need changes to support geometry shaders.
NOTE: This is a candidate for the stable branches.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37743
---
src/glsl/linker.cpp | 55 ++
1 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/src/glsl/linker.cpp b/src/glsl/linker.cpp
index 255edc6..eaa6412 100644
--- a/src/glsl/linker.cpp
+++ b/src/glsl/linker.cpp
@@ -1405,8 +1405,9 @@ demote_shader_inputs_and_outputs(gl_shader *sh, enum
ir_variable_mode mode)
}
-void
-assign_varying_locations(struct gl_shader_program *prog,
+bool
+assign_varying_locations(struct gl_context *ctx,
+struct gl_shader_program *prog,
gl_shader *producer, gl_shader *consumer)
{
/* FINISHME: Set dynamically when geometry shader support is added. */
@@ -1462,6 +1463,9 @@ assign_varying_locations(struct gl_shader_program *prog,
}
}
+ unsigned float_components = 0;
+ unsigned varying_vectors = 0;
+
foreach_list(node, consumer->ir) {
ir_variable *const var = ((ir_instruction *) node)->as_variable();
@@ -1492,8 +1496,45 @@ assign_varying_locations(struct gl_shader_program *prog,
* value is written by the previous stage.
*/
var->mode = ir_var_auto;
+ } else {
+if (var->type->is_array()) {
+ if (var->type->is_matrix()) {
+ varying_vectors += var->type->array_size()
+ * var->type->matrix_columns;
+ float_components += var->type->array_size()
+ * var->type->matrix_columns * 4;
+ } else {
+ varying_vectors += var->type->array_size();
+ float_components += var->type->array_size() * 4;
+ }
+} else if (var->type->is_matrix()) {
+ varying_vectors += var->type->matrix_columns;
+ float_components += var->type->matrix_columns * 4;
+} else {
+ varying_vectors++;
+ float_components += var->type->vector_elements;
+}
+ }
+ }
+
+ printf("varyings = %u, %u\n", varying_vectors, float_components);
+ if (ctx->API == API_OPENGLES2 || prog->Version == 100) {
+ if (varying_vectors > ctx->Const.MaxVarying) {
+linker_error_printf(prog, "shader uses too many varying vectors "
+"(%u > %u)\n",
+varying_vectors, ctx->Const.MaxVarying);
+return false;
+ }
+ } else {
+ if (float_components > ctx->Const.MaxVarying * 4) {
+linker_error_printf(prog, "shader uses too many varying components "
+"(%u > %u)\n",
+float_components, ctx->Const.MaxVarying * 4);
+return false;
}
}
+
+ return true;
}
@@ -1666,9 +1707,13 @@ link_shaders(struct gl_context *ctx, struct
gl_shader_program *prog)
if (prog->_LinkedShaders[i] == NULL)
continue;
- assign_varying_locations(prog,
- prog->_LinkedShaders[prev],
- prog->_LinkedShaders[i]);
+ if (!assign_varying_locations(ctx, prog,
+ prog->_LinkedShaders[prev],
+ prog->_LinkedShaders[i])) {
+prog->LinkStatus = false;
+goto done;
+ }
+
prev = i;
}
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] i965: fix mask used to write to clip distance registers when gen>6
On 13 June 2011 09:58, Eric Anholt wrote: > On Sun, 12 Jun 2011 21:14:50 -0700, Paul Berry > wrote: >> In gen6 and above, clip distances 0-3 are written to message register >> 3's xyzw components, and 4-7 to message register 4's xyzw components. >> Therefore when when writing the clip distances we need to examine the >> lower 2 bits of the clip distance index to see which component to >> write to. >> >> emit_vertex_write() was examining the lower 3 bits, causing clip >> distances 4-7 not to be written correctly. > > Reviewed-by: Eric Anholt > > Is this caught by any new testcase? It's not a requirement, just > thinking that since you were building testcases like this recently, it > might be easy. > Yes, agreed. It's caught by vs-clip-vertex-01.shader_test, which I sent to the piglit list earlier that day. The patch hasn't landed yet. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] llvmpipe: SSE2 fastpaths for b8g8r8x8 {un, }swizzle
Good catch!
Jose
- Original Message -
> Copy-and-paste from the bgra cases. The C paths attempt to avoid
> copying the 'x' channel, but it's harmless, you might as well. Good
> for
> about 5% in glxgears (740 to 780 fps).
>
> Signed-off-by: Adam Jackson
> ---
> src/gallium/drivers/llvmpipe/lp_tile_soa.py | 68
> ++-
> 1 files changed, 66 insertions(+), 2 deletions(-)
>
> diff --git a/src/gallium/drivers/llvmpipe/lp_tile_soa.py
> b/src/gallium/drivers/llvmpipe/lp_tile_soa.py
> index 8df7b23..f4324e6 100644
> --- a/src/gallium/drivers/llvmpipe/lp_tile_soa.py
> +++ b/src/gallium/drivers/llvmpipe/lp_tile_soa.py
> @@ -423,6 +423,70 @@ lp_tile_b8g8r8a8_unorm_unswizzle_4ub_sse2(const
> uint8_t * restrict src,
> }
> }
>
> +static void
> +lp_tile_b8g8r8x8_unorm_swizzle_4ub_sse2(uint8_t * restrict dst,
> +const uint8_t * restrict
> src, unsigned src_stride,
> +unsigned x0, unsigned y0)
> +{
> + __m128i *dst128 = (__m128i *) dst;
> + unsigned x, y;
> +
> + src += y0 * src_stride;
> + src += x0 * sizeof(uint32_t);
> +
> + for (y = 0; y < TILE_SIZE; y += 4) {
> + const uint8_t *src_row = src;
> +
> + for (x = 0; x < TILE_SIZE; x += 4) {
> + swz4((const __m128i *) (src_row + 0 * src_stride),
> + (const __m128i *) (src_row + 1 * src_stride),
> + (const __m128i *) (src_row + 2 * src_stride),
> + (const __m128i *) (src_row + 3 * src_stride),
> + dst128 + 2, /* b */
> + dst128 + 1, /* g */
> + dst128 + 0, /* r */
> + dst128 + 3);/* a */
> +
> + dst128 += 4;
> + src_row += sizeof(__m128i);
> + }
> +
> + src += 4 * src_stride;
> + }
> +}
> +
> +static void
> +lp_tile_b8g8r8x8_unorm_unswizzle_4ub_sse2(const uint8_t * restrict
> src,
> + uint8_t * restrict dst,
> unsigned dst_stride,
> + unsigned x0, unsigned y0)
> +{
> + unsigned int x, y;
> + const __m128i *src128 = (const __m128i *) src;
> +
> + dst += y0 * dst_stride;
> + dst += x0 * sizeof(uint32_t);
> +
> + for (y = 0; y < TILE_SIZE; y += 4) {
> + const uint8_t *dst_row = dst;
> +
> + for (x = 0; x < TILE_SIZE; x += 4) {
> + unswz4( &src128[2], /* b */
> + &src128[1], /* g */
> + &src128[0], /* r */
> + &src128[3], /* a */
> + (__m128i *) (dst_row + 0 * dst_stride),
> + (__m128i *) (dst_row + 1 * dst_stride),
> + (__m128i *) (dst_row + 2 * dst_stride),
> + (__m128i *) (dst_row + 3 * dst_stride));
> +
> + src128 += 4;
> + dst_row += sizeof(__m128i);;
> + }
> +
> + dst += 4 * dst_stride;
> + }
> +}
> +
> #endif /* PIPE_ARCH_SSE */
> '''
>
> @@ -446,7 +510,7 @@ def generate_swizzle(formats, dst_channel,
> dst_native_type, dst_suffix):
> if is_format_supported(format):
> print ' case %s:' % format.name
> func_name = 'lp_tile_%s_swizzle_%s' %
> (format.short_name(), dst_suffix)
> -if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM':
> +if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM' or
> format.name == 'PIPE_FORMAT_B8G8R8X8_UNORM':
> print '#ifdef PIPE_ARCH_SSE'
> print ' func = util_cpu_caps.has_sse2 ? %s_sse2
> : %s;' % (func_name, func_name)
> print '#else'
> @@ -484,7 +548,7 @@ def generate_unswizzle(formats, src_channel,
> src_native_type, src_suffix):
> if is_format_supported(format):
> print ' case %s:' % format.name
> func_name = 'lp_tile_%s_unswizzle_%s' %
> (format.short_name(), src_suffix)
> -if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM':
> +if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM' or
> format.name == 'PIPE_FORMAT_B8G8R8X8_UNORM':
> print '#ifdef PIPE_ARCH_SSE'
> print ' func = util_cpu_caps.has_sse2 ? %s_sse2
> : %s;' % (func_name, func_name)
> print '#else'
> --
> 1.7.5.2
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: Alias glXFreeContextEXT to glXDestroyContext
Signed-off-by: Adam Jackson
---
src/glx/glxcmds.c | 20 ++--
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index ab6b61a..e4356dd 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -354,8 +354,9 @@ glx_send_destroy_context(Display *dpy, XID xid)
/*
** Destroy the named context
*/
-static void
-DestroyContext(Display * dpy, GLXContext ctx)
+
+_X_EXPORT void
+glXDestroyContext(Display * dpy, GLXContext ctx)
{
struct glx_context *gc = (struct glx_context *) ctx;
@@ -381,12 +382,6 @@ DestroyContext(Display * dpy, GLXContext ctx)
gc->vtable->destroy(gc);
}
-_X_EXPORT void
-glXDestroyContext(Display * dpy, GLXContext gc)
-{
- DestroyContext(dpy, gc);
-}
-
/*
** Return the major and minor version #s for the GLX extension
*/
@@ -1494,12 +1489,9 @@ _X_EXPORT GLXContextID glXGetContextIDEXT(const
GLXContext ctx_user)
return ctx->xid;
}
-_X_EXPORT void
-glXFreeContextEXT(Display * dpy, GLXContext ctx)
-{
- DestroyContext(dpy, ctx);
-}
-
+_X_EXPORT
+GLX_ALIAS_VOID(glXFreeContextEXT, (Display *dpy, GLXContext ctx), (dpy, ctx),
+ glXDestroyContext);
_X_EXPORT GLXFBConfig *
glXChooseFBConfig(Display * dpy, int screen,
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] intel: Clean up intel_render_texture with a rename and a helper function.
On Fri, 10 Jun 2011 13:56:44 -0700, Eric Anholt wrote:
> On Fri, 10 Jun 2011 12:58:12 -0700, Kenneth Graunke
> wrote:
> > On 06/07/2011 11:47 AM, Eric Anholt wrote:
> > > The "newImage" isn't particularly new -- it might be the same texture
> > > that was attached to the same attachment point before. This function
> > > also gets called when just rebinding back to an FBO with a texture
> > > attachment.
> > > ---
> > > src/mesa/drivers/dri/intel/intel_fbo.c | 16 ++--
> > > 1 files changed, 6 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/src/mesa/drivers/dri/intel/intel_fbo.c
> > > b/src/mesa/drivers/dri/intel/intel_fbo.c
> > > index 0a67caa..8fda37b 100644
> > > --- a/src/mesa/drivers/dri/intel/intel_fbo.c
> > > +++ b/src/mesa/drivers/dri/intel/intel_fbo.c
> > > @@ -567,16 +567,12 @@ intel_render_texture(struct gl_context * ctx,
> > >struct gl_framebuffer *fb,
> > >struct gl_renderbuffer_attachment *att)
> > > {
> > > - struct gl_texture_image *newImage
> > > - = att->Texture->Image[att->CubeMapFace][att->TextureLevel];
> > > + struct gl_texture_image *image = _mesa_get_attachment_teximage(att);
> > > struct intel_renderbuffer *irb =
> > > intel_renderbuffer(att->Renderbuffer);
> > > - struct intel_texture_image *intel_image;
> > > + struct intel_texture_image *intel_image = intel_texture_image(image);
> > >
> > > (void) fb;
> > >
> > > - ASSERT(newImage);
> > > -
> > > - intel_image = intel_texture_image(newImage);
> > > if (!intel_image->mt) {
> > > /* Fallback on drawing to a texture that doesn't have a miptree
> > > * (has a border, width/height 0, etc.)
> > > @@ -586,7 +582,7 @@ intel_render_texture(struct gl_context * ctx,
> >
> > Any particular reason for removing the assertion?
>
> Trying not to confuse people about there being some risk here. :)
>
> > Patch 4 seems to be fixing a bug, but I don't see any statement of
> > impact on either piglit or applications. Was this actually breaking
> > something in the wild, or just found by inspection (and allergic
> > reactions to piles of yak hair)? :)
>
> Mostly just trying to increase sanity of the code. No more "This code
> is written in an absurd fashion, and would be better after the patch>."
I have encountered so many spurious assertions lately. They are more
misleading than they are helpful. Thanks for eliminating one.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] intel: Do the drawable x/y offset in intel_renderbuffer_map() for spans.
On Tue, 7 Jun 2011 11:47:14 -0700, Eric Anholt wrote:
> We were mapping the renderbuffer once, then walking over all the
> buffers to map just the texture ones using the other texture mapping
> function that handled the x/y offset to the image in the region. But
> then we would go and overwrite *those* mappings with the original
> mappings for depth/stencil, which was wrong.
>
> Instead, just walk over the attachments once and map the attachments.
> Wasn't that easy?
> ---
> src/mesa/drivers/dri/intel/intel_span.c | 87 --
> 1 files changed, 23 insertions(+), 64 deletions(-)
>
> diff --git a/src/mesa/drivers/dri/intel/intel_span.c
> b/src/mesa/drivers/dri/intel/intel_span.c
> index 8978129..92a7586 100644
> --- a/src/mesa/drivers/dri/intel/intel_span.c
> +++ b/src/mesa/drivers/dri/intel/intel_span.c
> @@ -122,10 +122,16 @@ intel_renderbuffer_map(struct intel_context *intel,
> struct gl_renderbuffer *rb)
> rb->Data = irb->region->buffer->virtual;
> rb->RowStride = irb->region->pitch;
>
> - /* Flip orientation if it's the window system buffer */
> if (!rb->Name) {
> + /* Flip orientation of the window system buffer */
>rb->Data += rb->RowStride * (irb->region->height - 1) *
> irb->region->cpp;
>rb->RowStride = -rb->RowStride;
> + } else {
> + /* Adjust the base pointer of a texture image drawbuffer to the image
> + * within the miptree region (all else has draw_x/y = 0).
> + */
> + rb->Data += irb->draw_x * irb->region->cpp;
> + rb->Data += irb->draw_y * rb->RowStride * irb->region->cpp;
> }
>
> intel_set_span_functions(intel, rb);
> @@ -148,71 +154,26 @@ intel_renderbuffer_unmap(struct intel_context *intel,
> rb->RowStride = 0;
> }
>
> -/**
> - * Map or unmap all the renderbuffers which we may need during
> - * software rendering.
> - * XXX in the future, we could probably convey extra information to
> - * reduce the number of mappings needed. I.e. if doing a glReadPixels
> - * from the depth buffer, we really only need one mapping.
> - *
> - * XXX Rewrite this function someday.
> - * We can probably just loop over all the renderbuffer attachments,
> - * map/unmap all of them, and not worry about the _ColorDrawBuffers
> - * _ColorReadBuffer, _DepthBuffer or _StencilBuffer fields.
> - */
> static void
> -intel_map_unmap_framebuffer(struct intel_context *intel,
> - struct gl_framebuffer *fb,
> - GLboolean map)
> +intel_framebuffer_map(struct intel_context *intel, struct gl_framebuffer *fb)
> {
> - GLuint i;
> -
> - /* color draw buffers */
> - for (i = 0; i < fb->_NumColorDrawBuffers; i++) {
> - if (map)
> - intel_renderbuffer_map(intel, fb->_ColorDrawBuffers[i]);
> - else
> - intel_renderbuffer_unmap(intel, fb->_ColorDrawBuffers[i]);
> - }
> -
> - /* color read buffer */
> - if (map)
> - intel_renderbuffer_map(intel, fb->_ColorReadBuffer);
> - else
> - intel_renderbuffer_unmap(intel, fb->_ColorReadBuffer);
> + int i;
>
> - /* check for render to textures */
> for (i = 0; i < BUFFER_COUNT; i++) {
> - struct gl_renderbuffer_attachment *att =
> - fb->Attachment + i;
> - struct gl_texture_object *tex = att->Texture;
> - if (tex) {
> - /* render to texture */
> - ASSERT(att->Renderbuffer);
> - if (map)
> -intel_tex_map_images(intel, intel_texture_object(tex));
> - else
> -intel_tex_unmap_images(intel, intel_texture_object(tex));
> - }
> + intel_renderbuffer_map(intel, fb->Attachment[i].Renderbuffer);
> }
>
> - /* depth buffer (Note wrapper!) */
> - if (fb->_DepthBuffer) {
> - if (map)
> - intel_renderbuffer_map(intel, fb->_DepthBuffer->Wrapped);
> - else
> - intel_renderbuffer_unmap(intel, fb->_DepthBuffer->Wrapped);
> - }
> + intel_check_front_buffer_rendering(intel);
> +}
>
> - /* stencil buffer (Note wrapper!) */
> - if (fb->_StencilBuffer) {
> - if (map)
> - intel_renderbuffer_map(intel, fb->_StencilBuffer->Wrapped);
> - else
> - intel_renderbuffer_unmap(intel, fb->_StencilBuffer->Wrapped);
> - }
> +static void
> +intel_framebuffer_unmap(struct intel_context *intel, struct gl_framebuffer
> *fb)
> +{
> + int i;
>
> - intel_check_front_buffer_rendering(intel);
> + for (i = 0; i < BUFFER_COUNT; i++) {
> + intel_renderbuffer_unmap(intel, fb->Attachment[i].Renderbuffer);
> + }
> }
>
> /**
> @@ -239,9 +200,8 @@ intelSpanRenderStart(struct gl_context * ctx)
>}
> }
>
> - intel_map_unmap_framebuffer(intel, ctx->DrawBuffer, GL_TRUE);
> - if (ctx->ReadBuffer != ctx->DrawBuffer)
> - intel_map_unmap_framebuffer(intel, ctx->ReadBuffer, GL_TRUE);
> + intel_framebuffer_map(intel, ctx->DrawBuffer);
> + intel_framebuffer_map(intel, ctx->ReadBuffer);
> }
I think this hunk should be:
@@ -239
Re: [Mesa-dev] [PATCH 1/4] intel: Move the draw_x/draw_y to the renderbuffer where it belongs.
On Tue, 7 Jun 2011 11:47:11 -0700, Eric Anholt wrote: > It was originally located in the region because the tracking of > depth/color buffers was on the regions, and getting back to the irb > would have been tricky. Now, we're keying off of the renderbuffer in > more places, which means we can move these fields where they belong. > > This could fix potential rendering failure with a single texture > having multiple images attached to different renderbuffers across > shareCtx (as far as I can tell, this was the only failure we could > cause, since anything else should trigger intel_render_texture in > between, for example a BindFramebuffer). > --- > src/mesa/drivers/dri/i915/i830_vtbl.c | 28 +++ > src/mesa/drivers/dri/i915/i915_vtbl.c | 28 +++ > src/mesa/drivers/dri/i965/brw_misc_state.c|2 +- > src/mesa/drivers/dri/i965/brw_wm_surface_state.c |2 +- > src/mesa/drivers/dri/i965/gen7_misc_state.c | 19 > src/mesa/drivers/dri/i965/gen7_wm_surface_state.c |2 +- > src/mesa/drivers/dri/intel/intel_blit.c |8 ++-- > src/mesa/drivers/dri/intel/intel_fbo.c| 53 +--- > src/mesa/drivers/dri/intel/intel_fbo.h|8 +++- > src/mesa/drivers/dri/intel/intel_regions.c| 35 -- > src/mesa/drivers/dri/intel/intel_regions.h|7 --- > src/mesa/drivers/dri/intel/intel_tex_copy.c |2 +- > 12 files changed, 106 insertions(+), 88 deletions(-) Reviewed-by: Chad Versace pgp7WYewDR8Zn.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 3/4] intel: Use rb->Data and rb->RowStride to handle spans Y flipping.
On Tue, 7 Jun 2011 11:47:13 -0700, Eric Anholt wrote: > This is already pointing at 0 or Height - 1 and with an appropriate > pitch, so no need to recompute those values per customization of the > spans code. Cuts 3 out of 21kb of the compiled size. > --- > src/mesa/drivers/dri/intel/intel_span.c | 11 --- > 1 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/src/mesa/drivers/dri/intel/intel_span.c > b/src/mesa/drivers/dri/intel/intel_span.c > index 5290342..8978129 100644 > --- a/src/mesa/drivers/dri/intel/intel_span.c > +++ b/src/mesa/drivers/dri/intel/intel_span.c > @@ -50,21 +50,18 @@ intel_set_span_functions(struct intel_context *intel, > > #define LOCAL_VARS \ > struct intel_renderbuffer *irb = intel_renderbuffer(rb); \ > - const GLint yScale = rb->Name ? 1 : -1; \ > - const GLint yBias = rb->Name ? 0 : rb->Height - 1; > \ > int minx = 0, miny = 0; \ > int maxx = rb->Width; \ > int maxy = rb->Height;\ > - int pitch = irb->region->pitch * irb->region->cpp; > \ > - void *buf = irb->region->buffer->virtual; \ > + int pitch = rb->RowStride * irb->region->cpp; \ > + void *buf = rb->Data; \ > GLuint p; \ > - (void) p; \ > - (void)buf; (void)pitch; /* unused for non-gttmap. */ > \ > + (void) p; Since you immediately void out p, why even declare it? > > #define HW_CLIPLOOP() > #define HW_ENDCLIPLOOP() > > -#define Y_FLIP(_y) ((_y) * yScale + yBias) > +#define Y_FLIP(_y) (_y) > > #define HW_LOCK() I also wanted to clean this up when defining the S8 span functions, but was afraidof breaking things. You, sir, are not afraid of breaking things. With the declaration of p killed, this is Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/4] intel: Clean up intel_render_texture with a rename and a helper function.
On Tue, 7 Jun 2011 11:47:12 -0700, Eric Anholt wrote: > The "newImage" isn't particularly new -- it might be the same texture > that was attached to the same attachment point before. This function > also gets called when just rebinding back to an FBO with a texture > attachment. > --- > src/mesa/drivers/dri/intel/intel_fbo.c | 16 ++-- > 1 files changed, 6 insertions(+), 10 deletions(-) Reviewed-by: Chad Versace ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] llvmpipe: SSE2 fastpaths for b8g8r8x8 {un, }swizzle
Copy-and-paste from the bgra cases. The C paths attempt to avoid
copying the 'x' channel, but it's harmless, you might as well. Good for
about 5% in glxgears (740 to 780 fps).
Signed-off-by: Adam Jackson
---
src/gallium/drivers/llvmpipe/lp_tile_soa.py | 68 ++-
1 files changed, 66 insertions(+), 2 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_tile_soa.py
b/src/gallium/drivers/llvmpipe/lp_tile_soa.py
index 8df7b23..f4324e6 100644
--- a/src/gallium/drivers/llvmpipe/lp_tile_soa.py
+++ b/src/gallium/drivers/llvmpipe/lp_tile_soa.py
@@ -423,6 +423,70 @@ lp_tile_b8g8r8a8_unorm_unswizzle_4ub_sse2(const uint8_t *
restrict src,
}
}
+static void
+lp_tile_b8g8r8x8_unorm_swizzle_4ub_sse2(uint8_t * restrict dst,
+const uint8_t * restrict src, unsigned
src_stride,
+unsigned x0, unsigned y0)
+{
+ __m128i *dst128 = (__m128i *) dst;
+ unsigned x, y;
+
+ src += y0 * src_stride;
+ src += x0 * sizeof(uint32_t);
+
+ for (y = 0; y < TILE_SIZE; y += 4) {
+ const uint8_t *src_row = src;
+
+ for (x = 0; x < TILE_SIZE; x += 4) {
+ swz4((const __m128i *) (src_row + 0 * src_stride),
+ (const __m128i *) (src_row + 1 * src_stride),
+ (const __m128i *) (src_row + 2 * src_stride),
+ (const __m128i *) (src_row + 3 * src_stride),
+ dst128 + 2, /* b */
+ dst128 + 1, /* g */
+ dst128 + 0, /* r */
+ dst128 + 3);/* a */
+
+ dst128 += 4;
+ src_row += sizeof(__m128i);
+ }
+
+ src += 4 * src_stride;
+ }
+}
+
+static void
+lp_tile_b8g8r8x8_unorm_unswizzle_4ub_sse2(const uint8_t * restrict src,
+ uint8_t * restrict dst, unsigned
dst_stride,
+ unsigned x0, unsigned y0)
+{
+ unsigned int x, y;
+ const __m128i *src128 = (const __m128i *) src;
+
+ dst += y0 * dst_stride;
+ dst += x0 * sizeof(uint32_t);
+
+ for (y = 0; y < TILE_SIZE; y += 4) {
+ const uint8_t *dst_row = dst;
+
+ for (x = 0; x < TILE_SIZE; x += 4) {
+ unswz4( &src128[2], /* b */
+ &src128[1], /* g */
+ &src128[0], /* r */
+ &src128[3], /* a */
+ (__m128i *) (dst_row + 0 * dst_stride),
+ (__m128i *) (dst_row + 1 * dst_stride),
+ (__m128i *) (dst_row + 2 * dst_stride),
+ (__m128i *) (dst_row + 3 * dst_stride));
+
+ src128 += 4;
+ dst_row += sizeof(__m128i);;
+ }
+
+ dst += 4 * dst_stride;
+ }
+}
+
#endif /* PIPE_ARCH_SSE */
'''
@@ -446,7 +510,7 @@ def generate_swizzle(formats, dst_channel, dst_native_type,
dst_suffix):
if is_format_supported(format):
print ' case %s:' % format.name
func_name = 'lp_tile_%s_swizzle_%s' % (format.short_name(),
dst_suffix)
-if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM':
+if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM' or format.name ==
'PIPE_FORMAT_B8G8R8X8_UNORM':
print '#ifdef PIPE_ARCH_SSE'
print ' func = util_cpu_caps.has_sse2 ? %s_sse2 : %s;' %
(func_name, func_name)
print '#else'
@@ -484,7 +548,7 @@ def generate_unswizzle(formats, src_channel,
src_native_type, src_suffix):
if is_format_supported(format):
print ' case %s:' % format.name
func_name = 'lp_tile_%s_unswizzle_%s' % (format.short_name(),
src_suffix)
-if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM':
+if format.name == 'PIPE_FORMAT_B8G8R8A8_UNORM' or format.name ==
'PIPE_FORMAT_B8G8R8X8_UNORM':
print '#ifdef PIPE_ARCH_SSE'
print ' func = util_cpu_caps.has_sse2 ? %s_sse2 : %s;' %
(func_name, func_name)
print '#else'
--
1.7.5.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: move texrender.c to swrast
On 06/13/2011 10:59 AM, Eric Anholt wrote: On Fri, 10 Jun 2011 20:37:21 -0600, Brian Paul wrote: This stuff is really for software rendering, it's not core Mesa. A small step toward pushing the FetchTexel() stuff down into swrast. Reviewed-by: Eric Anholt Do we feel the same about the other renderbuffer accessors? Yeah. I want to eventually get rid of all the renderbuffer Get/PutRow(), etc functions in gl_renderbuffer and FetchTexel() in gl_texture_image. Texture images and renderbuffers should be merged or share a common buffer abstraction. Accesses to texture images and renderbuffers for reading/writing pixel data should be done though Map/Unmap() functions. Basically, do things like in Gallium. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 4/4] intel: Do the drawable x/y offset in intel_renderbuffer_map() for spans.
On Sun, 12 Jun 2011 22:36:04 -0700, Chad Versace wrote: > On Tue, 7 Jun 2011 11:47:14 -0700, Eric Anholt wrote: > > We were mapping the renderbuffer once, then walking over all the > > buffers to map just the texture ones using the other texture mapping > > function that handled the x/y offset to the image in the region. But > > then we would go and overwrite *those* mappings with the original > > mappings for depth/stencil, which was wrong. > > > > Instead, just walk over the attachments once and map the attachments. > > Wasn't that easy? > > --- > > src/mesa/drivers/dri/intel/intel_span.c | 87 > > -- > > 1 files changed, 23 insertions(+), 64 deletions(-) > > > > diff --git a/src/mesa/drivers/dri/intel/intel_span.c > > b/src/mesa/drivers/dri/intel/intel_span.c > > index 8978129..92a7586 100644 > > --- a/src/mesa/drivers/dri/intel/intel_span.c > > +++ b/src/mesa/drivers/dri/intel/intel_span.c > > @@ -239,9 +200,8 @@ intelSpanRenderStart(struct gl_context * ctx) > >} > > } > > > > - intel_map_unmap_framebuffer(intel, ctx->DrawBuffer, GL_TRUE); > > - if (ctx->ReadBuffer != ctx->DrawBuffer) > > - intel_map_unmap_framebuffer(intel, ctx->ReadBuffer, GL_TRUE); > > + intel_framebuffer_map(intel, ctx->DrawBuffer); > > + intel_framebuffer_map(intel, ctx->ReadBuffer); > > } > > I think this hunk should be: > > @@ -239,9 +200,8 @@ intelSpanRenderStart(struct gl_context * ctx) >} > } > > - intel_map_unmap_framebuffer(intel, ctx->DrawBuffer, GL_TRUE); > + intel_framebuffer_map(intel, ctx->DrawBuffer); > - if (ctx->ReadBuffer != ctx->DrawBuffer) > - intel_map_unmap_framebuffer(intel, ctx->ReadBuffer, GL_TRUE); > + intel_framebuffer_map(intel, ctx->ReadBuffer); > } > > There's no reason to re-map the read buffer if we've already done so. Nice catch. I like it. pgpiqv8zYwg5D.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] mesa: move texrender.c to swrast
On Fri, 10 Jun 2011 20:37:21 -0600, Brian Paul wrote: > This stuff is really for software rendering, it's not core Mesa. > A small step toward pushing the FetchTexel() stuff down into swrast. Reviewed-by: Eric Anholt Do we feel the same about the other renderbuffer accessors? pgpv5kaTt2V5E.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 3/4] intel: Use rb->Data and rb->RowStride to handle spans Y flipping.
On Sun, 12 Jun 2011 22:28:08 -0700, Chad Versace wrote: > On Tue, 7 Jun 2011 11:47:13 -0700, Eric Anholt wrote: > > This is already pointing at 0 or Height - 1 and with an appropriate > > pitch, so no need to recompute those values per customization of the > > spans code. Cuts 3 out of 21kb of the compiled size. > > --- > > src/mesa/drivers/dri/intel/intel_span.c | 11 --- > > 1 files changed, 4 insertions(+), 7 deletions(-) > > > > diff --git a/src/mesa/drivers/dri/intel/intel_span.c > > b/src/mesa/drivers/dri/intel/intel_span.c > > index 5290342..8978129 100644 > > --- a/src/mesa/drivers/dri/intel/intel_span.c > > +++ b/src/mesa/drivers/dri/intel/intel_span.c > > @@ -50,21 +50,18 @@ intel_set_span_functions(struct intel_context *intel, > > > > #define LOCAL_VARS \ > > struct intel_renderbuffer *irb = intel_renderbuffer(rb); > > \ > > - const GLint yScale = rb->Name ? 1 : -1; \ > > - const GLint yBias = rb->Name ? 0 : rb->Height - 1; > > \ > > int minx = 0, miny = 0; \ > > int maxx = rb->Width; \ > > int maxy = rb->Height; \ > > - int pitch = irb->region->pitch * irb->region->cpp; > > \ > > - void *buf = irb->region->buffer->virtual; > > \ > > + int pitch = rb->RowStride * irb->region->cpp; \ > > + void *buf = rb->Data; \ > > GLuint p; > > \ > > - (void) p; > > \ > > - (void)buf; (void)pitch; /* unused for non-gttmap. */ > > \ > > + (void) p; > > Since you immediately void out p, why even declare it? It's used in half of the callers of this macro, but not the other half. The "(void)" suppresses unused variable warnings. pgp7c5tYUPnCY.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 10/11] intel: Drop dead preinitialization of align_w, align_h.
On Fri, 10 Jun 2011 18:10:13 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/10/2011 01:38 PM, Eric Anholt wrote:
> > ---
> > src/mesa/drivers/dri/intel/intel_tex_layout.c |4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/src/mesa/drivers/dri/intel/intel_tex_layout.c
> > b/src/mesa/drivers/dri/intel/intel_tex_layout.c
> > index 7493b42..2002777 100644
> > --- a/src/mesa/drivers/dri/intel/intel_tex_layout.c
> > +++ b/src/mesa/drivers/dri/intel/intel_tex_layout.c
> > @@ -57,7 +57,7 @@ void i945_miptree_layout_2d(struct intel_context *intel,
> > struct intel_mipmap_tree *mt,
> > uint32_t tiling, int nr_images)
> > {
> > - GLuint align_h = 2, align_w = 4;
> > + GLuint align_h, align_w;
> > GLuint level;
> > GLuint x = 0;
> > GLuint y = 0;
> > @@ -101,7 +101,7 @@ void i945_miptree_layout_2d(struct intel_context *intel,
> >height, 1);
> >
> >if (mt->compressed)
> > -img_height = MAX2(1, height/4);
> > +img_height = MAX2(1, height + 3/4);
>
> Is this hunk accidental or just missing from the commit message? I'm
> guessing the later.
Accidental -- the correct fix (without the obvious bug) appears in the
next commit.
pgpjFKedI1ZHY.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] i965: fix mask used to write to clip distance registers when gen>6
On Sun, 12 Jun 2011 21:14:50 -0700, Paul Berry wrote: > In gen6 and above, clip distances 0-3 are written to message register > 3's xyzw components, and 4-7 to message register 4's xyzw components. > Therefore when when writing the clip distances we need to examine the > lower 2 bits of the clip distance index to see which component to > write to. > > emit_vertex_write() was examining the lower 3 bits, causing clip > distances 4-7 not to be written correctly. Reviewed-by: Eric Anholt Is this caught by any new testcase? It's not a requirement, just thinking that since you were building testcases like this recently, it might be easy. pgpIgojU2HzAw.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] glxinfo: add support for creating/querying core-profile contexts
2011/6/13 Brian Paul :
> On 06/12/2011 12:56 PM, Gustaw Smolarczyk wrote:
>>
>> I found some bugs in this code.
>>
>> 2011/6/11 Brian Paul:
>>>
>>> The -c flag says to try to create a core profile (no legacy features)
>>> using glXCreateContextAttribsARB(). A core profile may advertise a
>>> different set of extensions than a compatibility profile (though,
>>> the only difference with NVIDIA's driver is the presence of
>>> GL_ARB_compatibility). Also note that extensions need to be queried
>>> one at a time with glGetStringi().
>
>
>>> + /* install X error handler */
>>> + old_handler = XSetErrorHandler(create_context_error_handler);
>>> + CreateContextErrorFlag = False;
>>> +
>>> + /* try creating context */
>>> + context = glXCreateContextAttribsARB_func(dpy,
>>> + fbconfig,
>>> + 0, /* share_context */
>>> + True, /* direct */
>>> + attribs);
>>> +
>>> + /* restore error handler */
>>> + XSetErrorHandler(old_handler);
>>> +
>>> + if (CreateContextErrorFlag)
>>> + context = 0;
>>
>> The context should be tested against being direct. For example, fglrx
>> will happily create "4.2" context, but it will be just default
>> indirect one.
>
> So you see "OpenGL version string: 4.2" in the output? That really
> shouldn't happen. Seems like that's a fgrlx bug.
Not really. It's 2.1 context, but indirect. However, it's still
"valid", so the caller thinks that it created 4.2 core profile context
and doesn't try to create 4.1, 4.0, and so on.
>
>
>
>>> + if (coreProfile) {
>>> + /* Try to create a core profile, starting with the newest version
>>> of
>>> + * GL that we're aware of. If we don't specify the version
>>> + */
>>> + int i;
>>> + for (i = NUM_GL_VERSIONS - 2; i> 0 ; i--) {
>>> + ctx = create_context_flags(dpy, config,
>>> + gl_versions[i].major,
>>> + gl_versions[i].minor,
>>> + 0x0,
>>> + GLX_CONTEXT_CORE_PROFILE_BIT_ARB);
>>> + if (ctx)
>>> + break;
>>> + }
>>> + if (!ctx) {
>>> + /* couldn't get core profile context */
>>> + return 0;
>>> + }
>>
>> There's something missing here. If ctx is not NULL, it will be
>> overwritten by code below. There should be "return ctx;" line here
>> IMHO.
>
> Thanks. I was mucking with that right before I quit for the day and posted
> my patch. I'll fix it.
>
> -Brian
>
PS. Again forgot to respond to mesa-dev too.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r600g: Various patches
2011/6/12 Mathias Fröhlich : > > Hi, > > attached is a set of patches to r600g. > > 0001-r600g-Fix-typo.patch: > Fix a more or less obvious typo in shader initialization setup. > > 0002-r600g-Set-the-domains-value-also-for-recycled-buffer.patch: > Makes sure that buffer objects from the userspace bo manager does not have a > degraded domains value set. Without this it could happen that buffer objects > for display lists for example ended up in gtt even if they could savely be > placed somewhere deep in the gpu board. > > 0003-r600g-Allow-VRAM-for-the-initial-domain-for-every-bu.patch: > This improoves rendering (not draw) times on plenty openscenegraph examples by > about 20% in average. > This turned out to be the most effective part of the past change that I > requested review for and that I never sent an updated patch up to now. > > 0004-r600g-Put-shaders-into-immutable-buffers.patch: > Shaders programs are immutable for the driver. So put them into immutable > buffer objects. These first 4 look good to me. I've done a piglit run with them and no regressions. I've gone ahead and applied them. Alex > > 0005-r600g-Make-use-of-PIPE_TRANSFER_DISCARD_WHOLE_RESOUR.patch: > This makes use of the DISCARD_WHOLE_RESOURCE flag for memory mappings. > > Please review/apply! > > Thanks > > Mathias > > > ___ > 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] Mesa (master): glapi: Add API that can create a _glapi_table from a dlfcn handle
On 06/11/2011 11:18 PM, Jeremy Huddleston wrote: Module: Mesa Branch: master Commit: 85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b Author: Jeremy Huddleston Date: Thu Jun 9 16:59:49 2011 -0700 glapi: Add API that can create a _glapi_table from a dlfcn handle Example usage: void *handle = dlopen(opengl_library_path, RTLD_LOCAL); struct _glapi_table *disp = _glapi_create_table_from_handle(handle, "gl"); Signed-off-by: Jeremy Huddleston --- src/mapi/glapi/gen/Makefile |9 +- src/mapi/glapi/gen/gl_gentable.py | 131 + src/mapi/glapi/glapi.h|4 + src/mapi/glapi/glapi_gentable.c | 7804 + src/mapi/glapi/sources.mak|1 + 5 files changed, 7947 insertions(+), 2 deletions(-) Diff: http://cgit.freedesktop.org/mesa/mesa/diff/?id=85937f4c0d4a78d3a11e3c1fa6148640f2a9ad7b ___ mesa-commit mailing list mesa-com...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-commit Jeremy, I'm getting a ton of warnings when glapi_gentable.c is compiled: glapi_gentable.c: In function ‘_glapi_create_table_from_handle’: glapi_gentable.c:52:10: warning: ISO C forbids passing argument 2 of ‘SET_NewLis t’ between function pointer and ‘void *’ ../../../src/mesa/main/dispatch.h:2055:20: note: expected ‘void (*)(GLuint, GLe num)’ but argument is of type ‘void *’ glapi_gentable.c:58:10: warning: ISO C forbids passing argument 2 of ‘SET_EndLis t’ between function pointer and ‘void *’ ../../../src/mesa/main/dispatch.h:2066:20: note: expected ‘void (*)(void)’ but a rgument is of type ‘void *’ glapi_gentable.c:64:10: warning: ISO C forbids passing argument 2 of ‘SET_CallLi st’ between function pointer and ‘void *’ ../../../src/mesa/main/dispatch.h:2077:20: note: expected ‘void (*)(GLuint)’ but argument is of type ‘void *’ glapi_gentable.c:70:10: warning: ISO C forbids passing argument 2 of ‘SET_CallLi sts’ between function pointer and ‘void *’ ../../../src/mesa/main/dispatch.h:2088:20: note: expected ‘void (*)(GLsizei, GL enum, const GLvoid *)’ but argument is of type ‘void *’ glapi_gentable.c:76:10: warning: ISO C forbids passing argument 2 of ‘SET_Delete Lists’ between function pointer and ‘void *’ ../../../src/mesa/main/dispatch.h:2099:20: note: expected ‘void (*)(GLuint, GLs izei)’ but argument is of type ‘void *’ I think the generator needs to insert some casts to pass the right function pointer type rather than void *. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 38210] Mesa git write access
https://bugs.freedesktop.org/show_bug.cgi?id=38210 Brian Paul changed: What|Removed |Added Product|Mesa|freedesktop.org Component|Other |Administration AssignedTo|mesa-dev@lists.freedesktop. |sitewranglers@lists.freedes |org |ktop.org --- Comment #1 from Brian Paul 2011-06-13 07:15:37 PDT --- Sounds good. Reassigning to admins. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] st/mesa: rebind vertex arrays if _NEW_BUFFER_OBJECT is dirty
On 06/12/2011 03:29 PM, Marek Olšák wrote: This fixes piglit/vbo-bufferdata. It's a regression in 7.11. --- src/mesa/state_tracker/st_draw.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c index 56955d3..dd26db2 100644 --- a/src/mesa/state_tracker/st_draw.c +++ b/src/mesa/state_tracker/st_draw.c @@ -650,7 +650,8 @@ st_draw_vbo(struct gl_context *ctx, struct pipe_draw_info info; unsigned i, num_instances = 1; GLboolean new_array = - st->dirty.st&& (st->dirty.mesa& (_NEW_ARRAY | _NEW_PROGRAM)) != 0; + st->dirty.st&& + (st->dirty.mesa& (_NEW_ARRAY | _NEW_PROGRAM | _NEW_BUFFER_OBJECT)) != 0; /* Mesa core state should have been validated already */ assert(ctx->NewState == 0x0); Reviewed-by: Brian Paul ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] mesa compressed mipmap generation
On 06/10/2011 02:42 PM, Eric Anholt wrote: Here's my series to finally fix compressed mipmap generation on hw drivers. Take a look at the last commit in particular -- I'd love to do TexImage in the uncompressed path as well so we could get rid of that awful code for handling this non-TexImage upload in the drivers, but that would cost us the zero-copy for swrast. Does anyone care? Fine by me. I only took a quick glance over the patches but they look OK. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] glxinfo: add support for creating/querying core-profile contexts
On 06/12/2011 12:56 PM, Gustaw Smolarczyk wrote:
I found some bugs in this code.
2011/6/11 Brian Paul:
The -c flag says to try to create a core profile (no legacy features)
using glXCreateContextAttribsARB(). A core profile may advertise a
different set of extensions than a compatibility profile (though,
the only difference with NVIDIA's driver is the presence of
GL_ARB_compatibility). Also note that extensions need to be queried
one at a time with glGetStringi().
+ /* install X error handler */
+ old_handler = XSetErrorHandler(create_context_error_handler);
+ CreateContextErrorFlag = False;
+
+ /* try creating context */
+ context = glXCreateContextAttribsARB_func(dpy,
+ fbconfig,
+ 0, /* share_context */
+ True, /* direct */
+ attribs);
+
+ /* restore error handler */
+ XSetErrorHandler(old_handler);
+
+ if (CreateContextErrorFlag)
+ context = 0;
The context should be tested against being direct. For example, fglrx
will happily create "4.2" context, but it will be just default
indirect one.
So you see "OpenGL version string: 4.2" in the output? That really
shouldn't happen. Seems like that's a fgrlx bug.
+ if (coreProfile) {
+ /* Try to create a core profile, starting with the newest version of
+ * GL that we're aware of. If we don't specify the version
+ */
+ int i;
+ for (i = NUM_GL_VERSIONS - 2; i> 0 ; i--) {
+ ctx = create_context_flags(dpy, config,
+gl_versions[i].major,
+gl_versions[i].minor,
+0x0,
+GLX_CONTEXT_CORE_PROFILE_BIT_ARB);
+ if (ctx)
+break;
+ }
+ if (!ctx) {
+ /* couldn't get core profile context */
+ return 0;
+ }
There's something missing here. If ctx is not NULL, it will be
overwritten by code below. There should be "return ctx;" line here
IMHO.
Thanks. I was mucking with that right before I quit for the day and
posted my patch. I'll fix it.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
