Bug 5199

Summary:	Mesa bug fixes from accelerated indirect rendering work
Product:	Mesa	Reporter:	Kristian Høgsberg <krh>
Component:	Mesa core	Assignee:	mesa-dev
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	high
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Patch for problems mentioned above

Description Kristian Høgsberg 2005-11-30 09:28:05 UTC

I've been working on getting accelerated indirect rendering working, and in the
process I've come across 3 problems in mesa:

  - The DRI drawable destructor need to remove the drawable from the hash table
so it isn't freed again during the drawable garbage collection.  Conversely, the
garbage collection shoudn't do this.  In the direct rendering case this never
happens, since we don't call the DRI drawable destructor directly, it's only
invoked during the garbage collection.

  - _gl_copy_visual_to_context_mode() should set the mode->rgbBits and
mode->indexBits corresponding to the actual mode, instead of setting both to
config->bufferSize.

  - I've removed the xf86drm.h include from dri_interface.h since it isn't used
by anything in the file.  dri/common/dri_util.h includes xf86drm.h indirectly
this way, but the patch adds and explicit include there.

See also: bug 4988.

Comment 1 Kristian Høgsberg 2005-11-30 09:30:45 UTC

Created attachment 3947 [details] [review]
Patch for problems mentioned above

Comment 2 Brian Paul 2005-11-30 09:59:43 UTC

I've checked in your changes to Mesa CVS, both the trunk and 6.4 branch.

Comment 3 Ian Romanick 2005-11-30 10:34:25 UTC

(In reply to comment #0)

>   - _gl_copy_visual_to_context_mode() should set the mode->rgbBits and
> mode->indexBits corresponding to the actual mode, instead of setting both to
> config->bufferSize.

There was a reason for doing it like this, but I don't recall what it was. 
There was a certain amount for fragility in that code with respect to getting
the set of visuals sent by the server to match the set of fbconfigs returned by
the client-side driver.  I don't know if this is still an issue.

Comment 4 Kristian Høgsberg 2005-11-30 14:55:44 UTC

(In reply to comment #3)
> (In reply to comment #0)
> 
> >   - _gl_copy_visual_to_context_mode() should set the mode->rgbBits and
> > mode->indexBits corresponding to the actual mode, instead of setting both to
> > config->bufferSize.
> 
> There was a reason for doing it like this, but I don't recall what it was. 
> There was a certain amount for fragility in that code with respect to getting
> the set of visuals sent by the server to match the set of fbconfigs returned by
> the client-side driver.  I don't know if this is still an issue.

That was exactly the problem I was seeing on the server side.  The visuals
didn't match up in the server, but the problem was hidden on the client side by
the fact t__glXInitializeVisualConfigFromTags() always initializes indexBits to 0.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.