mesa3d-dev

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 12:20 PM, Jakob Bornecrantz
<wal...@gm...> wrote:
> On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu <ol...@gm...> wrote:
>> On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu <ol...@gm...> wrote:
>>> This patch series adds st_api interface to st/mesa and st/vega, and
>>> switch st/egl and st/glx from st_public interface to the new interface.
>> I've pushed most of the this patch series to gallium-st-api.  I'd like to have
>> this topic branch focus on the switch of st/egl and st/glx to use st_api.
>> Further works, such as the switch of st/dri, EGLImage extensions will happen
>> directly in master or some other topic branches, whichever suits better.
>>
>> The implementations of the new interfaces (st_api, st_framebuffer_iface) are
>> isolated in new files in each state tracker.  The isolation makes it easier to
>> locate the changes.  But more importantly, unlike the rest of a state tracker,
>> the interfaces might be called from different threads.  I used whatever
>> existing mechanisms available to protect those callbacks, but when there is no
>> such mechanism, I ignored the issue mostly.
>>
>> I have one open question so far.  With st_api, co state trackers no longer have
>> access to pipe_contexts.  The pipe_contexts are usually used to implement
>>
>> * glXCopySubBufferMESA: copy a region of the back buffer to the front
>> * eglCopyBuffers: copy the render buffer of a surface to a pixmap
>> * SwapBuffers and FlushFront in DRI1
>>
>> The copying is a framebuffer operation and it does not make sense to steal a
>> random API context for the copying.  Remember that the co state trackers always
>> own the pipe_textures of a drawable in st_api.  One way to solve the problem is
>> to let the co state trackers own pipe_contexts of their own. A co state tracker
>> may create its pipe_context (and probably a blitter context) on demand when
>> glXCopySubBufferMESA or eglCopyBuffers is called and do the copying directly.
>>
>> But as all the 3 cases need to do a pipe_screen::flush_frontbuffer after the
>> copying, a better approach might be to rename and enhance
>> pipe_screen::flush_frontbuffer to support them directly, or a mix of both
>> approaches.
> Hmm maybe flush_frontbuffer should be made into a context function, or
> take a pipe_context. But that would probably require
> st_framebuffer_iface::flush_front to take a st_context as well. Not
> that I have anything against that.
> For eglCopyBuffers the manager probably need a pipe_context for
> itself. If you don't want to randomly steal one that is currently
> bound, even then it is not guarantied to be any context created, so as
> a fallback you will probably always have a context around.
I am thinking change pipe_screen::flush_frontbuffer to

  void
  pipe_screen::display_texture(struct pipe_screen *,
                               struct pipe_texture *,
                               void *winsys_drawable_handle,
                               unsigned x, unsigned y,
                               unsigned width, unsigned height);

The pipe_texture must be created with DISPLAY_TARGET or SCANOUT.  The type of
the opaque drawable handle is pipe_screen specific and is known to the co state
tracker, or whoever, created the pipe_screen.

This solves the problem with glXCopySubBufferMESA and eglCopyBuffers.  What
remain to be done for the DRI1 case is to define the DRI1 displaytarget and
switch st/dri to use it.

Down to the lowest level, DRI1 displaytarget still faces the problem of
displaying a pipe_texture, given struct dri1_api.  In the case
dri1_api::front_srf_locked is supported, it still needs to copy the texture.

Therefore, a mixed approach seems be the best.  With the change to
pipe_screen::flush_frontbuffer, glXCopySubBufferMESA and eglCopyBuffers do not
need a pipe_context.  And a pipe_context will be created by st/dri when DRI1 is
used.  This mixed approach requires less work.  As DRI1 is phasing out, I think
it is a sensible approach.

This is just some ideas.  The switch of st/dri can be delayed until
gallium-st-api is merged.  But if you are interested, I also have a local
branch that switches st/dri to use st_api, but only the DRI2 part.  It is
functioning, but the patch is a little bit dirty..

-- 
ol...@Lu...

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 12:07 PM, Jakob Bornecrantz
<wal...@gm...> wrote:
> On Fri, Mar 12, 2010 at 2:12 AM, Chia-I Wu <ol...@gm...> wrote:
>> On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz <ja...@vm...> wrote:
>>> Thanks for doing this Chia-I, also a very excellent summary. Last time we
>>> talked about st_api IIRC we both agreed that the way we implemented EGLImage
>>> was wrong. However I think that we have waited long enough to move the state
>>> trackers over to st_api.
>>> Would it to much trouble for you if we didn't do EGLImage in the first
>>> gallium-st-api feature branch? My feeling is that they are two separate
>>> issues and I think we should be able to quickly resolve moving the state
>>> trackers over to st_api and then move on to EGLImage. Looking at the patches
>>> the only affected one is the VG state tracker while the rest should just be
>>> not to apply the EGLImage related patches. I can do this later tonight and
>>> send out a series and give you something to work on.
>>> I really want to move the state trackers over to st_api and I don't want the
>>> EGLImage issues holding us back. I also think that that part of the patch
>>> series looks excellent and I don't foresee any difficulties getting this
>>> merged ASAP.
>>> Again thanks for doing this I know the inter state tracker interactions are
>>> a mess.
>> I've pushed a new branch, gallium-st-api, for the development of st_api.  It
>> consists of this patch series with EGLImage bits stripped out.  I also like to
>> have the branch merged sooner than later.
> Awesome, Thanks!
> The *_iface was always a eye sore in the interface but it could be
> avoided since st_context and st_framebuffer was already taken by the
> gl state tracker. One would have to be crazy to go over the files with
> sed and change all the reference, I guess I'm crazy... I have attached
> three patches does exactly this. Everything compiles between and works
> between each patch but a lot of warnings are generated, but I think I
> squashed them all in the last patch. They should probably be squashed
> if we want to use them, I like to get somebody sensible to weigh in on
> this matter before we do anything with them.
I'd love to see the _iface suffix get dropped too.  About the patches.  st/vega
also defines st_framebuffer and it needs to be renamed.  We might want to have
a convention for data types and variable naming that st/mesa and st/vega could
both follow.

That said, one concern about the renames is that it might cause many conflicts
when the branch is merged.  We might want to delay it until the branch is
merged or about to be merged.

-- 
ol...@Lu...

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Jakob B. <wal...@gm...>]

On Fri, Mar 12, 2010 at 3:00 AM, Chia-I Wu <ol...@gm...> wrote:
> On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu <ol...@gm...> wrote:
>> This patch series adds st_api interface to st/mesa and st/vega, and
>> switch st/egl and st/glx from st_public interface to the new interface.
> I've pushed most of the this patch series to gallium-st-api.  I'd like to have
> this topic branch focus on the switch of st/egl and st/glx to use st_api.
> Further works, such as the switch of st/dri, EGLImage extensions will happen
> directly in master or some other topic branches, whichever suits better.
>
> The implementations of the new interfaces (st_api, st_framebuffer_iface) are
> isolated in new files in each state tracker.  The isolation makes it easier to
> locate the changes.  But more importantly, unlike the rest of a state tracker,
> the interfaces might be called from different threads.  I used whatever
> existing mechanisms available to protect those callbacks, but when there is no
> such mechanism, I ignored the issue mostly.
>
> I have one open question so far.  With st_api, co state trackers no longer have
> access to pipe_contexts.  The pipe_contexts are usually used to implement
>
> * glXCopySubBufferMESA: copy a region of the back buffer to the front
> * eglCopyBuffers: copy the render buffer of a surface to a pixmap
> * SwapBuffers and FlushFront in DRI1
>
> The copying is a framebuffer operation and it does not make sense to steal a
> random API context for the copying.  Remember that the co state trackers always
> own the pipe_textures of a drawable in st_api.  One way to solve the problem is
> to let the co state trackers own pipe_contexts of their own. A co state tracker
> may create its pipe_context (and probably a blitter context) on demand when
> glXCopySubBufferMESA or eglCopyBuffers is called and do the copying directly.
>
> But as all the 3 cases need to do a pipe_screen::flush_frontbuffer after the
> copying, a better approach might be to rename and enhance
> pipe_screen::flush_frontbuffer to support them directly, or a mix of both
> approaches.

Hmm maybe flush_frontbuffer should be made into a context function, or
take a pipe_context. But that would probably require
st_framebuffer_iface::flush_front to take a st_context as well. Not
that I have anything against that.

For eglCopyBuffers the manager probably need a pipe_context for
itself. If you don't want to randomly steal one that is currently
bound, even then it is not guarantied to be any context created, so as
a fallback you will probably always have a context around.

Cheers Jakob.

[Mesa3d-dev] [PATCH] Add programs to .gitignore in redbook

[Jeff S. <why...@ya...>]

[Mesa3d-dev] [PATCH] Add programs to .gitignore in xdemos

[Jeff S. <why...@ya...>]

[Mesa3d-dev] [PATCH] Change some int64_t's to uint64_t's, to match CARD64's signedness

[Jeff S. <why...@ya...>]

[Mesa3d-dev] [PATCH] Add -L$(libdir) for xdemos and egl so that the right libX11 is found

[Jeff S. <why...@ya...>]

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Jakob B. <wal...@gm...>]

On Fri, Mar 12, 2010 at 2:12 AM, Chia-I Wu <ol...@gm...> wrote:
> On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz <ja...@vm...> wrote:
>> Thanks for doing this Chia-I, also a very excellent summary. Last time we
>> talked about st_api IIRC we both agreed that the way we implemented EGLImage
>> was wrong. However I think that we have waited long enough to move the state
>> trackers over to st_api.
>> Would it to much trouble for you if we didn't do EGLImage in the first
>> gallium-st-api feature branch? My feeling is that they are two separate
>> issues and I think we should be able to quickly resolve moving the state
>> trackers over to st_api and then move on to EGLImage. Looking at the patches
>> the only affected one is the VG state tracker while the rest should just be
>> not to apply the EGLImage related patches. I can do this later tonight and
>> send out a series and give you something to work on.
>> I really want to move the state trackers over to st_api and I don't want the
>> EGLImage issues holding us back. I also think that that part of the patch
>> series looks excellent and I don't foresee any difficulties getting this
>> merged ASAP.
>> Again thanks for doing this I know the inter state tracker interactions are
>> a mess.
> I've pushed a new branch, gallium-st-api, for the development of st_api.  It
> consists of this patch series with EGLImage bits stripped out.  I also like to
> have the branch merged sooner than later.

Awesome, Thanks!

The *_iface was always a eye sore in the interface but it could be
avoided since st_context and st_framebuffer was already taken by the
gl state tracker. One would have to be crazy to go over the files with
sed and change all the reference, I guess I'm crazy... I have attached
three patches does exactly this. Everything compiles between and works
between each patch but a lot of warnings are generated, but I think I
squashed them all in the last patch. They should probably be squashed
if we want to use them, I like to get somebody sensible to weigh in on
this matter before we do anything with them.

Cheers Jakob.

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 10:16 AM, Chia-I Wu <ol...@gm...> wrote:
> On Thu, Mar 11, 2010 at 11:45 PM, Keith Whitwell <ke...@vm...> wrote:
>> On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
>>> Thanks for testing the patches.  I will have a look at the segfault tomorrow.
>>> I haven't tried llvmpipe.  Does softpipe also get the rendering error?
>> No, purely llvmpipe.
> I've fixed the infinite loop.  It was a stupid typo.  Now I am seeing rendering
> errors in singlebuffer.
Yes, the rendering error I saw was due to missing stencil bits.  It should be
fixed now.

-- 
ol...@Lu...

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Chia-I Wu <ol...@gm...>]

On Thu, Mar 11, 2010 at 12:15 PM, Chia-I Wu <ol...@gm...> wrote:
> This patch series adds st_api interface to st/mesa and st/vega, and
> switch st/egl and st/glx from st_public interface to the new interface.
I've pushed most of the this patch series to gallium-st-api.  I'd like to have
this topic branch focus on the switch of st/egl and st/glx to use st_api.
Further works, such as the switch of st/dri, EGLImage extensions will happen
directly in master or some other topic branches, whichever suits better.

The implementations of the new interfaces (st_api, st_framebuffer_iface) are
isolated in new files in each state tracker.  The isolation makes it easier to
locate the changes.  But more importantly, unlike the rest of a state tracker,
the interfaces might be called from different threads.  I used whatever
existing mechanisms available to protect those callbacks, but when there is no
such mechanism, I ignored the issue mostly.

I have one open question so far.  With st_api, co state trackers no longer have
access to pipe_contexts.  The pipe_contexts are usually used to implement

* glXCopySubBufferMESA: copy a region of the back buffer to the front
* eglCopyBuffers: copy the render buffer of a surface to a pixmap
* SwapBuffers and FlushFront in DRI1

The copying is a framebuffer operation and it does not make sense to steal a
random API context for the copying.  Remember that the co state trackers always
own the pipe_textures of a drawable in st_api.  One way to solve the problem is
to let the co state trackers own pipe_contexts of their own. A co state tracker
may create its pipe_context (and probably a blitter context) on demand when
glXCopySubBufferMESA or eglCopyBuffers is called and do the copying directly.

But as all the 3 cases need to do a pipe_screen::flush_frontbuffer after the
copying, a better approach might be to rename and enhance
pipe_screen::flush_frontbuffer to support them directly, or a mix of both
approaches.

-- 
ol...@Lu...

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Chia-I Wu <ol...@gm...>]

On Thu, Mar 11, 2010 at 11:45 PM, Keith Whitwell <ke...@vm...> wrote:
> On Thu, 2010-03-11 at 07:43 -0800, Chia-I Wu wrote:
>> Thanks for testing the patches.  I will have a look at the segfault tomorrow.
>> I haven't tried llvmpipe.  Does softpipe also get the rendering error?
> No, purely llvmpipe.
I've fixed the infinite loop.  It was a stupid typo.  Now I am seeing rendering
errors in singlebuffer.
>> I will create a topic branch, gallium-st-api, tomorrow and continue the
>> development/bugfixing there, unless there are major design defects that should
>> be resolved first.
> I don't see any major defects - it all looks pretty sensible to me.
I've pushed this patches series to gallium-st-api.  The only change is that it
does not have the EGLImage bits, as requested by Jakob.

-- 
ol...@Lu...

Re: [Mesa3d-dev] [PATCH-RFC] st_api, EGLImage, and flush_frontbuffer

[Chia-I Wu <ol...@gm...>]

On Fri, Mar 12, 2010 at 3:11 AM, Jakob Bornecrantz <ja...@vm...> wrote:
> Thanks for doing this Chia-I, also a very excellent summary. Last time we
> talked about st_api IIRC we both agreed that the way we implemented EGLImage
> was wrong. However I think that we have waited long enough to move the state
> trackers over to st_api.
> Would it to much trouble for you if we didn't do EGLImage in the first
> gallium-st-api feature branch? My feeling is that they are two separate
> issues and I think we should be able to quickly resolve moving the state
> trackers over to st_api and then move on to EGLImage. Looking at the patches
> the only affected one is the VG state tracker while the rest should just be
> not to apply the EGLImage related patches. I can do this later tonight and
> send out a series and give you something to work on.
> I really want to move the state trackers over to st_api and I don't want the
> EGLImage issues holding us back. I also think that that part of the patch
> series looks excellent and I don't foresee any difficulties getting this
> merged ASAP.
> Again thanks for doing this I know the inter state tracker interactions are
> a mess.
I've pushed a new branch, gallium-st-api, for the development of st_api.  It
consists of this patch series with EGLImage bits stripped out.  I also like to
have the branch merged sooner than later.

-- 
ol...@Lu...

[Mesa3d-dev] util_format cleanup leftover: Gallium BGRA vertex swizzles

[Marek O. <ma...@gm...>]

Please see this commit:
http://cgit.freedesktop.org/~mareko/mesa/commit/?id=177a4432aa88fc68d83895ae71b7ad2c86a1e7e3

Subject: [PATCH] gallium: fix BGRA vertex color swizzles

The mapping for vertex_array_bgra:
(gl -> st -> translate)
GL_RGBA -> PIPE_FORMAT_R8G8B8A8 (RGBA) -> no swizzle (XYZW)
GL_BGRA -> PIPE_FORMAT_A8R8G8B8 (ARGB) -> ZYXW (BGRA again??)

Iẗ́'s pretty clear that PIPE_FORMAT_A8R8G8B8 here is wrong. This commit
fixes the pipe format and removes obvious workarounds in util/translate.

Tested with: softpipe, llvmpipe, r300g.

Please review.

-Marek

[Mesa3d-dev] [Bug 27012] mesa git shows a compilation error

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27012


Jos van Wolput <wo...@on...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #2 from Jos van Wolput <wo...@on...>  2010-03-11 17:49:06 PST ---
(In reply to comment #1)
> Fixed in Git.
> 
Yet another compilation error:
---
make[5]: Entering directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon/egl'
gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
-fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_X86_64_ASM -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -D_GNU_SOURCE
-DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS dummy.c -o dummy.o
make[5]: *** No rule to make target
`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
`egl_x11_radeon.so'.  Stop.
make[5]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon/egl'
make[4]: *** [default] Error 1
make[4]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm/radeon'
make[3]: *** [default] Error 1
make[3]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys/drm'
make[2]: *** [default] Error 1
make[2]: Leaving directory
`/home/jos/tmp/xorg/git-master/mesa/src/gallium/winsys'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/jos/tmp/xorg/git-master/mesa/src'
make: *** [default] Error 1
---


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] xdemos build breakage...

[David M. <da...@da...>]

This change:

commit d888bbc45a84946cafb4f4d2c89681a580cd89bc
Author: Brian Paul <br...@vm...>
Date:   Tue Nov 17 13:39:13 2009 -0700

    progs/xdemos: added -lX11 -lpthread for GNU gold linker

breaks the build if you are building under a specific path prefix
(say, /opt/XORG) and you have an existing X11 installation in the
usual location (/usr, etc.)

Mesa gets configure with:

PATH=/opt/XORG/bin:$PATH ./configure --prefix=/opt/XORG --libdir=/opt/XORG/lib

And then we get, for example:

make[2]: Entering directory `/home/davem/src/GIT/XORG/mesa/mesa/progs/xdemos'
gcc -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing  -fPIC  -DUSE_SPARC_ASM -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS  corender.o ipc.o -L../../lib -lGL  -lm -lX11 -lpthread -o corender
/usr/bin/../lib/libxcb-xlib.so.0: undefined reference to `_xcb_lock_io'
/usr/bin/../lib/libxcb-xlib.so.0: undefined reference to `_xcb_unlock_io'
collect2: ld returned 1 exit status

Reverting the commit, of course, makes the problem go away.

One way to fix this would be to propagate the --libdir prefix
down to these Makefiles.

The same exact problem exists in progs/egl, but since libEGL doesn't
link to libX11 any more, a simple revert of:

commit 8d0bdfa4335ea07a747f53635a57414d15c234b7
Author: Chia-I Wu <ol...@gm...>
Date:   Wed Aug 26 12:44:02 2009 +0800

    progs: EGL/X progs should link to libX11.
    
    Since 5a459d58fca2b71cb77c39f98df8a81ce6298421, libEGL no longer links
    to libX11.  Add the dependency to affected progs and cleanup
    prog/egl/Makefile.
    
    Signed-off-by: Chia-I Wu <ol...@gm...>

doesn't fix the problem.

Sigh... :-)

Re: [Mesa3d-dev] mesa vbo validation issue [was Re: Wine/Gallium indexed strided VBO fail]

[Corbin S. <mos...@gm...>]

On Wed, Mar 10, 2010 at 7:11 AM, Brian Paul <br...@vm...> wrote:
>>> get_arrays_bounds: Handling 2 attrs
>>> attr 0: stride 16 size 12 start (nil) end 0xfffffffc
>>> attr 1: stride 16 size 4 start 0xc end (nil)
>>> buffer range: (nil) 0xfffffffc range -4 max index 4294967295
>
> Can you post the patch you used to print this info, Corbin?

Inlined:

diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index 8a6e1ed..7ae152c 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -293,6 +293,8 @@ get_arrays_bounds(const struct st_vertex_program *vp,
    const GLubyte *high_addr = NULL;
    GLuint attr;

+   debug_printf("get_arrays_bounds: Handling %u attrs\n", vpv->num_inputs);
+
    for (attr = 0; attr < vpv->num_inputs; attr++) {
       const GLuint mesaAttr = vp->index_to_input[attr];
       const GLint stride = arrays[mesaAttr]->StrideB;
@@ -301,6 +303,8 @@ get_arrays_bounds(const struct st_vertex_program *vp,
                            _mesa_sizeof_type(arrays[mesaAttr]->Type));
       const GLubyte *end = start + (max_index * stride) + sz;

+      debug_printf("attr %u: stride %d size %u start %p end %p\n",
attr, stride, sz, start, end);
+
       if (attr == 0) {
          low_addr = start;
          high_addr = end;
@@ -348,7 +352,7 @@ setup_interleaved_attribs(GLcontext *ctx,
          const GLubyte *low, *high;

          get_arrays_bounds(vp, vpv, arrays, max_index, &low, &high);
-         /*printf("buffer range: %p %p  %d\n", low, high, high-low);*/
+         printf("buffer range: %p %p range %d max index %u\n", low,
high, high-low, max_index);

          offset0 = low;
          if (userSpace) {


>>> So right here (from device.ok) we have interleaved userspace VBO, that is
>>> being
>>> prepped inside core Mesa. Two delightful things here; the first attr
>>> seems way
>>> off-base, it shouldn't dare be giving us bad pointers, and the second
>>> attr's
>>> pointers don't even line up!
>>
>> In VBO rendering, the pointers are really just offsets into the VBO, so
>> should be interpreted as numbers.
>>
>> The first attribute has what looks like a small negative number.  I
>> don't know if that's legal or not in GL - I suspect it is probably not
>> legal and should be rejected in the mesa validation code.
>
> This would have come in via the 'ptr' argument to one of the
> glVertex/Color/etcPointer() functions.  We never check for negative pointer
> values.

Just started digging into this again, finally have spare time (if only
for a few days.) I will hopefully have a followup soon.

~ C.

-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<Mos...@gm...>

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

[Marek O. <ma...@gm...>]

On Thu, Mar 11, 2010 at 4:41 PM, Luca Barbieri <lu...@lu...>wrote:

> I've looked into the issue, and found a workaround by looking at what
> st_renderbuffer_alloc_storage (which is called to create the depth
> buffer with ST_SURFACE_DEPTH != BUFFER_DEPTH) does.
>
> Adding:
> if(ctx) ctx->NewState |= _NEW_BUFFERS;
>
> at the end of st_set_framebuffer_surface seems to solve the warsow
> problem with no other regressions.
>
> Brian, is this the right fix?
> Marek, does it fix your r300g problems too?
>

Mesa master merged with 7.8 fixes all the glean regressions. Thanks.

Re: [Mesa3d-dev] sw-api-2 branch

[STEVE555 <ste...@ho...>]

Hi keith,
            Thank you very much for putting my mind at rest.I have to admit
I was sweating a bit,lol! I'm might try out the gallium-sampler-view branch
a bit later.
Regards,
            STEVE555

Keith Whitwell-4 wrote:
> 
> I actually merged the sw-api-2 branch to master & then deleted the
> branch.  Sorry if I surprised you - just trying to avoid having
> hundreds of old, dead branches cluttering up the repository.   Usually
> after a few weeks go by it's hard to remember which branches are still
> active and which can be deleted.
> 
> I'll push the fix tomorrow from work.
> 
> Keith
> 
> On Thu, Mar 11, 2010 at 9:58 PM, STEVE555 <ste...@ho...>
> wrote:
>>
>> Hi guys,
>>           I applied the patch using git apply on the Mesa  master branch
>> (I
>> was getting the same on there also),for some reason,Kompare wasn't doing
>> it's job properly. The reason I did it on there was because I looked at
>> the
>> branches on cgit,and Keith's gallium-sw-api-2 branch has disappeared! I'm
>> extremeley sorry if I deleted it,or merged it into master by accident
>> like I
>> did earlier.I genuinely thought I was doing that sort of thing on my
>> local
>> copy of his branch.
>> The good news is that when I re-compiled my local copy of Mesa master
>> with
>> the patch applied,it all compiled fine,with no ill effects when I
>> re-booted.
>> Regards,
>>            STEVE555
>>
>> Dan Nicholson-2 wrote:
>>>
>>> On Thu, Mar 11, 2010 at 12:23 PM, Dan Nicholson <dbn...@gm...>
>>> wrote:
>>>> On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 <ste...@ho...>
>>>> wrote:
>>>>>
>>>>> Hi Keith,
>>>>>            Here's what I did.I opened Konsole on my mesa folder.I did
>>>>> a
>>>>> git
>>>>> pull origin to get the latest commits from master,then I did a git
>>>>> checkout
>>>>> -b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
>>>>> deleted it earlier) .I then switched to the gallium-sw-api-2 using git
>>>>> branch and then did a git merge master.I saved your patch in a txt
>>>>> file,and
>>>>> then renamed it as gallium-sw-api-2.patch,I then used Kompare to apply
>>>>> and
>>>>> save all the differences.
>>>>>  I then did a gmake -B realclean and then I used the same configure
>>>>> options
>>>>> as before.
>>>>> Unfortunately,your patch didn't work,I still get the same error as
>>>>> before.
>>>>
>>>> You would actually need to run autoconf first to generate a new
>>>> configure script with Keith's changes.
>>>
>>> Or just run ./autogen.sh with the arguments you normally pass to
>>> configure.
>>>
>>> --
>>> Dan
>>>
>>> ------------------------------------------------------------------------------
>>> Download Intel® Parallel Studio Eval
>>> Try the new software tools for yourself. Speed compiling, find bugs
>>> proactively, and fine-tune applications for parallel performance.
>>> See why Intel Parallel Studio got high marks during beta.
>>> http://p.sf.net/sfu/intel-sw-dev
>>> _______________________________________________
>>> Mesa3d-dev mailing list
>>> Mes...@li...
>>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>>
>>>
>>
>> --
>> View this message in context:
>> http://old.nabble.com/sw-api-2-branch-tp27841684p27870463.html
>> Sent from the mesa3d-dev mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Mesa3d-dev mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/sw-api-2-branch-tp27841684p27870709.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] sw-api-2 branch

[Keith W. <kei...@go...>]

I actually merged the sw-api-2 branch to master & then deleted the
branch.  Sorry if I surprised you - just trying to avoid having
hundreds of old, dead branches cluttering up the repository.   Usually
after a few weeks go by it's hard to remember which branches are still
active and which can be deleted.

I'll push the fix tomorrow from work.

Keith

On Thu, Mar 11, 2010 at 9:58 PM, STEVE555 <ste...@ho...> wrote:
>
> Hi guys,
>           I applied the patch using git apply on the Mesa  master branch (I
> was getting the same on there also),for some reason,Kompare wasn't doing
> it's job properly. The reason I did it on there was because I looked at the
> branches on cgit,and Keith's gallium-sw-api-2 branch has disappeared! I'm
> extremeley sorry if I deleted it,or merged it into master by accident like I
> did earlier.I genuinely thought I was doing that sort of thing on my local
> copy of his branch.
> The good news is that when I re-compiled my local copy of Mesa master with
> the patch applied,it all compiled fine,with no ill effects when I re-booted.
> Regards,
>            STEVE555
>
> Dan Nicholson-2 wrote:
>>
>> On Thu, Mar 11, 2010 at 12:23 PM, Dan Nicholson <dbn...@gm...>
>> wrote:
>>> On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 <ste...@ho...>
>>> wrote:
>>>>
>>>> Hi Keith,
>>>>            Here's what I did.I opened Konsole on my mesa folder.I did a
>>>> git
>>>> pull origin to get the latest commits from master,then I did a git
>>>> checkout
>>>> -b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
>>>> deleted it earlier) .I then switched to the gallium-sw-api-2 using git
>>>> branch and then did a git merge master.I saved your patch in a txt
>>>> file,and
>>>> then renamed it as gallium-sw-api-2.patch,I then used Kompare to apply
>>>> and
>>>> save all the differences.
>>>>  I then did a gmake -B realclean and then I used the same configure
>>>> options
>>>> as before.
>>>> Unfortunately,your patch didn't work,I still get the same error as
>>>> before.
>>>
>>> You would actually need to run autoconf first to generate a new
>>> configure script with Keith's changes.
>>
>> Or just run ./autogen.sh with the arguments you normally pass to
>> configure.
>>
>> --
>> Dan
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Mesa3d-dev mailing list
>> Mes...@li...
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>>
>>
>
> --
> View this message in context: http://old.nabble.com/sw-api-2-branch-tp27841684p27870463.html
> Sent from the mesa3d-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>

Re: [Mesa3d-dev] sw-api-2 branch

[STEVE555 <ste...@ho...>]

Hi guys,
           I applied the patch using git apply on the Mesa  master branch (I
was getting the same on there also),for some reason,Kompare wasn't doing
it's job properly. The reason I did it on there was because I looked at the
branches on cgit,and Keith's gallium-sw-api-2 branch has disappeared! I'm
extremeley sorry if I deleted it,or merged it into master by accident like I
did earlier.I genuinely thought I was doing that sort of thing on my local
copy of his branch.
The good news is that when I re-compiled my local copy of Mesa master with
the patch applied,it all compiled fine,with no ill effects when I re-booted.
Regards,
            STEVE555 

Dan Nicholson-2 wrote:
> 
> On Thu, Mar 11, 2010 at 12:23 PM, Dan Nicholson <dbn...@gm...>
> wrote:
>> On Thu, Mar 11, 2010 at 12:19 PM, STEVE555 <ste...@ho...>
>> wrote:
>>>
>>> Hi Keith,
>>>            Here's what I did.I opened Konsole on my mesa folder.I did a
>>> git
>>> pull origin to get the latest commits from master,then I did a git
>>> checkout
>>> -b gallium-sw-api-2 origin/gallium-sw-api-2 to get your branch again(I
>>> deleted it earlier) .I then switched to the gallium-sw-api-2 using git
>>> branch and then did a git merge master.I saved your patch in a txt
>>> file,and
>>> then renamed it as gallium-sw-api-2.patch,I then used Kompare to apply
>>> and
>>> save all the differences.
>>>  I then did a gmake -B realclean and then I used the same configure
>>> options
>>> as before.
>>> Unfortunately,your patch didn't work,I still get the same error as
>>> before.
>>
>> You would actually need to run autoconf first to generate a new
>> configure script with Keith's changes.
> 
> Or just run ./autogen.sh with the arguments you normally pass to
> configure.
> 
> --
> Dan
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Mesa3d-dev mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
> 
> 

-- 
View this message in context: http://old.nabble.com/sw-api-2-branch-tp27841684p27870463.html
Sent from the mesa3d-dev mailing list archive at Nabble.com.

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

[Brian P. <br...@vm...>]

Luca Barbieri wrote:
> Shouldn't
> 
> _mesa_add_renderbuffer(&stfb->Base, BUFFER_FRONT_LEFT, rb);
> 
> be
> 
> _mesa_add_renderbuffer(&stfb->Base, surfIndex, rb);
> 
> instead, since you seem to make the on-demand creation mechanism
> generic and no longer limited to the front buffer?

Yes. Fixed now.

-Brian

Re: [Mesa3d-dev] Compile error in xorg_crtc.c

[José F. <jfo...@vm...>]

On Thu, 2010-03-11 at 13:39 -0800, Johannes Obermayr wrote:
> STEVE555 wrote:
> >If I leave out the xorg state tracker,it goes past fine until it comes up
> >with this error I posted earlier:
> >
> >gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
> >gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
> >-fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM
> >-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
> >-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
> >-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> >-DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -D_GNU_SOURCE -DPTHREADS -DDEBUG
> >-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
> >-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
> >-DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o dummy.o
> >gmake[5]: *** No rule to make target
> >`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
> >`egl_x11_vmwgfx.so'.  Stop.
> >gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
> >gmake[4]: *** [default] Error 1
> >gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware'
> >gmake[3]: *** [default] Error 1
> >gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm'
> >gmake[2]: *** [default] Error 1
> >gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys'
> >gmake[1]: *** [subdirs] Error 1
> >gmake[1]: Leaving directory `/opt/mesa/src'
> >gmake: *** [default] Error 1
> >
> >I'll try and wait if the latest packages get updated for xorg,but I might be
> >tempted to bit the bullet and upgrade to Rawhide.
> >
> >Regards,
> >            STEVE555
> 
> There is also this error with latest git:
> gmake[5]: *** No rule to make target `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by `egl_x11_i915.so'.  Stop.

This is a build order issue.

src/gallium/winsys should produce no shared objects. Just static
libraries.

src/gallium/targets should produce the final shared object targets.

So the right build order is winsys then targets.

But since we still have shared objects in src/gallium/winsys they might
be built before the .as they depend upon.

Perhaps tweaking order such way that winsys/drm comes after winsys/xlib
will help.

Jose

Re: [Mesa3d-dev] Compile error in xorg_crtc.c

[Johannes O. <joh...@gm...>]

STEVE555 wrote:
>If I leave out the xorg state tracker,it goes past fine until it comes up
>with this error I posted earlier:
>
>gmake[5]: Entering directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
>gcc -c  -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math
>-fvisibility=hidden -fno-strict-aliasing -m32 -g  -fPIC -m32 -DUSE_X86_ASM
>-DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_GNU_SOURCE -DPTHREADS -DDEBUG
>-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
>-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
>-DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 -D_GNU_SOURCE -DPTHREADS -DDEBUG
>-DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER
>-DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS
>-DMAX_WIDTH=4096 -DMAX_HEIGHT=4096 dummy.c -o dummy.o
>gmake[5]: *** No rule to make target
>`../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by
>`egl_x11_vmwgfx.so'.  Stop.
>gmake[5]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware/egl'
>gmake[4]: *** [default] Error 1
>gmake[4]: Leaving directory `/opt/mesa/src/gallium/winsys/drm/vmware'
>gmake[3]: *** [default] Error 1
>gmake[3]: Leaving directory `/opt/mesa/src/gallium/winsys/drm'
>gmake[2]: *** [default] Error 1
>gmake[2]: Leaving directory `/opt/mesa/src/gallium/winsys'
>gmake[1]: *** [subdirs] Error 1
>gmake[1]: Leaving directory `/opt/mesa/src'
>gmake: *** [default] Error 1
>
>I'll try and wait if the latest packages get updated for xorg,but I might be
>tempted to bit the bullet and upgrade to Rawhide.
>
>Regards,
>            STEVE555

There is also this error with latest git:
gmake[5]: *** No rule to make target `../../../../../../src/gallium/winsys/xlib/libws_xlib.a', needed by `egl_x11_i915.so'.  Stop.

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

[Luca B. <lu...@lu...>]

Shouldn't

_mesa_add_renderbuffer(&stfb->Base, BUFFER_FRONT_LEFT, rb);

be

_mesa_add_renderbuffer(&stfb->Base, surfIndex, rb);

instead, since you seem to make the on-demand creation mechanism
generic and no longer limited to the front buffer?

Re: [Mesa3d-dev] Revert ST_SURFACE_DEPTH = BUFFER_DEPTH in master too?

[Brian P. <br...@vm...>]

Michel Dänzer wrote:
> On Thu, 2010-03-11 at 11:28 -0700, Brian Paul wrote: 
>> Luca Barbieri wrote:
>>> Solves the Warsow issue and seems to work.
>> OK, I think you can commit the patch to 7.8 then.
> 
> Can this also be backported to mesa_7_7_branch?

Sure, if you can test it.  We might want to wait a few days and make 
sure nothing regresses with it on the 7.8 branch.  I'll commit it there.

-Brian