[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current

2013-02-19 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61012

Brian Paul bri...@vmware.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Brian Paul bri...@vmware.com ---
Fixed by commit e2091f64cb9ea79f3b51c353ed9facc03ec5690a

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current

2013-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61012

--- Comment #2 from Brian Paul bri...@vmware.com ---
Created attachment 75059
  -- https://bugs.freedesktop.org/attachment.cgi?id=75059action=edit
llvmpipe texture size patch

Can you test the attached patch?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current

2013-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61012

--- Comment #3 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #0)
 The following(ish) code produces an assertion failure using llvmpipe libGL
 from Mesa 9.0.2:
 Near as I can tell, the call responsible for storing that state with the
 pbuffer is this code:
 
  
 http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/glx/
 xlib/xm_api.c?id=369e46888904c6d379b8b477d9242cff1608e30e#n460
 
 A call to get_drawable_size retrieves the size of the pbuffer drawable into
 local variables width and height, but these values never make it into the
 XMesaBuffer structure.

This isn't llvmpipe specific right?
That call you mention indeed looks a bit odd. The function comment explicitly
states Width/Height of the new buffer will be 0 so I don't know why it calls
get_drawable_size() there in the first place (probably some leftover from older
code).
It looks like for pixmaps/windows that information will be filled out later at
MakeCurrent time, which will eventually call xmesa_check_buffer_size() which
will fill it in. However, for pbuffers this is a noop. My guess is it should be
filled out in XMesaCreatePBuffer() instead since pbuffers have fixed size (?).

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current

2013-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61012

--- Comment #4 from Brian Paul bri...@vmware.com ---
Created attachment 75065
  -- https://bugs.freedesktop.org/attachment.cgi?id=75065action=edit
Initialize the buffer's size in create_xmesa_buffer()

Here's another patch to try.  It uses the results of get_drawable_size() to
initialize the buffer's dimensions.  I've run other test programs and it seems
to be OK.

I think my previous patch for llvmpipe is also needed since it's possible to
create a pbuffer of size 0 x 0.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current

2013-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61012

--- Comment #6 from Brian Paul bri...@vmware.com ---
(In reply to comment #5)
 Created attachment 75068 [details] [review]
 another attempt to fix pbuffer initialization
 
 Hmm is it legal to use XGetGeometry() with pbuffers?

Not normally, but in the glx/xlib code we create a dummy pixmap for each
pbuffer so that we have an XID that we can pass around.


 I think something like this patch would be better.

That would be fine too.  It's what I first tried.

 Not sure if guarding against zero-sized buffers in drivers is needed. Might
 be but there are other instances where we hack up such windows to have
 width/height of 1 for that reason so we don't have to do it in drivers.

I hacked up a test for a 0x0 surface.  Softpipe worked but the llvmpipe
assertion failed.  I guess I'd consider the llvmpipe change to be a defensive
coding check.  One less way for llvmpipe to fail is good thing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current

2013-02-18 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61012

--- Comment #7 from Roland Scheidegger srol...@vmware.com ---
(In reply to comment #6)
 (In reply to comment #5)
  Created attachment 75068 [details] [review] [review]
  another attempt to fix pbuffer initialization
  
  Hmm is it legal to use XGetGeometry() with pbuffers?
 
 Not normally, but in the glx/xlib code we create a dummy pixmap for each
 pbuffer so that we have an XID that we can pass around.
Ah ok then that should be fine too.
I think though in this case the function comment should be updated too (which
is why I was thinking this function shouldn't really set up size for whatever
reason).

 
 
  I think something like this patch would be better.
 
 That would be fine too.  It's what I first tried.
 
  Not sure if guarding against zero-sized buffers in drivers is needed. Might
  be but there are other instances where we hack up such windows to have
  width/height of 1 for that reason so we don't have to do it in drivers.
 
 I hacked up a test for a 0x0 surface.  Softpipe worked but the llvmpipe
 assertion failed.  I guess I'd consider the llvmpipe change to be a
 defensive coding check.  One less way for llvmpipe to fail is good thing.
Yeah probably. Though zero-sized resources are a pretty nasty thing.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev


[Mesa-dev] [Bug 61012] alloc_layout_array tx * ty assertion failure when making pbuffer current

2013-02-17 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=61012

--- Comment #1 from Brian Crowell freedesk...@fluggo.com ---
Created attachment 75010
  -- https://bugs.freedesktop.org/attachment.cgi?id=75010action=edit
Test case

Hopefully minimal test case. Use the llvmpipe libGL.

-- 
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