[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #10 from Chow Loong Jin 2009-10-27 23:24:14 PST --- (In reply to comment #9) > (In reply to comment #7) > > @Dan Nicholson: Sticking 64-bit libraries into /usr/lib64 instead of > > /usr/lib > > would require changing Debian's packaging policy as well as every > > derivative of > > Debian's policy to accomodate one library that won't work otherwise. > > So debian's policy is that 32 bit libraries go in /usr/lib32 on x86_64 but > their 32 bit libraries aren't actually installed there? So, is this is > multiarch or not? It sounds like it's not intended to be multiarch. It's not trivial to change the userland, and the package manager does not natively support multiarch. ia32-libs exists because of the need for 32-bit libraries in 64-bit. > I would agree with Corbin that this is NOTABUG since this case is pretty > convoluted and no one has ever needed it before. However, if you write a patch > that sets the search path from configure and leaves the current default (not > extending it with a path that hasn't been needed), then I'll commit it for > you. Will do. > You may want to open a bug in ubuntu to see what the developers say. If this > is > a debian/ubuntu policy, then I don't know why it hasn't come up before. I'm not sure about ia32-libs' history as I've only switched to 64-bit Ubuntu relatively recently (after Ubuntu 9.04's release), but I've talked to other developers and am personally an Ubuntu Contributing Developer myself. The bug in Ubuntu which I linked in comment #8 was filed on 2008-07-14, but never really got much attention, probably because not many actually played 32-bit GPU intensive games on 64-bit Ubuntu with Intel graphics. I myself did not notice that Wine was not getting direct rendering until the whole issue with Wine segfaulting as a result of a bad FBO returned by mesa under indirect rendering took place. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #9 from Dan Nicholson 2009-10-27 23:00:35 PST --- (In reply to comment #7) > @Dan Nicholson: Sticking 64-bit libraries into /usr/lib64 instead of /usr/lib > would require changing Debian's packaging policy as well as every derivative > of > Debian's policy to accomodate one library that won't work otherwise. So debian's policy is that 32 bit libraries go in /usr/lib32 on x86_64 but their 32 bit libraries aren't actually installed there? So, is this is multiarch or not? It sounds like it's not intended to be multiarch. I would agree with Corbin that this is NOTABUG since this case is pretty convoluted and no one has ever needed it before. However, if you write a patch that sets the search path from configure and leaves the current default (not extending it with a path that hasn't been needed), then I'll commit it for you. You may want to open a bug in ubuntu to see what the developers say. If this is a debian/ubuntu policy, then I don't know why it hasn't come up before. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Mon, Oct 05, 2009 at 09:14:04PM -0600, Brian Paul wrote: > The texformat-rework branch cleans up the texture format code. The > gl_texture_format struct is replaced by a simple gl_format enum (see > formats.h). This leads to assorted clean-ups in core mesa and the > drivers. This is a step toward unifying and cleaning up the texture > image and renderbuffer data structures. I am reading 3fa7db and 8c36ca. While GLchan-based formats are endian-neutral, the memory layout of formats like RGBA are affected by host endian. As a result, opt_sample_rgba_2d and others seem not respect the endian. -- Regards, olv -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #8 from Chow Loong Jin 2009-10-27 19:08:26 PST --- For reference, https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/248392 is the original bug downstream. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #7 from Chow Loong Jin 2009-10-27 19:07:18 PST --- @Dan Nicholson: Sticking 64-bit libraries into /usr/lib64 instead of /usr/lib would require changing Debian's packaging policy as well as every derivative of Debian's policy to accomodate one library that won't work otherwise. I'm not actually sure about what the case is like for GStreamer. However, the approach I am proposing is actually used within Gtk for loading modules which are usually found in /usr/lib/gtk-2.0 (i.e. it also searches within /usr/lib/gtk-2.0/ where GTK_HOST is defined to the $host found from configure. In fact, https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/369498 is what I was referring to when I came up with the patch. @Corbin Simpson: The compile time flag --with-dri-driverdir would fail if I set more than one path there, e.g. /usr/lib/dri:/usr/lib/dri/i486-pc-linux-gnu, and the LIBGL_DRIVERS_PATH environment variable would require that every 64-bit user running 32-bit OpenGL applications set the environment variable, which is hardly what I would consider appropriate. Also, you both were mentioning "changing the defaults". The patch I propose does not change the defaults, it just adds an extra search path. The original search path is preserved. Either way, if you wouldn't mind committing a patch that changes the path via a configure argument, then I'll just write up a patch that does that instead. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #6 from Corbin Simpson 2009-10-27 18:01:15 PST --- Multilib distributions always have extra baggage on their shoulders, and this is just one more bit of it. I'm really struggling to see how this is our problem when we've got not just a compile-time flag (--with-dri-driverdir) but also a run-time environment variable (LIBGL_DRIVERS_PATH) to configure this. I'd like to close as NOTOURBUG, but I'd like to make sure that nobody else wants to follow up on this. I also heavily encourage the original reporter to follow up with Ubuntu directly. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #5 from Dan Nicholson 2009-10-27 17:26:47 PST --- I don't think you can have it both ways. If your system's ABI is 32 bit in /usr/lib32 and 64 bit in /usr/lib, then you should probably build the binaries that way. If you want your system's ABI to be compatible with a 32 bit only system, then put the 64 bit libraries in /usr/lib64 like everybody else. Mesa libGL is certainly not the only library that dlopen's modules from private directories. What would you do about, say, gstreamer? I would commit a patch that changes the search path via a configure argument as long as it doesn't change the default. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #4 from Chow Loong Jin 2009-10-27 16:50:16 PST --- Building with --libdir=/usr/lib32 won't work, since 32-bit machines do use /usr/lib after all. The whole point of this was to avoid the requirement of rebuilding with different configure arguments, so that all the 32-bit libraries can be treated the same way (just repacking) for the multiarch ia32-libs package. As for --with-dri-searchpath, I think that can be handled without too many changes to the build system. If you're sure you'd like it that way, I can come up with a patch to make it that way. I just don't have a lot of time to spare a the moment and don't want to come up with numerous patches that get rejected one by one. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Make DRI/DRM state tracker interface less context-dependent
I'd just like to add that if other interfaces will exist in the future (I recall pipe_2d_context being floated at one time) and state trackers want to use them without initializing a pipe_context needlessly and want to reuse the rest of the DRM winsys then the relevent parts of this patch (or comparable changes) will need to be considered sooner or later regardless of whether or not pipe_video_context exists. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #3 from Dan Nicholson 2009-10-27 14:09:35 PST --- Why not just build mesa so that the paths are correct? There's even a switch, --with-dri-driverdir, that sets this correctly. I don't think things will work correctly if they get moved around after the installation. If Ubuntu multiarch uses /usr/lib32 for 32 bit libraries, why not just build with --libdir=/usr/lib32? If we really want to extend the search path, I'd rather keep the current default and allow overriding with --with-dri-searchpath or something. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Make DRI/DRM state tracker interface less context-dependent
On Tue, Oct 27, 2009 at 3:33 PM, José Fonseca wrote: > Yes. Younes, I really think it is better to crystallize this in a > separate branch until it reaches a point where the interfaces are > crystallized. The master branch is not always perfect, but it should > always near a state were a release can be made, and it seems that the > video interfaces need to mature a little more before that. > > Jose That's probably the best solution for everybody. I'll copy a video branch off master, remove the video stuff from master, and continue on in the video branch. Thanks. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Make DRI/DRM state tracker interface less context-dependent
On Tue, Oct 27, 2009 at 3:11 PM, Zack Rusin wrote:
> Younes,
>
> sorry for the slow response, we've been a bit busy lately.
> I can't say that I'm a huge fan of this patch. I've been thinking about it
> lately and essentially I'd like to reiterate what I said initially about the
> pipe_video_context. While I think it's a great idea, I'm not too excited about
> the way it looks right now. It boils down to three problems for me:
>
> 1) The interface itself. In particular:
>
> void (*clear_surface)(struct pipe_video_context *vpipe,
> unsigned x, unsigned y,
> unsigned width, unsigned height,
> unsigned value,
> struct pipe_surface *surface);
> is problematic for two reasons: a) because it's something that looks more like
> a pipe_context method in itself, b) because it's a combination of a
> surface_fill and clear interface which we moved away from in master
Thanks for the comments. I've changed this slightly in my tree to be
::surface_fill() and ::surface_copy() just as in pipe_context. The way
I see it in a video API implementation the client won't have a
pipe_context, so pipe_video_context has to provide these methods so
you can 1) initialize video surfaces (to black, in cases where the
video doesn't actually fill the entire frame) and 2) to copy the
surfaces to the front buffer. Unlike pipe_context these must be
provided because I don't expect surfaces that can't be rendered to to
exist in this context, the only surfaces that should exist are color
buffers. If someone wants/needs to implement these with their
pipe_context then they can, but if their video HW can handle it then
there's no need to initialize a pipe_context at all.
> void (*render_picture)(struct pipe_video_context *vpipe,
> /*struct pipe_surface *backround,
> struct pipe_video_rect*backround_area,*/
> struct pipe_video_surface *src_surface,
> enum pipe_mpeg12_picture_type picture_type,
> /*unsignednum_past_surfaces,
> struct pipe_video_surface *past_surfaces,
> unsigned num_future_surfaces,
> struct pipe_video_surface *future_surfaces,*/
> struct pipe_video_rect*src_area,
> struct pipe_surface *dst_surface,
> struct pipe_video_rect*dst_area,
> /*unsigned num_layers,
> struct pipe_texture *layers,
> struct pipe_video_rect*layer_src_areas,
> struct pipe_video_rect*layer_dst_areas,*/
> struct pipe_fence_handle **fence);
>
> has simply way too many arguments, not to mention that over a half is
> commented out. It's really a common problem for the entire interface, methods
> are very complex.
Well, because they're commented out we haven't really committed to
anything yet, I just had it in there as a reminder of what needs to be
supported for VDPAU (if you remove the comments this function maps
one-to-one with the VDPAU function that does the same thing). I can
implement it as settable states when the time comes if that's what
people prefer.
Gallium deals with it with settable state. Which brings us
> to another problem with the interface:
>
> struct pipe_video_context
> {
> struct pipe_screen *screen;
> enum pipe_video_profile profile;
> enum pipe_video_chroma_format chroma_format;
> unsigned width;
> unsigned height;
>... methods follow...
>
> which means that the interface is both an interface and a state.
> All of it is very un-gallium like.
However this isn't mutable state, they're effectively constants; once
you create a pipe_video_context with a set of parameters you get a
context that can only handle what you specified and everything else
fails, so they're there so it can easily be determined what this video
context handles. They could be behind getter functions if that's what
people prefer, but I'm the only one who uses this stuff so I apologize
if my personal habits sometimes sneak in...
> 2) We really need a real world video api implemented with the interface before
> making it public. So it should be proven that openmax or vdpau can actually be
> implemented using the interface before making it public.
Fair enough.
> 3) There's no hardware implementation for the interface and as far as i can
> see there's no plans for one. It's really what the interfaces are for, until
> we have people actually working on a hardware implementation there's no reason
> for this to be a Gallium interface at all.
>
> That's why i think the whole code should be an auxiliary module in which case
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #2 from Chow Loong Jin 2009-10-27 13:31:25 PST --- Well, the other way would be to recompile every 32-bit library within ia32-libs with --libdir=/usr/lib32, which doesn't seem like a particularly good idea to me either. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24766] 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 --- Comment #1 from Julien Cristau 2009-10-27 12:44:10 PST --- On Tue, Oct 27, 2009 at 11:40:05 -0700, bugzilla-dae...@freedesktop.org wrote: > On Ubuntu Karmic x86_64, all 32-bit applications which use DRI fail to have > Direct Rendering due to libGL.so searching in /usr/lib/dri, which contains > 64-bit DRI modules instead of /usr/lib32/dri. > > One of the bugs that this has caused is > http://bugs.winehq.org/show_bug.cgi?id=20448, which occurs in combination with > http://bugs.freedesktop.org/show_bug.cgi?id=23335. sounds like a packaging issue rather than a mesa bug? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [PATCH] Make DRI/DRM state tracker interface less context-dependent
On Tue, 2009-10-27 at 12:11 -0700, Zack Rusin wrote:
> On Saturday 24 October 2009 19:02:51 Younes Manton wrote:
> > Hi Thomas,
> >
> > I'd like to make these changes to make it possible to use the DRM
> > state tracker interface with contexts other than pipe_context. Nouveau
> > is the only public driver that does DRI1 from what I can see, but I've
> > been told that there are some closed drivers that also depend on these
> > interfaces and that you look after them.
> >
> > Added drm_api::create_video_context() to get a pipe_video_context, you
> > can ignore it. Changes to the st_* lock functions are trivial and
> > obvious, Nouveau doesn't use them but presumably anyone who does can
> > return pipe_context->priv just as easily. Changes to
> > dri1_api::front_srf_locked() are too, hopefully your front buffer can
> > be accessed via pipe_screen as well. I didn't change
> > dri1_api::present_locked() because we don't do page flipping yet, but
> > I think that could be done with just a screen as well in Nouveau.
> > Thoughts?
>
> Younes,
>
> sorry for the slow response, we've been a bit busy lately.
> I can't say that I'm a huge fan of this patch. I've been thinking about it
> lately and essentially I'd like to reiterate what I said initially about the
> pipe_video_context. While I think it's a great idea, I'm not too excited
> about
> the way it looks right now. It boils down to three problems for me:
>
> 1) The interface itself. In particular:
>
> void (*clear_surface)(struct pipe_video_context *vpipe,
> unsigned x, unsigned y,
> unsigned width, unsigned height,
> unsigned value,
> struct pipe_surface *surface);
> is problematic for two reasons: a) because it's something that looks more
> like
> a pipe_context method in itself, b) because it's a combination of a
> surface_fill and clear interface which we moved away from in master
>
> void (*render_picture)(struct pipe_video_context *vpipe,
> /*struct pipe_surface *backround,
> struct pipe_video_rect*backround_area,*/
> struct pipe_video_surface *src_surface,
> enum pipe_mpeg12_picture_type picture_type,
> /*unsignednum_past_surfaces,
> struct pipe_video_surface *past_surfaces,
> unsigned num_future_surfaces,
> struct pipe_video_surface *future_surfaces,*/
> struct pipe_video_rect*src_area,
> struct pipe_surface *dst_surface,
> struct pipe_video_rect*dst_area,
> /*unsigned num_layers,
> struct pipe_texture *layers,
> struct pipe_video_rect*layer_src_areas,
> struct pipe_video_rect*layer_dst_areas,*/
> struct pipe_fence_handle **fence);
>
> has simply way too many arguments, not to mention that over a half is
> commented out. It's really a common problem for the entire interface, methods
> are very complex. Gallium deals with it with settable state. Which brings us
> to another problem with the interface:
>
> struct pipe_video_context
> {
>struct pipe_screen *screen;
>enum pipe_video_profile profile;
>enum pipe_video_chroma_format chroma_format;
>unsigned width;
>unsigned height;
> ... methods follow...
>
> which means that the interface is both an interface and a state.
> All of it is very un-gallium like.
>
> 2) We really need a real world video api implemented with the interface
> before
> making it public. So it should be proven that openmax or vdpau can actually
> be
> implemented using the interface before making it public.
>
> 3) There's no hardware implementation for the interface and as far as i can
> see there's no plans for one. It's really what the interfaces are for, until
> we have people actually working on a hardware implementation there's no
> reason
> for this to be a Gallium interface at all.
>
> That's why i think the whole code should be an auxiliary module in which case
> patches like this one wouldn't be even necessary.
>
> When it comes to interfaces it's a lot harder to remove/significantly change
> an
> interface than to add a new one, so we should be extremely careful when
> adding
> interfaces and at least try to make sure that for all #1, #2 and #3 are
> fixable.
Yes. Younes, I really think it is better to crystallize this in a
separate branch until it reaches a point where the interfaces are
crystallized. The master branch is not always perfect, but it should
always near a state were a release can be mad
Re: [Mesa3d-dev] [PATCH] Make DRI/DRM state tracker interface less context-dependent
On Saturday 24 October 2009 19:02:51 Younes Manton wrote:
> Hi Thomas,
>
> I'd like to make these changes to make it possible to use the DRM
> state tracker interface with contexts other than pipe_context. Nouveau
> is the only public driver that does DRI1 from what I can see, but I've
> been told that there are some closed drivers that also depend on these
> interfaces and that you look after them.
>
> Added drm_api::create_video_context() to get a pipe_video_context, you
> can ignore it. Changes to the st_* lock functions are trivial and
> obvious, Nouveau doesn't use them but presumably anyone who does can
> return pipe_context->priv just as easily. Changes to
> dri1_api::front_srf_locked() are too, hopefully your front buffer can
> be accessed via pipe_screen as well. I didn't change
> dri1_api::present_locked() because we don't do page flipping yet, but
> I think that could be done with just a screen as well in Nouveau.
> Thoughts?
Younes,
sorry for the slow response, we've been a bit busy lately.
I can't say that I'm a huge fan of this patch. I've been thinking about it
lately and essentially I'd like to reiterate what I said initially about the
pipe_video_context. While I think it's a great idea, I'm not too excited about
the way it looks right now. It boils down to three problems for me:
1) The interface itself. In particular:
void (*clear_surface)(struct pipe_video_context *vpipe,
unsigned x, unsigned y,
unsigned width, unsigned height,
unsigned value,
struct pipe_surface *surface);
is problematic for two reasons: a) because it's something that looks more like
a pipe_context method in itself, b) because it's a combination of a
surface_fill and clear interface which we moved away from in master
void (*render_picture)(struct pipe_video_context *vpipe,
/*struct pipe_surface *backround,
struct pipe_video_rect*backround_area,*/
struct pipe_video_surface *src_surface,
enum pipe_mpeg12_picture_type picture_type,
/*unsignednum_past_surfaces,
struct pipe_video_surface *past_surfaces,
unsigned num_future_surfaces,
struct pipe_video_surface *future_surfaces,*/
struct pipe_video_rect*src_area,
struct pipe_surface *dst_surface,
struct pipe_video_rect*dst_area,
/*unsigned num_layers,
struct pipe_texture *layers,
struct pipe_video_rect*layer_src_areas,
struct pipe_video_rect*layer_dst_areas,*/
struct pipe_fence_handle **fence);
has simply way too many arguments, not to mention that over a half is
commented out. It's really a common problem for the entire interface, methods
are very complex. Gallium deals with it with settable state. Which brings us
to another problem with the interface:
struct pipe_video_context
{
struct pipe_screen *screen;
enum pipe_video_profile profile;
enum pipe_video_chroma_format chroma_format;
unsigned width;
unsigned height;
... methods follow...
which means that the interface is both an interface and a state.
All of it is very un-gallium like.
2) We really need a real world video api implemented with the interface before
making it public. So it should be proven that openmax or vdpau can actually be
implemented using the interface before making it public.
3) There's no hardware implementation for the interface and as far as i can
see there's no plans for one. It's really what the interfaces are for, until
we have people actually working on a hardware implementation there's no reason
for this to be a Gallium interface at all.
That's why i think the whole code should be an auxiliary module in which case
patches like this one wouldn't be even necessary.
When it comes to interfaces it's a lot harder to remove/significantly change an
interface than to add a new one, so we should be extremely careful when adding
interfaces and at least try to make sure that for all #1, #2 and #3 are
fixable.
Also it's worth noting that Keith is the maintainer for Gallium interfaces, so
pipe_video_context and, in general, all changes to Gallium should always go
through him.
z
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us
[Mesa3d-dev] [Bug 24766] New: 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri
http://bugs.freedesktop.org/show_bug.cgi?id=24766 Summary: 32-bit libGL.so searches for DRI modules in /usr/lib/dri instead of /usr/lib32/dri Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: GLX AssignedTo: mesa3d-dev@lists.sourceforge.net ReportedBy: hyper...@gmail.com Created an attachment (id=30758) --> (http://bugs.freedesktop.org/attachment.cgi?id=30758) Additionally search in /usr/lib/dri// for DRI modules On Ubuntu Karmic x86_64, all 32-bit applications which use DRI fail to have Direct Rendering due to libGL.so searching in /usr/lib/dri, which contains 64-bit DRI modules instead of /usr/lib32/dri. One of the bugs that this has caused is http://bugs.winehq.org/show_bug.cgi?id=20448, which occurs in combination with http://bugs.freedesktop.org/show_bug.cgi?id=23335. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texformat-rework branch
On Mon, Oct 26, 2009 at 3:06 PM, Brian Paul wrote: > Alex Deucher wrote: >> >> On Fri, Oct 23, 2009 at 5:23 PM, Brian Paul wrote: >>> >>> Alex, Nicolai, >>> >>> Would you guys please test the texformat-rework branch again? >>> >>> If it looks OK, I'd like to merge to master soon, but probably not until >>> next week. >> >> Most apps assert: >> radeon_create_renderbuffer: Unknown format 0x001b >> glxgears: main/renderbuffer.c:1981: _mesa_add_renderbuffer: Assertion >> `rb' failed. > > Here's a patch to try. That seems to fix it. Alex > > -Brian > > > diff --git a/src/mesa/drivers/dri/radeon/radeon_fbo.c > b/src/mesa/drivers/dri/radeon/radeon_fbo.c > index 4084682..fc0d312 100644 > --- a/src/mesa/drivers/dri/radeon/radeon_fbo.c > +++ b/src/mesa/drivers/dri/radeon/radeon_fbo.c > @@ -280,12 +280,17 @@ radeon_create_renderbuffer(gl_format format, > __DRIdrawablePrivate *driDrawPriv) > rrb->base.DataType = GL_UNSIGNED_SHORT; > rrb->base._BaseFormat = GL_DEPTH_COMPONENT; > break; > + case MESA_FORMAT_X8_Z24: > + rrb->base.DataType = GL_UNSIGNED_INT; > + rrb->base._BaseFormat = GL_DEPTH_COMPONENT; > + break; > case MESA_FORMAT_S8_Z24: > rrb->base.DataType = GL_UNSIGNED_INT_24_8_EXT; > rrb->base._BaseFormat = GL_DEPTH_STENCIL; > break; > default: > - fprintf(stderr, "%s: Unknown format 0x%04x\n", __FUNCTION__, > format); > + fprintf(stderr, "%s: Unknown format %s\n", > + __FUNCTION__, _mesa_get_format_name(format)); > _mesa_delete_renderbuffer(&rrb->base); > return NULL; > } > > -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] r600: implement ARB_occlusion_query
On Mon, Oct 26, 2009 at 5:32 PM, Alex Deucher wrote:
> On Mon, Oct 26, 2009 at 4:55 AM, Stephan Schmid wrote:
>> This implements GL_ARB_occlusion_query for RV610
>> Currently it results in a huge performance gain in games that take advantage
>> of
>> ARB_oq such as sauerbraten (cube2).
>> issues:
>> - this was tested so far only on RV610. I figured out that the RV610 writes
>> one
>> single uint64_t value when triggering the zpass write event. The specs
>> aren't
>> too clear about what exactly is written.
>> It might be that there are multiple zpass counters on chip and that
>> r6xx/r7xx
>> chips write one uint64_t per counter (just as the r300 do it). In this case
>> the
>> RV610 would write only one value because it's one of the smallest chips in
>> the
>> family so it's got only one counter.
>> If my assumtion were true it would be necessary to use n*sizeof(uint64_t) in
>> r600_emit_query_finish as offset (n = number of counters/values written) and
>> to consider the additional values in radeonQueryGetResult when computing the
>> result of the query.
>> It would be interesting to know what the other r6xx/r7xx write on
>> zpass-write event
>> to support them as well.
>
> Stephan,
>
> Nice work! The zpass stuff is per DB just like the older chips, so
> you'll need to allocate enough memory to support two qwords for each
> DB. The number of DBs depends on the asic. We'll probably need a drm
> query similar to what we do for r300. I'm working on a cleaned up
> version of your mesa patch and a drm patch to return the number of RBs
> like we do for r300.
After testing, it seems r6xx aggregates the zpass results from all DB
blocks into 1 qword. R7xx, seems to work differently. I'm following
up internally. The attached patch works properly on all r6xx cards I
have and certain r7xx cards. tri-query and glean oq tests pass.
Alex
From 888e8fd56788bcf4fc42b9d630ad1c4a01d8c9b1 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Tue, 27 Oct 2009 03:50:58 -0400
Subject: [PATCH] r600: add occlusion query support
Based on initial patch from Stephan Schmid .
Basic idea is to dump the zpass count before and after and substract
to get the total number of visible fragments. R6xx appears to
aggregate the results of all DB blocks into a single qword and works
properly on all cards I've tested on. R7xx seems to work differently
and needs follow up.
Signed-off-by: Alex Deucher
---
src/mesa/drivers/dri/r600/r600_context.c | 28 --
src/mesa/drivers/dri/r600/r700_chip.c | 50 +
src/mesa/drivers/dri/r600/r700_state.c|1 +
src/mesa/drivers/dri/radeon/radeon_queryobj.c | 28 +++---
4 files changed, 97 insertions(+), 10 deletions(-)
diff --git a/src/mesa/drivers/dri/r600/r600_context.c b/src/mesa/drivers/dri/r600/r600_context.c
index c1bf76d..6fe2926 100644
--- a/src/mesa/drivers/dri/r600/r600_context.c
+++ b/src/mesa/drivers/dri/r600/r600_context.c
@@ -64,6 +64,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include "r600_cmdbuf.h"
#include "r600_emit.h"
#include "radeon_bocs_wrapper.h"
+#include "radeon_queryobj.h"
#include "r700_state.h"
#include "r700_ioctl.h"
@@ -73,11 +74,8 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include "utils.h"
#include "xmlpool.h" /* for symbolic values of enum-type options */
-/* hw_tcl_on derives from future_hw_tcl_on when its safe to change it. */
-int future_hw_tcl_on = 1;
-int hw_tcl_on = 1;
-
#define need_GL_VERSION_2_0
+#define need_GL_ARB_occlusion_query
#define need_GL_ARB_point_parameters
#define need_GL_ARB_vertex_program
#define need_GL_EXT_blend_equation_separate
@@ -98,6 +96,7 @@ static const struct dri_extension card_extensions[] = {
/* *INDENT-OFF* */
{"GL_ARB_depth_texture", NULL},
{"GL_ARB_fragment_program", NULL},
+ {"GL_ARB_occlusion_query",GL_ARB_occlusion_query_functions},
{"GL_ARB_multitexture", NULL},
{"GL_ARB_point_parameters", GL_ARB_point_parameters_functions},
{"GL_ARB_shadow", NULL},
@@ -204,6 +203,25 @@ static void r600_fallback(GLcontext *ctx, GLuint bit, GLboolean mode)
context->radeon.Fallback &= ~bit;
}
+static void r600_emit_query_finish(radeonContextPtr radeon)
+{
+ context_t *context = (context_t*) radeon;
+ BATCH_LOCALS(&context->radeon);
+
+ struct radeon_query_object *query = radeon->query.current;
+
+ BEGIN_BATCH_NO_AUTOSTATE(4 + 2);
+ R600_OUT_BATCH(CP_PACKET3(R600_IT_EVENT_WRITE, 2));
+ R600_OUT_BATCH(ZPASS_DONE);
+ R600_OUT_BATCH(query->curr_offset); /* hw writes qwords */
+ R600_OUT_BATCH(0x);
+ R600_OUT_BATCH_RELOC(VGT_EVENT_INITIATOR, query->bo, 0, 0, RADEON_GEM_DOMAIN_GTT, 0);
+ END_BATCH();
+ query->curr_offset += 8 * sizeof(uint64_t);
+ assert(query->curr_offset < RADEON_QUERY_PAGE_SIZE);
+ query->emitted_begin = GL_FALSE;
+}
+
static void r600_init_vtbl(radeonContextPtr radeon)
{
radeon->vtbl.get_lock = r600_get_lock;
@@ -212
