Thomas Hellström wrote:
Jerome Glisse wrote:
Hi again Thomas,
It seems that if a fence is created with a userobject in superioctl,
one ref on the fence from one of the associated bo (the EXE bo i think)
is not properly unreferenced automagicly by kernel on program exit
if program never
http://bugs.freedesktop.org/show_bug.cgi?id=15477
Michel Dänzer [EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
http://bugs.freedesktop.org/show_bug.cgi?id=15511
Gordon Jin [EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED]|[EMAIL PROTECTED]
--
http://bugs.freedesktop.org/show_bug.cgi?id=15477
--- Comment #10 from Ben Gamari [EMAIL PROTECTED] 2008-04-15 07:23:08 PST ---
Created an attachment (id=15926)
-- (http://bugs.freedesktop.org/attachment.cgi?id=15926)
X log from non-working configuration
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=15477
--- Comment #11 from Ben Gamari [EMAIL PROTECTED] 2008-04-15 07:27:31 PST ---
I
(In reply to comment #9)
(In reply to comment #7)
It seems that over indirect rendering compiz runs fine
So, I suspect that GLX_EXT_texture_from_pixmap is
http://bugs.freedesktop.org/show_bug.cgi?id=15477
--- Comment #12 from Michel Dänzer [EMAIL PROTECTED] 2008-04-15 07:32:38 PST
---
(In reply to comment #11)
So, I suspect that GLX_EXT_texture_from_pixmap is incorrectly being
advertised
with DRI1.
Interesting. glxinfo lists it,
http://bugs.freedesktop.org/show_bug.cgi?id=15477
--- Comment #13 from Ben Gamari [EMAIL PROTECTED] 2008-04-15 07:39:54 PST ---
Created an attachment (id=15927)
-- (http://bugs.freedesktop.org/attachment.cgi?id=15927)
glxinfo output
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=15477
--- Comment #14 from Ben Gamari [EMAIL PROTECTED] 2008-04-15 07:41:11 PST ---
(In reply to comment #12)
It's expected to be listed in the server and client extensions. What matters
is
the 'GLX extensions:' string.
Just attached the output
http://bugs.freedesktop.org/show_bug.cgi?id=15477
Michel Dänzer [EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #15927|application/octet-stream|text/plain
http://bugs.freedesktop.org/show_bug.cgi?id=15477
Ben Gamari [EMAIL PROTECTED] changed:
What|Removed |Added
Attachment #15926|application/octet-stream|text/plain
mime
http://bugs.freedesktop.org/show_bug.cgi?id=15477
--- Comment #15 from Johannes Engel [EMAIL PROTECTED] 2008-04-15 08:02:23
PST ---
That log looks good to me, at least my one looks pretty similar. And at the
moment I do not expect that behaviour.
--
Configure bugmail:
http://bugs.freedesktop.org/show_bug.cgi?id=15477
--- Comment #16 from Ben Gamari [EMAIL PROTECTED] 2008-04-15 08:36:11 PST ---
(In reply to comment #15)
That log looks good to me, at least my one looks pretty similar. And at the
moment I do not expect that behaviour.
Well, this is
http://bugs.freedesktop.org/show_bug.cgi?id=15525
Summary: No transparency in VMD
Product: DRI
Version: XOrg CVS
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component:
http://bugs.freedesktop.org/show_bug.cgi?id=15525
--- Comment #1 from Markus Amsler [EMAIL PROTECTED] 2008-04-15 15:46:59 PST
---
Created an attachment (id=15944)
-- (http://bugs.freedesktop.org/attachment.cgi?id=15944)
fix fragment.position
Just a guess, does this patch fix the issue? If
Hi Eric,
others: This may be a larger problem (I'd be interested in how TTM solves
this also).
So I've hit a problem with the fake bufmgr and the size of the objects
referenced by a batchbuffer being bigger than the current aperture. So
when we have a batchbuffer and we are emitting a number
15 matches
Mail list logo
