Re: [Mesa3d-dev] [PATCH] nv40: remove leftover nv40_transfer.c from unification into nvfx
On Mon, Mar 15, 2010 at 9:35 AM, Luca Barbieri l...@luca-barbieri.com wrote:
---
src/gallium/drivers/nv40/nv40_transfer.c | 181
--
1 files changed, 0 insertions(+), 181 deletions(-)
delete mode 100644 src/gallium/drivers/nv40/nv40_transfer.c
diff --git a/src/gallium/drivers/nv40/nv40_transfer.c
b/src/gallium/drivers/nv40/nv40_transfer.c
deleted file mode 100644
index 3d8c8e8..000
--- a/src/gallium/drivers/nv40/nv40_transfer.c
+++ /dev/null
@@ -1,181 +0,0 @@
-#include pipe/p_state.h
-#include pipe/p_defines.h
-#include util/u_inlines.h
-#include util/u_format.h
-#include util/u_memory.h
-#include util/u_math.h
-#include nouveau/nouveau_winsys.h
-#include nv40_context.h
-#include nvfx_screen.h
-#include nvfx_state.h
-
-struct nv40_transfer {
- struct pipe_transfer base;
- struct pipe_surface *surface;
- boolean direct;
-};
-
-static void
-nv40_compatible_transfer_tex(struct pipe_texture *pt, unsigned width,
unsigned height,
- struct pipe_texture *template)
-{
- memset(template, 0, sizeof(struct pipe_texture));
- template-target = pt-target;
- template-format = pt-format;
- template-width0 = width;
- template-height0 = height;
- template-depth0 = 1;
- template-last_level = 0;
- template-nr_samples = pt-nr_samples;
-
- template-tex_usage = PIPE_TEXTURE_USAGE_DYNAMIC |
- NOUVEAU_TEXTURE_USAGE_LINEAR;
-}
-
-static struct pipe_transfer *
-nv40_transfer_new(struct pipe_context *pcontext, struct pipe_texture *pt,
- unsigned face, unsigned level, unsigned zslice,
- enum pipe_transfer_usage usage,
- unsigned x, unsigned y, unsigned w, unsigned h)
-{
- struct pipe_screen *pscreen = pcontext-screen;
- struct nvfx_miptree *mt = (struct nvfx_miptree *)pt;
- struct nv40_transfer *tx;
- struct pipe_texture tx_tex_template, *tx_tex;
-
- tx = CALLOC_STRUCT(nv40_transfer);
- if (!tx)
- return NULL;
-
- pipe_texture_reference(tx-base.texture, pt);
- tx-base.x = x;
- tx-base.y = y;
- tx-base.width = w;
- tx-base.height = h;
- tx-base.stride = mt-level[level].pitch;
- tx-base.usage = usage;
- tx-base.face = face;
- tx-base.level = level;
- tx-base.zslice = zslice;
-
- /* Direct access to texture */
- if ((pt-tex_usage PIPE_TEXTURE_USAGE_DYNAMIC ||
- debug_get_bool_option(NOUVEAU_NO_TRANSFER, TRUE/*XXX:FALSE*/))
- pt-tex_usage NOUVEAU_TEXTURE_USAGE_LINEAR)
- {
- tx-direct = true;
- tx-surface = pscreen-get_tex_surface(pscreen, pt,
- face, level, zslice,
-
pipe_transfer_buffer_flags(tx-base));
- return tx-base;
- }
-
- tx-direct = false;
-
- nv40_compatible_transfer_tex(pt, w, h, tx_tex_template);
-
- tx_tex = pscreen-texture_create(pscreen, tx_tex_template);
- if (!tx_tex)
- {
- FREE(tx);
- return NULL;
- }
-
- tx-base.stride = ((struct nvfx_miptree*)tx_tex)-level[0].pitch;
-
- tx-surface = pscreen-get_tex_surface(pscreen, tx_tex,
- 0, 0, 0,
-
pipe_transfer_buffer_flags(tx-base));
-
- pipe_texture_reference(tx_tex, NULL);
-
- if (!tx-surface)
- {
- pipe_surface_reference(tx-surface, NULL);
- FREE(tx);
- return NULL;
- }
-
- if (usage PIPE_TRANSFER_READ) {
- struct nvfx_screen *nvscreen = nvfx_screen(pscreen);
- struct pipe_surface *src;
-
- src = pscreen-get_tex_surface(pscreen, pt,
- face, level, zslice,
- PIPE_BUFFER_USAGE_GPU_READ);
-
- /* TODO: Check if SIFM can deal with x,y,w,h when swizzling */
- /* TODO: Check if SIFM can un-swizzle */
- nvscreen-eng2d-copy(nvscreen-eng2d,
- tx-surface, 0, 0,
- src, x, y,
- w, h);
-
- pipe_surface_reference(src, NULL);
- }
-
- return tx-base;
-}
-
-static void
-nv40_transfer_del(struct pipe_context *pcontext, struct pipe_transfer *ptx)
-{
- struct nv40_transfer *tx = (struct nv40_transfer *)ptx;
-
- if (!tx-direct (ptx-usage PIPE_TRANSFER_WRITE)) {
- struct pipe_screen *pscreen = pcontext-screen;
- struct nvfx_screen *nvscreen = nvfx_screen(pscreen);
-
Re: [Mesa3d-dev] [Nouveau] [PATCH] nv30/nv40 Gallium drivers unification
On Sat, Mar 13, 2010 at 1:29 PM, Luca Barbieri l...@luca-barbieri.com wrote: Currently the nv30 and nv40 Gallium drivers are very similar, and contain about 5000 lines of essentially duplicate code. I prepared a patchset (which can be found at http://repo.or.cz/w/mesa/mesa-lb.git/shortlog/refs/heads/unification+fixes) which gradually unifies the drivers, one file per the commit. A new nvfx directory is created, and unified files are put there one by one. After all patches are applied, the nv30 and nv40 directories are removed and the only the new nvfx directory remains. The first patches unify the engine naming (s/curie/eng3d/g; s/rankine/eng3d), and switch nv40 to use the NV34TCL_ constants. Initial versions of this work changed renouveau.xml to create a new NVFXTCL object, but the current version doesn't need any renouveau.xml modification at all. The unification+fixes branch referenced above is the one that should be tested. The unification branch contains just the unification, with no behavior changes, while unification+fixes also fixes swtnl and quad rendering, allowing to better test the unification. Some cleanups on top of the unfication are also included. That same repository also contains other branches with significant improvements on top of the unification, but I'm still not proposing them for inclusion as they need more testing and some fixes. While there are some branches in the Mesa repository that would conflict with this, such branches seem to be popping up continuously (and this is good!), so waiting until they are merged probably won't really work. The conflicts are minimal anyway and the driver fixes can be very easily reconstructed over the unified codebase. How about merging this? Any objections? Any comments? Pushed. Thanks. -- 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 Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Proposed gallium buffer/texture evolution
On Mon, Feb 8, 2010 at 10:24 PM, Luca Barbieri luca.barbi...@gmail.com wrote: By making transfers context-private and non-shareable, it becomes possible for a driver to implement interleaved drawing and dma-uploads within a single command buffer. While we do this, how about removing transfer map and unmap functions and making the create and destroy functions do mapping and unmapping? Since the transfer contents are flushed on destroy, anything other than calling map just after create and unmap just before destroy does not offer any benefit, so we may as well merge the functionality. Another option would be to flush on unmap and let transfer objects be permanent, but I think this would complicate both state trackers and drivers for a very dubious performance improvement. Map/unmap make it all the way to the user's program, and there will likely be cases where user code maps/unmaps a buffer multiple times before drawing. The current transfer semantics can handle that with zero-copy if the state tracker does the right thing with it. If performance matters transfer creation can be made cheaper by not malloc'ing. Transfers aren't refcounted anyway so I don't see much of a benefit in forcing them to be dynamically allocated. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Proposed gallium buffer/texture evolution
On Mon, Feb 8, 2010 at 11:51 PM, Luca Barbieri luca.barbi...@gmail.com wrote: Map/unmap make it all the way to the user's program, and there will likely be cases where user code maps/unmaps a buffer multiple times before drawing. The current transfer semantics can handle that with zero-copy if the state tracker does the right thing with it. OpenGL does not allow you to map textures and when other APIs exposes map/unmap, I think the API unmap is always supposed to actually change the texture (this is also the case for OpenGL mapping of buffers), which transfer unmap does not do, since it is done by destroy. Thus, API map must be implemented with transfer create+map and API unmap must be implemented with transfer unmap+destroy, defeating the purpose of having them separate. Well, if I understood Keith correctly pipe_transfers will apply to all buffers, not just textures. Anyhow, If I recall you can glMapBuffer a PBO as many times as you want and the transfer to the actual texture only occurs when glTexImage2D is called. In an API like D3D that has texture lock(x,y,w,h)/unlock() operations IIRC there's no requirement that unlock() flushes anything. I think they even keep track of dirty rects for lock/unlock and upload the minimal enclosing rect during validation in such cases. Instead of combining create/map and unmap/destroy it would be better to make map more powerful. If the API says otherwise, with merged functions, you can just remove the calls to map/unmap and have equivalent behavior. Basically the only thing you lose is the ability to unmap and then remap the transfer while using it. On many drivers this is a no-op, and where it actually does a munmap and mmap, you just decrease performance for no significant benefits. That would make map_buffer_range() kind of useless wouldn't it? You would allocate a transfer the size of the entire buffer and ignore the range param. If you wanted to allocate a transfer at every map_buffer_range() instead you would miss an opportunity to coalesce a bunch of map/unmaps together. Potentially someone could update the entire buffer in many small ranges. In fact, I think in the whole Mesa/Gallium codebase, get_tex_transfer is always immediately followed by transfer_map, and likewise for unmap and destroy. To me it makes sense to optimize at least two things for transfers: the size of the transfer buffer and the amount of data transferred. Transfer creation can deal with the size of the buffer, map/unmap with a range/rect param can deal with the amount of data being transferred. If you know ahead of time the subset of data being considered you can create a transfer to cover only that range, if not you can create a transfer to cover the entire buffer. At map/unmap time if you know the subset of data being read/written you can optimize the amount of data being transferred, especially in the write-only case where you can keep track of the dirty ranges and possibly combine them to fewer uploads. If you combine create+map and unmap+destroy you end up limiting yourself for no reason other than minor convenience. If performance matters transfer creation can be made cheaper by not malloc'ing. Transfers aren't refcounted anyway so I don't see much of a benefit in forcing them to be dynamically allocated. The problem is that usually you have driver specific data after pipe_transfer, so the size is not known by the state tracker. A possible improvement could be to add a private pointer to pipe_transfer and make it a structure allocated by the caller and passed by reference to transfer_create. Then, drivers implementing transfers by just giving a pointer to the texture do not need private data, and others need to allocate the temporary buffer anyway, and the private transfer structure allocation is cheap compared to that. Basically pipe_transfer would become a cookie returned by create+map for use by unmap+destroy to flush the temporary buffer, if present. What I was actually imagining was letting the driver specify the size of its pipe_transfer objects (this size would have to be consistent) and letting the caller allocate the space so that the caller could either allocate the transfers once [or abuse alloca() if applicable] and the driver could simply init/cleanup the transfer data members every time it was required. A little less clean, but maybe worth it for objects that get created/destroyed potentially many times per frame. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net
Re: [Mesa3d-dev] buffer usage, ttm [RE: [RFC] gallium-multiple-constant-buffers merge
On Fri, Jan 22, 2010 at 11:41 AM, Keith Whitwell kei...@vmware.com wrote: Christoph, The vertex usage issue is a bug and can be fixed. It sounds like you're really asking for another flag that indicates the expected lifetime of the buffer. That sounds orthogonal to the ones we already have describing the possible binding points. I suspect ttm is already reusing buffer memory for you (userspace sub-allocation), so the weight of the ttm calls you are making may be less than you suspect. Keith From: Christoph Bumiller [e0425...@student.tuwien.ac.at] Sent: Friday, January 22, 2010 8:35 AM To: Keith Whitwell Cc: Michal Krol; mesa3d-dev Subject: Re: [Mesa3d-dev] [RFC] gallium-multiple-constant-buffers merge On 22.01.2010 17:01, Keith Whitwell wrote: Christoph, The USAGE_CONSTANT flag is a bit confusing -- the intention is to state that this buffer can be bound as a constant-buffer, not that it is itself immutable. It should be perfectly legal to create a single constant buffer and update it over time... I didn't interpret the USAGE_CONSTANT as meaning the buffer's contents should be constant at all, I just meant it should not be used for throw-away constant buffers. The same is done for vertex buffers created for glVertexPointer etc., they do NOT have PIPE_BUFFER_USAGE_VERTEX (they are user_buffer_create), but STILL get set as vertex buffers. Alternatively, rather than not using USAGE_CONSTANT/VERTEX on those, we could finally add PIPE_BUFFER_USAGE_STATIC,STREAM,THROW_AWAY ... Of course, maybe we shouldn't take the buffer_create function literally and ask TTM to create a new buffer object every time it's called ... I admit that this whole thing is a pipe driver specific issue. Keith From: Christoph Bumiller [e0425...@student.tuwien.ac.at] Sent: Thursday, January 21, 2010 3:48 PM To: Michal Krol Cc: mesa3d-dev; Keith Whitwell Subject: Re: [Mesa3d-dev] [RFC] gallium-multiple-constant-buffers merge On 21.01.2010 20:20, michal wrote: Hi, This simple feature branch adds support for two-dimensional constant buffers in TGSI. An example shader would look like this: FRAG DCL IN[0], COLOR, LINEAR DCL OUT[0], COLOR DCL CONST[1][1..2] MAD OUT[0], IN[0], CONST[1][2], CONST[1][1] END For this to work, one needs to bind a buffer to slot nr 1 containing at least 3 vectors. I've been thinking about what to do with these multiple constant buffers now, and I thought we might want to avoid creating those buffers with PIPE_BUFFER_USAGE_CONSTANT that will be used only once and then discarded, as the currently used uniform buffer is. Instead it should only be set for persistent ones that the user created with glGenBuffers'd etc. (this would be similar to our usage of PIPE_BUFFER_USAGE_VERTEX). Then I would be able to decided whether to put them in VRAM or in user memory (since creation of VRAM buffers is a bit costly), and then either copy/upload constants from the buffer if it's user, or bind it's GPU virt. address to the program CB it if it's VRAM. Of course, I don't know if it would even be noticeable performance-wise if I just kept around a bunch of buffers and pushed constants all the time ... Any thoughts ? Thanks, Christoph Expected lifetime flags would be useful for both textures and buffers. One-time-use buffers (like the ones st/mesa uses for immediate mode) and textures may not even need to be backed by a BO on some hardware, they can be shoved into the command stream, but with the current setup it's hard to detect that. The only flag we have now is pipe_texture_usage_dynamic and that's used on nv30-40 to place textures in system memory for faster CPU access, since nv30-40 can texture from system memory. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] egl_g3d ximage backend transfer usage is broken
On Mon, Jan 18, 2010 at 9:10 PM, Chia-I Wu olva...@gmail.com wrote: On Tue, Jan 19, 2010 at 7:58 AM, Luca Barbieri l...@luca-barbieri.com wrote: The XImage backend keeps a transfer permanently and map/unmaps to do modifications. However, Gallium transfers can be implemented by making and keeping a copy of the surface, flushing it back on transfer destruction. Thus, it should be fixed to create and destroy a transfer every time it maps the surface. Thanks, that should be an easy fix. But I do wonder if a pipe transfer is always supposed to be temporary? Its operations, transfer_map and transfer_unmap, kind of hinted me that the pipe transfer can be used repeatedly. -olv It was my understanding that the transfer happened on destroy and that was how the nouveau implementations were written. You can probably find the original thread, IIRC it was Michael Danzer that did the interface and softpipe. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium feature levels
On Tue, Jan 12, 2010 at 9:44 AM, Keith Whitwell kei...@vmware.com wrote: On Tue, 2010-01-12 at 06:33 -0800, Roland Scheidegger wrote: Profile 7 (2009)6 (2008) 5 (2006)4 (2004)3 (2003)2 (2002) 1 (2000) Fragment Shader Yes Yes Yes Yes Yes Yes Yes DX 7 didn't have any shader model IIRC. DX8/8.1 introduced shader models 1.0-1.3/1.4. Yea, that level should be gone. Though thinking about this, maybe we should keep a level below lowest dx9 feature level, since gallium drivers exist which are pretty low on the feature scale (like the nv04/10/20). I don't know how well they'll ever going to work, since they'd need the fixed function fragment operations out of tgsi, but maybe we shouldn't prevent it by forcing them to announce support of fragment shaders. The base level of gallium functionality included fragment shaders from the start, these early nv drivers don't really change that. In my view these are a speculative bet that with a lot of effort it is possible to turn shaders back into fixed-function, but supporting that isn't a design goal for gallium as a whole. Keith Just my opinion, I wouldn't count on nv04-nv20 actually staying in gallium. At some point we wanted to experiment with shaders on fixed func, but I don't think anyone is really motivated or optimistic that it will turn out well. They're already rotting as it is. Francisco Jerez is working on a classic Mesa driver for these and if/when they're worth pushing to master I'd expect the gallium drivers to be axed. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Yet more r300g fear and loathing...
On Mon, Dec 21, 2009 at 3:02 AM, Corbin Simpson mostawesomed...@gmail.com wrote: So, yet another thing that r300 sucks balls at: NPOT textures. We've been talking it over on IRC, and here's the options. 1) Don't do NPOT. Stop advertising PIPE_CAP_NPOT, refuse to accept non-NPOT dimensions on textures. This sucks because it means that we don't get GL 2.0, which means most apps (bless their non-compliant souls) will refuse to attempt GLSL, which means that there's really no point in continuing this driver. 2) Don't do NPOT in the pipe, but do it in the state tracker instead, as needed. Write up the appropriate fallbacks, and then let ARB_npot be advertised by the state tracker regardless of whether PIPE_CAP_NPOT is set. Lots of typing, though. Lots and lots of typing. 3) Same as above, but put all the fallbacks in the pipe instead of the state tracker. I am *really* not fond of this, since PIPE_CAP was not intended for lies, but it was mentioned in IRC, so I gotta mention it here. 3) The fglrx special: Don't require ARB_npot for advertising GL 2.0. I figured this wasn't on the table, but you never know... Also: Can we assume that texrects are part of core, or are there shaderful chipsets without them? NV30 is in the same boat IIRC, so something shareable would be nice. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium: add blitter
On Mon, Dec 14, 2009 at 11:42 AM, Corbin Simpson mostawesomed...@gmail.com wrote: As far as immediate verts, why don't we just add support to r300g to switch to immediate mode for small VBOs? Posting from a mobile, pardon my terseness. ~ C. That was what I was thinking for Nouveau, silently create a user buffer for size some threshold and when we get a draw call with a user vertex buffer submit it in immediate mode. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thu, Dec 10, 2009 at 11:44 AM, Zack Rusin za...@vmware.com wrote:
On Thursday 10 December 2009 11:25:48 Younes Manton wrote:
On Thu, Dec 10, 2009 at 5:32 AM, Zack Rusin za...@vmware.com wrote:
On Wednesday 09 December 2009 20:30:56 Igor Oliveira wrote:
Hi Zack,
1) agreed. OpencCL is a complete different project and should exist in
a different repository.
1.1) Well use Gallium as CPU backend is a software dilemma:
All problems in computer science can be solved by another level of
indirection...except for the problem of too many layers of
indirection
But in my opinion we can use Gallium for CPU operations too, using
gallium as a backend for all device types we maintain a code
consistency.
Yes, it will certainly make the code a lot cleaner. I think using
llvmpipe we might be able to get it working fairly quickly. I'll need to
finish a few features in Gallium3d first. In particular we'll need to
figure out how to handle memory hierarchies, i.e. private/shared/global
memory accesses in shaders. Then we'll have some basic tgsi stuff like
scatter reads and writes to structured buffers, types in tgsi (int{8-64},
float, double}, barrier and memory barrier instructions, atomic reduction
instructions, performance events and likely trap/breakpoint instructions.
We'll be getting all those fixed within the next few weeks.
Doesn't seem like the current pipe_context is suited to the
requirements of a compute API.
Can you be more specific? Which parts you don't think are suited for it?
Should it be made larger or is another kind of context in order?
I don't see anything missing from pipe_context to warrant a new interface.
What exactly is your concern?
Well how do we keep the compute state seperate from the 3D state, and
how do you mix the two? Do you have two state trackers using the same
pipe_context and re-emitting their entire states to the HW as
necessary? Do you use two pipe_contexts? What about cards that know
about compute and keep a seperate state? When you set a shader/read
buffer/write buffer/const buffer with the pipe_context it's not clear
to me what we should do on the driver's side.
Under the hood on nvidia cards there's are
seperate hardware interfaces for compute, graphics, video, even though
there is some duplicate functionality, so it's not like most of the
code of our current pipe_context would be reused*, so to me a
different type of context makes sense.
Really? To be honest I've never seen any compute specific hardware in nvidia,
what is it?
The card basically has seperate state for DMA, 2D, 3D, video, compute
on nv50+, and a bunch of others. When we create a pipe_context we bind
the DMA, 2D, and 3D and some of the others and issue commands. For
nv50 we have a compute state, but we need to know what to do with
commands coming through pipe_context, are they for 3D or compute?
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] PATCH[0/1]: OpenCL: create and implement stub context methods
On Thu, Dec 10, 2009 at 3:34 PM, Zack Rusin za...@vmware.com wrote:
On Thursday 10 December 2009 15:14:46 Younes Manton wrote:
OK, so we seem to be on the same page here, pipe_context will get some
more functions. That's what I was originally asking about, will
pipe_context grow or will there be a new kind of context? From my POV
we would end up in roughly the same place either way.
In general it's safe to assume that pipe_context as the main Gallium3d
interface will largely model the modern pipeline. Meaning that the Gallium3d
pipeline will look a lot like D3D 11 pipeline because realistically that's
what's going to get the most attention from hardware vendors. So effectively
1) input assembler
2) vertex shader
3) hull shader
4) tessellator
5) domain shader
6) geometry shader
7) rasterizer
8) pixel shader
9) compute shader
10) output merger
When it comes to compute OpenCL is more robust so the compute resources will
be designed to make sure CL 1.1 is easily implementable and certainly make it
possible to use compute without graphics but the pipeline itself will have to
stay as outlined above otherwise we'd just be asking for trouble. Does that
make sense?
Makes perfect sense, I just had a completely different looking, yet
practically identical picture that put orthogonal functionality (2D,
3D, compute, video) in seperate 'contexts' as far as gallium was
concerned, even if everything ended up in the same command buffer on
the backend.
pipe_foo_context { foo(); bar(); }
pipe_shaz_context { shaz(); blam(); }
...
vs
pipe_context { foo(); bar(); shaz(); blam(); }
If we want to grow pipe_context beyond just 3D then thats fine too,
it's just that I was operating under the assumption that pipe_context
was for 3D all this time, so that's where the confusion comes from.
Cheers.
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Branch pipe-format-simplify open for review
On Tue, Dec 8, 2009 at 9:55 AM, michal mic...@vmware.com wrote: This branch simplifies pipe/p_format.h by making enum pipe_format what it should have been -- an enum. As a result there is no extra information encoded in it and one needs to use auxiliary/util/u_format.h to get that info instead. Linking to the auxiliary/util lib is necessary. Please review and if you can test if it doesn't break your setup, I will appreciate it. I would like to hear from r300 and nouveau guys, as those drivers were using some internal macros and I weren't 100% sure I got the conversion right. Thanks! The Nouveau stuff that you touched looks correct to me. Any particular reason why the enums are explicitly numbered? I'd let the compiler do the numbering for us unless there's a reason not to. (Or is the intention here that future additions only happen at the tail and we therefore implicitly threaten anyone considering otherwise with the prospect of tediously updating all the entries that follow? :) ) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] st/mesa: Coalesce imm mode prims into a single draw call
Is there anything in the spec or mesa internals that say this isn't
allowed? I was trying to fix what seems like an unrelated HW errata
with no luck, but it might as well be used if it's useful. I'll apply
if no one raises any concerns.
diff --git a/src/mesa/state_tracker/st_draw.c b/src/mesa/state_tracker/st_draw.c
index c76bff9..794b426 100644
--- a/src/mesa/state_tracker/st_draw.c
+++ b/src/mesa/state_tracker/st_draw.c
@@ -672,14 +672,36 @@ st_draw_vbo(GLcontext *ctx,
prims[i].start + indexOffset,
prims[i].count);
}
else {
- for (i = 0; i nr_prims; i++) {
-setup_edgeflags(ctx, prims[i].mode,
-prims[i].start + indexOffset, prims[i].count,
-arrays[VERT_ATTRIB_EDGEFLAG]);
-
-pipe-draw_elements(pipe, indexBuf, indexSize,
-prims[i].mode,
-prims[i].start + indexOffset, prims[i].count);
+ if (ctx-Polygon.FrontMode == GL_FILL
+ ctx-Polygon.BackMode == GL_FILL) {
+/* Coalesce runs of prims into a single draw call */
+for (i = 0; i nr_prims; i++) {
+ GLuint firstPrimMode = prims[i].mode;
+ GLuint firstPrimStart = prims[i].start;
+ GLuint totalCount = prims[i].count;
+ if (firstPrimMode != GL_TRIANGLE_STRIP
firstPrimMode != GL_TRIANGLE_FAN)
+ while (i + 1 nr_prims prims[i + 1].mode ==
firstPrimMode
+ prims[i + 1].start == prims[i].start +
prims[i].count) {
+ totalCount += prims[i + 1].count;
+ i++;
+ }
+
+ pipe-draw_elements(pipe, indexBuf, indexSize,
+ firstPrimMode,
+ firstPrimStart + indexOffset, totalCount);
+}
+ }
+ else
+ {
+for (i = 0; i nr_prims; i++) {
+ setup_edgeflags(ctx, prims[i].mode,
+ prims[i].start + indexOffset, prims[i].count,
+ arrays[VERT_ATTRIB_EDGEFLAG]);
+
+ pipe-draw_elements(pipe, indexBuf, indexSize,
+ prims[i].mode,
+ prims[i].start + indexOffset,
prims[i].count);
+}
}
}
@@ -688,12 +710,32 @@ st_draw_vbo(GLcontext *ctx,
else {
/* non-indexed */
GLuint i;
- for (i = 0; i nr_prims; i++) {
- setup_edgeflags(ctx, prims[i].mode,
- prims[i].start, prims[i].count,
- arrays[VERT_ATTRIB_EDGEFLAG]);
+ if (ctx-Polygon.FrontMode == GL_FILL
+ ctx-Polygon.BackMode == GL_FILL) {
+ /* Coalesce runs of prims into a single draw call */
+ for (i = 0; i nr_prims; i++) {
+GLuint firstPrimMode = prims[i].mode;
+GLuint firstPrimStart = prims[i].start;
+GLuint totalCount = prims[i].count;
+if (firstPrimMode != GL_TRIANGLE_STRIP firstPrimMode
!= GL_TRIANGLE_FAN)
+ while (i + 1 nr_prims prims[i + 1].mode == firstPrimMode
+ prims[i + 1].start == prims[i].start + prims[i].count) {
+ totalCount += prims[i + 1].count;
+ i++;
+ }
+
+ pipe-draw_arrays(pipe, firstPrimMode, firstPrimStart, totalCount);
+ }
+ }
+ else
+ {
+ for (i = 0; i nr_prims; i++) {
+setup_edgeflags(ctx, prims[i].mode,
+prims[i].start, prims[i].count,
+arrays[VERT_ATTRIB_EDGEFLAG]);
- pipe-draw_arrays(pipe, prims[i].mode, prims[i].start,
prims[i].count);
+pipe-draw_arrays(pipe, prims[i].mode, prims[i].start,
prims[i].count);
+ }
}
}
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (pipe-video): g3dvl: Use ureg to build shaders.
On Mon, Nov 9, 2009 at 2:35 PM, Keith Whitwell kei...@vmware.com wrote: On Sat, 2009-11-07 at 16:47 -0800, Younes Manton wrote: Module: Mesa Branch: pipe-video Commit: e57f7b7b107c610fa2d7f149f3441c2b4a9600cb URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=e57f7b7b107c610fa2d7f149f3441c2b4a9600cb Author: Younes Manton youne...@gmail.com Date: Sat Nov 7 19:46:33 2009 -0500 g3dvl: Use ureg to build shaders. Fantastic -- I think g3dvl was the last user of tgsi_build.c. Keith Better late than never, it's much easier to work with than tgsi_build.c that's for sure. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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 za...@vmware.com 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
patches like this one wouldn't be even
Re: [Mesa3d-dev] [PATCH] Make DRI/DRM state tracker interface less context-dependent
On Tue, Oct 27, 2009 at 3:33 PM, José Fonseca jfons...@vmware.com 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
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
Re: [Mesa3d-dev] [RFC] gallium-blitter
On Thu, Oct 15, 2009 at 8:54 PM, Corbin Simpson mostawesomed...@gmail.com wrote: URL: http://cgit.freedesktop.org/~csimpson/mesa/log/?h=gallium-blitter So, with r600g right around the corner, I'd like to do something about this blitter/no blitter thing. Just wondering, how can you get hardware clear/copy on R600 if the 3D engine can't sample and render to a particular format? Are you doomed to a software fallback for these? Hopefully no relatively common format is in that category. This patch series contains one new getparam, PIPE_CAP_BLITTER, and a proposed ABI change to accompany it. surface_copy and surface_fill are proposed to have a way of indicating whether or not they successfully performed the fill/blit. It is up to the state tracker to determine whether or not to rely on these functions. Issues: - Should surface_copy and surface_fill return boolean instead of void? With this patchset, they'll return FALSE if they fail, and always return FALSE if PIPE_CAP_BLITTER isn't set. - Instead, should surface_copy and surface_fill simply be allowed to be NULL if PIPE_CAP_BLITTER is set? State tracker could continue to assume that, if present, surface_copy and surface_fill behave as expected and never fail. I prefer NULL, at least you know right away if you try to call and it isn't available, vs forgetting to check the return value and having to track it down. However I think right there's a mix of both conventions in use right now... - Should clear be included with these two? I don't think any drivers are doing anything with clear except wiring it up to util_clear... Better to let them keep the option for flexibility's sake IMO, especially if it doesn't require much maintenance. If someone ever needs to do something different here it's an easy job. -- 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] [RFC] Proper Gallium video decoding interface
On Mon, Oct 12, 2009 at 11:58 AM, José Fonseca jfons...@vmware.com wrote: Younes, I've finally took a good look to your changes. Again, I don't know enough about video to comment on the details, so comments below focus more on shape than the content. Overall the interfaces look sane to me. The point I'm a bit skeptical about is your choice above of pipe_video_surface over pipe_surface and pipe_texture. I don't see a reason for video frames to be handled differently -- even if the pixel formats that can be used by pipe_context and pipe_video_context are disjoint the resource management side of it can still be shared. Thanks for the comments. Originally I had pipe_texture used in place of pipe_video_surface, but I assumed people who weren't interested in video wouldn't want to deal with textures that weren't really always textures as far as pipe_context was concerned. As it stands, aside from pipe_screen::video_surface_create() the rest of the video interface doesn't really mess with the 3D bits so it's not too much of a burden on anyone and can be ignored easily enough. Originally I noticed that pipe_format doesn't describe any kind of planar formats, which are far more common in video. However it looks like PIPE_LAYOUT_YCBCR only uses 2+3 bits so there's actually a lot of room left there to describe the planar/interleaved/packed, etc layouts that are common in video. It's not too much trouble to change, and it does allow for uploading of pre-decoded frames via pipe_transfer for things like Xv so I'd go with that. Furthermore, we've been considering unifying pipe_textures it with pipe_buffers, making pipe_surface/texture/buffer mere views of a pipe_resource. There are some OpenGL extensions that would become easier to implement if this was the case, and this is also aligned with the DirectX10 does. So adding yet another resource type put us another step back on this direction. Also, why is pipe_mpeg12_macroblock::blocks a void * and not a pipe_buffer *? Won't that data ever be touched by the hardware? Oversight. That struct is mostly 1:1 with XvMC's macroblock definition. The blocks may or may not be touched by the hardware directly so a pipe_user_buffer seems logical here. Finally, u_reduce_video_profile() should be in auxiliary/util. We want to move towards having only interfaces in include/pipe, and move inline helpers to auxiliary/util. It's messy change so there has been inertia in making it happen, but new code should try to stick with this. Will do. -- 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 2/3] gallium: Add PIPE_TRANSFER_MAP_DIRECTLY usage flag.
On Thu, Oct 1, 2009 at 11:29 AM, Michel Dänzer mic...@daenzer.net wrote:
On Thu, 2009-10-01 at 16:16 +0100, José Fonseca wrote:
On Thu, 2009-10-01 at 07:44 -0700, Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
Asks the driver to map the texture storage directly or return NULL if
that's
not possible.
---
src/gallium/include/pipe/p_defines.h | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/src/gallium/include/pipe/p_defines.h
b/src/gallium/include/pipe/p_defines.h
index ad42bef..f8fa1e3 100644
--- a/src/gallium/include/pipe/p_defines.h
+++ b/src/gallium/include/pipe/p_defines.h
@@ -193,7 +193,18 @@ enum pipe_texture_target {
enum pipe_transfer_usage {
PIPE_TRANSFER_READ = (1 0),
PIPE_TRANSFER_WRITE = (1 1),
- PIPE_TRANSFER_READ_WRITE = PIPE_TRANSFER_READ | PIPE_TRANSFER_WRITE
/** Read/modify/write */
+ /** Read/modify/write */
+ PIPE_TRANSFER_READ_WRITE = PIPE_TRANSFER_READ | PIPE_TRANSFER_WRITE,
+ /**
+* The transfer should map the texture storage directly. The driver may
+* return NULL if that isn't possible, and the state tracker needs to
cope
+* with that and use an alternative path without this flag.
+*
+* E.g. the state tracker could have a simpler path which maps
textures and
+* does read/modify/write cycles on them directly, and a more
complicated
+* path which uses minimal read and write transfers.
+*/
+ PIPE_TRANSFER_MAP_DIRECTLY = (1 2)
};
Michel,
To help understand, could you give a concrete example of the simpler
path and complicated path?
See patch 3, and the EXA 'mixed pixmaps' code in xserver = 1.7. The
Xorg state tracker uses PIPE_TRANSFER_MAP_DIRECTLY in the EXA
PrepareAccess hook, as the EXA Prepare/FinishAccess hooks intend a
direct mapping. If the Gallium driver returns NULL, the Xorg state
tracker propagates that to EXA, which in turn uses the
DownloadFrom/UploadToScreen hooks for minimal transfers (with some
damage tracking overhead).
Just out of curiousity, wouldn't PrepareAccess/DFS/UTS/FinishAccess be
doing whats already done by the driver for pipe transfers in this
case? If in PrepareAccess you create a transfer object does it matter
if it's a direct mapping of your texture or a temp texture? Either way
you'll get mapped access to the contents you want and the driver will
be doing the minimal transfer stuff when the pipe transfer is
created/destroyed. I guess if you want to respect the intentions of
PrepareAccess/DFS/UTS/FinishAccess it makes sense to provide such an
interface, but you could make it all transparent to the Xorg state
tracker and get the same end result no?
--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] g3dvl and xvmc indention and location
On Mon, Sep 28, 2009 at 8:42 AM, José Fonseca jfons...@vmware.com wrote: Younes, Large changes like this should be rehearsed in a feature branch, to allow for more review and experimentation while keeping master from getting too broken. I hadn't time to review pipe_video_context yet, but a few quick comments to your changes: - Avoid unsupported C99 features in code that will be build in all architectures (especially, src/gallium/auxiliaries, src/gallium/drivers): use p_compiler.h instead of stdbool.h; declare all variables on top of the scope. I already fixed all issues that were causing build failures on MSVC, but please keep this in mind on future changes. - Please add copyright headers. Sorry about MSVC, I forgot about it. I posted a long reply to the mail where I originally proposed this with details on the changes last week but I guess it was missed. http://www.nabble.com/-RFC--Proper-Gallium-video-decoding-interface-td21543225.html I don't mind #ifdefing/moving/reverting it if people think it needs changes, some feedback on that when time allows would be appreciated. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] g3dvl and xvmc indention and location
On Thu, Sep 17, 2009 at 2:29 PM, Zack Rusin za...@vmware.com wrote: On Thursday 17 September 2009 13:21:45 Younes Manton wrote: On Thu, Sep 17, 2009 at 12:43 PM, Zack Rusin za...@vmware.com wrote: Hey, I'm going to start adding XvMC acceleration to the Gallium's xorg state tracker. I'd like to move src/xvmc to src/gallium/state_trackers/xorg/xvmc and run the standard Mesa3D indent command on both g3dvl and xvmc. I'm by no means saying that the style in them is bad, or that any style is better than any other. What I am saying is that when working within a project that has a well defined indention (docs/devinfo.html) it's anti-social and difficult for everyone involved when parts of the code are using something completely different. It's unrealistic to expect people to keep switching indention that drastically when moving between files within a project. So all I'm asking for is some consistency which I think is going to make everything a lot easier for all of us. z Be my guest. Great, thanks Younes. But aside from that I'm still messing with the pipe_video_context stuff I proposed a while back, which carves up state_trackers/g3dvl pretty good and which might make what you want to do a little easier. At the moment it compiles and runs (no output to window, everything safely stubbed, slowly porting over what used to be the state tracker into aux libs), if you have any interest. Maybe I can put it somewhere so people can comment on the interface and auxiliaries if nothing else. Sounds like a good idea. We're on a schedule for XvMC in the xorg state tracker so we might have to get that just working first. But there's substantial interest in OpenMAX state tracker, plus support for things like vdpau and it would be great if we could do it all properly. z Ok I just pushed this all out and moved xvmc under xorg. state_trackers/g3dvl is now completely useless and I'll delete it soon. pipe_video_context and vl_compositor still need some love for Xv and more love for VDPAU. pipe_video_context needs a function to set a colour conv matrix procamp for hue/saturation/brightness/etc. Right now vl_compositor sets its own matrix internally for csc and doesnt do procamp. There needs to be a way to map pipe_video_surface to be able to upload already decoded frames, either pipe_transfer can become a little more general or there can be separate transfer objects. The winsys/g3dvl dir is probably out of place. There's already an xlib winsys dir so maybe we can have xlib/mesa, xlib/xorg, xlib/xorg/xvmc to match how winsys/drm is set up now. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] is anybody writing dri2 client stuff
On Wed, Sep 23, 2009 at 9:40 AM, Cooper Yuan coopery...@gmail.com wrote: Hi All, The dri1 client files in mesa/src/driclient provide some useful interfaces, I want to know is there a need to provide similar interfaces for dri2 client? It would be nice if this code was in it's own lib since Mesa isn't the only DRI client these days. For XvMC I copied the DRI1 code to src/driclient to avoid linking with half of Mesa. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] g3dvl and xvmc indention and location
On Thu, Sep 17, 2009 at 12:43 PM, Zack Rusin za...@vmware.com wrote: Hey, I'm going to start adding XvMC acceleration to the Gallium's xorg state tracker. I'd like to move src/xvmc to src/gallium/state_trackers/xorg/xvmc and run the standard Mesa3D indent command on both g3dvl and xvmc. I'm by no means saying that the style in them is bad, or that any style is better than any other. What I am saying is that when working within a project that has a well defined indention (docs/devinfo.html) it's anti-social and difficult for everyone involved when parts of the code are using something completely different. It's unrealistic to expect people to keep switching indention that drastically when moving between files within a project. So all I'm asking for is some consistency which I think is going to make everything a lot easier for all of us. z Be my guest. I wasn't aware of the indent stuff when I started, apologies. You might also want to move src/driclient, since it's not used by anyone else. But aside from that I'm still messing with the pipe_video_context stuff I proposed a while back, which carves up state_trackers/g3dvl pretty good and which might make what you want to do a little easier. At the moment it compiles and runs (no output to window, everything safely stubbed, slowly porting over what used to be the state tracker into aux libs), if you have any interest. Maybe I can put it somewhere so people can comment on the interface and auxiliaries if nothing else. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] g3dvl and xvmc indention and location
On Thu, Sep 17, 2009 at 1:26 PM, Corbin Simpson mostawesomed...@gmail.com wrote: On 09/17/2009 10:21 AM, Younes Manton wrote: On Thu, Sep 17, 2009 at 12:43 PM, Zack Rusin za...@vmware.com wrote: Hey, I'm going to start adding XvMC acceleration to the Gallium's xorg state tracker. I'd like to move src/xvmc to src/gallium/state_trackers/xorg/xvmc and run the standard Mesa3D indent command on both g3dvl and xvmc. I'm by no means saying that the style in them is bad, or that any style is better than any other. What I am saying is that when working within a project that has a well defined indention (docs/devinfo.html) it's anti-social and difficult for everyone involved when parts of the code are using something completely different. It's unrealistic to expect people to keep switching indention that drastically when moving between files within a project. So all I'm asking for is some consistency which I think is going to make everything a lot easier for all of us. z Be my guest. I wasn't aware of the indent stuff when I started, apologies. You might also want to move src/driclient, since it's not used by anyone else. But aside from that I'm still messing with the pipe_video_context stuff I proposed a while back, which carves up state_trackers/g3dvl pretty good and which might make what you want to do a little easier. At the moment it compiles and runs (no output to window, everything safely stubbed, slowly porting over what used to be the state tracker into aux libs), if you have any interest. Maybe I can put it somewhere so people can comment on the interface and auxiliaries if nothing else. Are we still looking at pluggable pipelines and PIPE_FORMATs for video frames? Yes. Most of the stuff in the current state tracker is/will be in src/gallium/auxiliary/vl in the form of reusable mpeg1/2 mocomp renderer and scaling/colour convert renderer that use pipe_context. Also made changes to softpipe_screen to allocate video surfaces, and added a softpipe_create-type func to get a pipe_video_surface. Anyone who wants to get a new driver up and running can probably look at that for reference. Also moved over to mesa makefiles like the rest of the libraries. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Fri, Jun 19, 2009 at 11:39 AM, Kaspar Bumkekaspar.bu...@gmail.com wrote: Yeah that was me on your blog. Thanks for answering here. I found your work very interesting and would like to continue where you left of. I do not have alot of experience, but I can make up for it with available time (a year!) and enthusiasm. I am going to start looking into OpenGL first of all and using and developing Mesa3D in general. It will probably be a long time before I will be able to use anything you would be pushing at this point. I'd suggest playing around in OpenGL too. If you can put together a proof of concept demo or something that did one of the decoding stages (e.g. H264 mocomp) it wouldn't be too hard to port to Gallium. IIRC there was somebody in GSoC with XBMC last year who attempted H264. I don't know how far he got but you could pick up where he left off or use his work as a reference. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Google Summer of Code
On Mon, Jun 15, 2009 at 11:59 AM, kasbahkaspar.bu...@gmail.com wrote: Corbin Simpson wrote: we have a state tracker/winsys combo called g3dvl (Gallium3D Video Layer) which can be used for XvMC. VDPAU support would require beefing this layer up to the point of being able to decode h.264, Theora, etc. in a big pipeline, and then writing the glue code to connect with the actual VDPAU interface. Has anything happend with this? Are you doing it for GSoC Denis? I am interested in getting involved in this for my final year undergraduate project. So has anyone begun attempting to beef up g3dvl to decode h.264 ? Nobody is doing this for GSoC as far as I know. (Did you ask the same thing on my blog? Sorry, I meant to respond to you there.) As far as beefing up g3dvl for this I started doing things to at least make it feasible to implement VDPAU and other APIs in a clean way, and I still hack away at it whenever I get a bit of time (hopefully more time now that a few of my other obligations have wrapped up). If you want to do stuff in this area I guess it would inspire me to move a little faster and push what I have so far. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Nouveau git drm git, mesa 7.5 git, xbmc crash and kwin crash
On Sat, May 16, 2009 at 3:44 AM, Eric Valette eric.vale...@free.fr wrote: Younes Manton wrote: However, I have a permanent, always reproducible crash running xbmc Mesa driver is not stable or ready for end users so things like this are normal at the moment. Very constructive answer when I see 7.5 is at RC2... By Mesa driver I meant the Nouveau Mesa driver specifically; I should have been more explicit. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Nouveau git drm git, mesa 7.5 git, xbmc crash and kwin crash
On Fri, May 15, 2009 at 6:10 PM, Eric Valette eric.vale...@free.fr wrote: Hi, I've been running nouveau driver for about 8 month now and did not find any serious problem except selecting OpenGL instead of Xrender as the rendering backend was causing the kde 4 window manager to crash at startup. I saw that mesa 7.5 will have nouveau gallium for the 3D and that decided to have a try. I apparently succeeded: glxinfo | grep render direct rendering: Yes OpenGL renderer string: Gallium 0.2 on NV49 glxinfo | grep OpenGL OpenGL vendor string: Tungsten Graphics, Inc. and nouveau OpenGL renderer string: Gallium 0.2 on NV49 OpenGL version string: 1.5 Mesa 7.5-devel OpenGL extensions: However, I have a permanent, always reproducible crash running xbmc Mesa driver is not stable or ready for end users so things like this are normal at the moment. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium: Make sure we flush before some texture / buffer operations. gallium: Create OGL state tracker wrappers for various CPU access operations.
On Fri, Apr 17, 2009 at 2:22 PM, Thomas Hellstrom thellst...@vmware.com wrote: Ideally this flushing would've been done in the various map operations within the pipe driver as you say, but unfortunately these map operations are screen operations, so the pipe driver doesn't know which context to flush in a multi-threaded environment. Usually drivers wait for fence in a map operation but there is no fence if the draw commands affecting the buffer have not been flushed = Rendering errors. For each buffer we keep track of which command buf it has been referenced in and which context that command buf belongs to. So when we map we check if the buffer has been referenced in a command buf and flush the context that owns it and associate the resulting fences with the buffer and wait on them. If the buffer isn't referenced but is fenced then we just wait on them as usual. Not sure how we keep track if a buffer is referenced in more than one unflushed context though, the current code doesn't seem to handle that, based on my quick look. I'll have to ask Ben. Also the semantics for this will vary for different state-trackers. For OpenGL it's sufficient to flush the current context of the thread doing the map operation, since there can only be one context with unflushed data per thread. Other threads are required to synchronize in the application to avoid clashes. For other state trackers the situation will be different, although I'm no expert in this field we have a couple of them in-house. So to summarize: 1) We need to know what context to flush before mapping. Only the state-tracker knows that. 2) Different state-trackers have different requirements. I'm attaching a program flush_teximage, which will expose the problem. Run with flush_teximage -subimage and you'll probably see the rendering error without this fix. You forgot to attach it. I'd like to give it a try if you still have it around somewhere. -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] gallium: Make sure we flush before some texture / buffer operations. gallium: Create OGL state tracker wrappers for various CPU access operations.
Hi Thomas, I don't understand why this code is necessary in the state tracker. My understanding is you want to flush and synchronize as necessary for read/write before mapping buffers, but isn't that something the pipe driver should already be doing to insure correctness? We do this in nouveau in order to sync CPU access to memory, and then there are the DONTBLOCK and DISCARD flags to fine tune the behaviour. Does this change do more that I've missed or Is there a need to expose this kind of thing to state trackers? -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Winsys
On Sat, Apr 11, 2009 at 9:06 AM, Dee Sharpe demetrioussha...@netscape.net wrote: So, this means I'll have to port the winsys for intel radeon in addition to a generic winsys for the OS if I want to use Intel AMD chipsets??? Each driver/API/OS combo needs a Winsys. Radeon/OpenGL/Your OS, Intel/OpenGL/Your OS, etc. It might be easier to get Softpipe/OpenGL/Your OS running first. You can see what was done for Windows (src/gallium/winsys/gdi/gdi_softpipe_winsys.c) and X (src/gallium/winsys/xlib/xlib_softpipe.c). The Softpipe driver doesn't require a lot from the Winsys, just basically some memory to render to and a way to display it on the screen (via GDI blits, X putimages, etc). Real hardware drivers will require more from their Winsyses, like a way to communicate with their respective kernel modules (and you'll need your own kernel modules if you don't have DRM, I don't think it would be possible to do everything in the Winsys from userspace). -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] texture tiling, sw fallbacks and bufmgrs.
On Sat, Mar 21, 2009 at 9:02 PM, Dave Airlie airl...@linux.ie wrote: I'm just wondering if anyone has already tackled this in any driver, and how this could work best. Does Gallium provide surface accessors for textures like spans? I'm sort of thinking I keep two buffers objects, one sw only and one for hw to use and use the GPU to blit between them when updates are needed. That's roughly what I did for the NV50 Gallium drivers. In general that's what Gallium has for any kind of texture update, you can map/unmap the actual texture or alloc a new temp texture and sync the changes later. We use the latter and instead of a regular blit to sync the changes we do a conversion blit. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): nouveau: bypass_vs_clip_and_viewport
On Mon, Mar 16, 2009 at 6:26 AM, Keith Whitwell kei...@vmware.com wrote: On Sat, 2009-03-14 at 17:21 -0700, Younes Manton wrote: Ugh, sorry about this. I'm not sure how I didn't pick these up - I must have had these drivers disabled in my build without realizing it. Sorry for the screwup. Keith No big deal. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (master): nv50: rework for texture_transfer changes
On Sat, Feb 21, 2009 at 11:32 PM, Ben Skeggs skeg...@gmail.com wrote: On Fri, 2009-02-20 at 10:17 +0100, Michel Dänzer wrote: On Thu, 2009-02-19 at 23:58 -0800, Ben Skeggs wrote: Module: Mesa Branch: master Commit: 63a3a3762c8e1a67666d36b35fdb0ada8e4b7d08 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=63a3a3762c8e1a67666d36b35fdb0ada8e4b7d08 Author: Ben Skeggs bske...@redhat.com Date: Fri Feb 20 09:32:47 2009 +1000 nv50: rework for texture_transfer changes Thanks for this, and sorry for any inconvenience the transfer changes may have caused. No problems at all. I'll probably have a shot a fixing up the other nouveau pipe drivers tomorrow if I get the chance and noone else beats me to it. Don't worry about it if you haven't already started. I started doing it yesterday and I'll probably get back to it when I get home tonight. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] linux-cell compile problems
On Sat, Feb 7, 2009 at 4:11 AM, David Harr djh...@gmail.com wrote: When I run make linux-cell it compiles for quite a while, then I start getting lots of weird errors, like spu_per_fragment_op.c: In function 'spu_fallback_fragment_ops': spu_per_fragment_op.c: error: 'struct pipe_alpha_state' has no member named 'ref' and so on and so forth. There seems to be a disconnect between the members that the SPU and PPU code expect and the data structs in the pipe headers. Has anyone seen this before? I have a hard time believing that there is something weird on my machine such that I am the only one seeing this. On the other hand, it is hard to believe that the repository is sporked. There were some changes recently and it looks like a few things were missed in the cell sources. The fixes are probably trivial (e.g. ref is now ref_value) but I can't compile cell stuff so I can't fix anything there. Try checking out a version from last week or month. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Proper Gallium video decoding interface
On Tue, Jan 20, 2009 at 4:07 AM, Xavier Bestel xavier.bes...@free.fr wrote: Sorry to get in the way, but if at some point in the pipe everything can be done in hardware or shaders, maybe drivers should expose what they can accelerate to let the app handle the rest (some smart frameworks like gstreamer could take shortcuts). OTOH that could require a more complex interface. That was the original plan. It really depends on the API the client is actually using (VAAPI, VDPAU, etc). The VAAPI interface is flexible enough to let drivers expose the entrypoints they support, so the app does everything up to that point and hands off the rest to the driver. Unfortunately VDPAU doesn't do that, the app passes the bitstream off to the driver and the driver gets to do everything else, which is why we need a more complete implementation on the driver side. Even if VAAPI had made it out to mplayer and others I don't know that they would have bothered to support all the possible entry points anyway, since its a lot of work for them to hack up their current decoders. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [RFC] Proper Gallium video decoding interface
I've been taking a look at VDPAU and how to support it on cards with
and without hardware support and I have some thoughts. The VDPAU API
lets the client pass off the entire video bitstream and takes care of
the rest of the decoding pipeline. This is fine if you have hardware
that can handle that, but if not you have to do at least parts of it
in software. Even for MPEG2 most cards don't have hardware to decode
the bitstream so to support VDPAU there would need to be a software
fallback. This is probably why Nvidia isn't currently supporting VDPAU
for pre-NV50 cards.
It seems to me that all of this software fallback business is outside
the scope of a state tracker. I can see this state tracker getting
very large and ugly if we have to deal with fallbacks and if anyone
wants to support fixed function decoding in the future. I think the
much better solution is to extend Gallium to support a very minimal
video decoding interface. The idea would be something along the lines
of:
picture_desc_mpeg12;
picture_desc_h264;
picture_desc_vc1;
...
pipe_video_context
{
set_picture_desc(...)
render_picture(bitstream, ..., surface)
put_picture(src, dst)
...
};
create_video_pipe(profile, width, height, ...)
The driver would then implement the above any way it chooses. Going
along with that would be some generic fallback modules like the
current draw module that can be arranged in a pipeline, to implement
things like software bitstream decode for various formats, software
and shader-based IDCT, shader-based mocomp, and colour space conv,
etc.
An NV50 driver might implement pipe_video_context mostly in hardware,
along with shader based colour space conv. An NV40 driver for MPEG2
might instantiate a software bitstream decoder and implement the rest
in hardware, where as for MPEG4 it might instantiate software
bitstream and IDCT along with shader-based MC and CSC. As far as I
know most fixed func decoding HW is single context, so a driver might
instantiate a software+shader pipeline if another stream is already
playing and using the HW, or it might use it as a basis for managing
states and letting DRM arbitrate access from multiple contexts. A
driver might instantiate a fallback pipeline if it had no hardware
support for a particular type of video, e.g. Theora. Lots of
variations are possible.
Having things in the state tracker makes using dedicated hardware or
supporting VDPAU and others unpleasant and would create a mess going
forward; many of these decisions should be made by driver-side code
anyway, which will simplify the state tracker greatly.
Comments would be appreciated.
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [RFC] Proper Gallium video decoding interface
On Mon, Jan 19, 2009 at 4:08 PM, Corbin Simpson mostawesomed...@gmail.com wrote: Well, it occurs to me that almost all video decoding's done in a pipeline, and we don't want to do any steps in software between hardware steps. It also occurs to me that there's a big disconnect between the actual video format, and the bitstream that encapsulates it, which could be anything from MPEG to Matroska (my favorite) to OGM to AVI, etc. The bitstream in this case is the video bitstream (MPEG2, H264, etc) once it's been demuxed from the container. A full hardware decoder would simply take it as input into a FIFO, parse it, generate control signals for the rest of the pipeline, and eventually split out YUV pixels on the other side, so that's one of the logical entry points. Another would be after the bitstream has been parsed and you have a list of macroblocks that make up a frame, which is the classic XvMC entrypoint. Most of what you said still applies however. - Gallium is only responsible for the formats themselves, and not the containers. Any data required to decompress a raw frame, that's normally stored in the container, should be passed alongside the frame. Right, it's all in the bitstream. Each video format has a spec that defines what a valid bitstream is. - Drivers declare all the formats they can handle. A driver would implement create_video_pipe(profile, width, height, ...) by either initializing its decoding hardware for profile,width,height,etc (e.g. mpeg2main,720,480; h264simple,1280,720) or by initializing software and shader fallbacks if it could not support it in hardware. - Drivers have one hook for taking in video frames, maybe in a context, maybe in a video_context. - Drivers are responsible for all steps of decoding frames, but are free to use methods in Util or Video or whatever auxiliary module we decide to put them in. Things like, say, video_do_idct() or video_do_huffman() might be possible. - Drivers probably shouldn't mix'n'match hardware and software steps, although this is a driver preference, e.g. video_do_foo(); nouveau_do_bar(); video_do_baz(); I would guess that the migration setup would take longer than just doing video_do_bar() instead, but that's just my opinion. I'm sure that not all chipsets are quite like that. I doubt this will be a problem, I can't think of any reason to fall back to software for a stage if the preceding stage was handled in hardware or shaders. There may be such an oddball case, but yeah no point in mixing hardware, software, and shaders if we have to read back from the GPU. - I think that once a frame's decompressed, we can use the normal methods for putting the frame to a buffer, although I'm sure that people are going to reply and tell me why that's not a good idea. :3 So from this perspective, support for new formats needs to be explicitly added per-driver. PIPE_FORMAT_MPEG2, PIPE_FORMAT_THEORA, PIPE_FORMAT_XVID, PIPE_FORMAT_H264, etc. There are also profile variations to consider, but yeah that's the jist of it. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Mesa (gallium-0.2): nouveau: return buffer map to something sane.
On Mon, Jan 12, 2009 at 5:04 AM, Keith Whitwell kei...@vmware.com wrote: On Sun, 2009-01-11 at 23:00 -0800, Ben Skeggs wrote: Module: Mesa Branch: gallium-0.2 Commit: df266471b1f0eae54cf23fd59a741fa3be9b93df URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=df266471b1f0eae54cf23fd59a741fa3be9b93df Author: Ben Skeggs skeg...@gmail.com Date: Mon Jan 12 13:27:13 2009 +1000 nouveau: return buffer map to something sane. Sorry, but no, we're not doing this.. Correctness always takes precedence over speed. Implement this higher up where you know it's safe to do so, and doesn't break other things in the process. Agreed, This is a general facility that makes sense to add at the gallium API level -- there's nothing hardware-specific about this idea, so implementing it within a driver or winsys is putting it at the wrong level. I'd be happy to see a patch that adds something similar at the API level, eg an extra flag to map() like _DISCARD or similar. Keith I don't see how you can implement that functionality (nicely) at a higher level because there's no way to know if the mapping of a buffer will block or not. The current alternative at a higher level than the winsys is to recreate *every* write-only pipe_buffer that we touch in the state tracker and block+retry later on out-of-memory if we're allocating faster than the GPU is consuming. This is what jrfonseca suggested when I brought up the possibility of adding flags and/or offset+len params to map(), and he pointed me to src/gallium/winsys/drm/intel/common/ws_dri_*.c and src/gallium/auxiliary/pipebuffer/*. I've tried that in various ways and it's a lot more code than the above and is overkill in cases where buffers are not actually busy and can be mapped immediately because we're rendering faster than we're mapping. I'd be happy with a DISCARD flag and/or offset+len params to map, to allow the above to be done safely. (But that still means implementing it in each winsys even though its not hardware specific, but it is winsys and pipe_buffer implementation specific -- in this case it relies on the nouveau BO that backs each pipe_buffer. I don't see how a state tracker calling winsys-map() on a pipe_buffer could hit generic code with the current setup.) -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH] Gallium-0.1 Softpipe PIPE_FORMAT_R16_SNORM
I needed this to test some XvMC related stuff.
diff --git a/src/gallium/auxiliary/util/p_tile.c
b/src/gallium/auxiliary/util/p_tile.c
index 1bf0d72..2b6db43 100644
--- a/src/gallium/auxiliary/util/p_tile.c
+++ b/src/gallium/auxiliary/util/p_tile.c
@@ -441,6 +441,46 @@ a8_get_tile_rgba(ubyte *src,
}
}
+/*** PIPE_FORMAT_R16_SNORM ***/
+
+static void
+r16_get_tile_rgba(short *src,
+ unsigned w, unsigned h,
+ float *p,
+ unsigned dst_stride)
+{
+ unsigned i, j;
+
+ for (i = 0; i h; i++) {
+ float *pRow = p;
+ for (j = 0; j w; j++, src++, pRow += 4) {
+ pRow[0] = SHORT_TO_FLOAT(src[0]);
+ pRow[1] =
+ pRow[2] = 0.0;
+ pRow[3] = 1.0;
+ }
+ p += dst_stride;
+ }
+}
+
+
+static void
+r16_put_tile_rgba(short *dst,
+ unsigned w, unsigned h,
+ const float *p,
+ unsigned src_stride)
+{
+ unsigned i, j;
+
+ for (i = 0; i h; i++) {
+ const float *pRow = p;
+ for (j = 0; j w; j++, dst++, pRow += 4) {
+ UNCLAMPED_FLOAT_TO_SHORT(dst[0], pRow[0]);
+ }
+ p += src_stride;
+ }
+}
+
/*** PIPE_FORMAT_R16G16B16A16_SNORM ***/
@@ -742,6 +782,9 @@ pipe_tile_raw_to_rgba(enum pipe_format format,
case PIPE_FORMAT_A8L8_UNORM:
a8_l8_get_tile_rgba((ushort *) src, w, h, dst, dst_stride);
break;
+ case PIPE_FORMAT_R16_SNORM:
+ r16_get_tile_rgba((short *) src, w, h, dst, dst_stride);
+ break;
case PIPE_FORMAT_R16G16B16A16_SNORM:
r16g16b16a16_get_tile_rgba((short *) src, w, h, dst, dst_stride);
break;
@@ -847,6 +890,9 @@ pipe_put_tile_rgba(struct pipe_surface *ps,
case PIPE_FORMAT_A8L8_UNORM:
/*a8_l8_put_tile_rgba((ushort *) packed, w, h, p, src_stride);*/
break;
+ case PIPE_FORMAT_R16_SNORM:
+ /*r16_put_tile_rgba((short *) packed, w, h, p, src_stride);*/
+ break;
case PIPE_FORMAT_R16G16B16A16_SNORM:
r16g16b16a16_put_tile_rgba((short *) packed, w, h, p, src_stride);
break;
diff --git a/src/gallium/auxiliary/util/p_tile.c b/src/gallium/auxiliary/util/p_tile.c
index 1bf0d72..2b6db43 100644
--- a/src/gallium/auxiliary/util/p_tile.c
+++ b/src/gallium/auxiliary/util/p_tile.c
@@ -441,6 +441,46 @@ a8_get_tile_rgba(ubyte *src,
}
}
+/*** PIPE_FORMAT_R16_SNORM ***/
+
+static void
+r16_get_tile_rgba(short *src,
+ unsigned w, unsigned h,
+ float *p,
+ unsigned dst_stride)
+{
+ unsigned i, j;
+
+ for (i = 0; i h; i++) {
+ float *pRow = p;
+ for (j = 0; j w; j++, src++, pRow += 4) {
+ pRow[0] = SHORT_TO_FLOAT(src[0]);
+ pRow[1] =
+ pRow[2] = 0.0;
+ pRow[3] = 1.0;
+ }
+ p += dst_stride;
+ }
+}
+
+
+static void
+r16_put_tile_rgba(short *dst,
+ unsigned w, unsigned h,
+ const float *p,
+ unsigned src_stride)
+{
+ unsigned i, j;
+
+ for (i = 0; i h; i++) {
+ const float *pRow = p;
+ for (j = 0; j w; j++, dst++, pRow += 4) {
+ UNCLAMPED_FLOAT_TO_SHORT(dst[0], pRow[0]);
+ }
+ p += src_stride;
+ }
+}
+
/*** PIPE_FORMAT_R16G16B16A16_SNORM ***/
@@ -742,6 +782,9 @@ pipe_tile_raw_to_rgba(enum pipe_format format,
case PIPE_FORMAT_A8L8_UNORM:
a8_l8_get_tile_rgba((ushort *) src, w, h, dst, dst_stride);
break;
+ case PIPE_FORMAT_R16_SNORM:
+ r16_get_tile_rgba((short *) src, w, h, dst, dst_stride);
+ break;
case PIPE_FORMAT_R16G16B16A16_SNORM:
r16g16b16a16_get_tile_rgba((short *) src, w, h, dst, dst_stride);
break;
@@ -847,6 +890,9 @@ pipe_put_tile_rgba(struct pipe_surface *ps,
case PIPE_FORMAT_A8L8_UNORM:
/*a8_l8_put_tile_rgba((ushort *) packed, w, h, p, src_stride);*/
break;
+ case PIPE_FORMAT_R16_SNORM:
+ /*r16_put_tile_rgba((short *) packed, w, h, p, src_stride);*/
+ break;
case PIPE_FORMAT_R16G16B16A16_SNORM:
r16g16b16a16_put_tile_rgba((short *) packed, w, h, p, src_stride);
break;
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/___
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] Gallium HW winsys
[Just realized that mesa-dev might be slightly more on topic for DRI-specific issues. See below. Thanks.] On Thu, Jul 10, 2008 at 12:22 PM, Younes Manton [EMAIL PROTECTED] wrote: I'm trying to get the HW winsys stuff set up for XvMC and have some questions. Is there any problem with dlopen()ing the DRI driver (in this case nouveau_dri.so) and instead of writing my own winsys? Stephane suggested I look into this, even though the winsys is supposed to be tied to the API. For Softpipe I looked at what Mesa's winsys was doing and implemented the stuff I needed and ignored any GL-specific things, but I realize now I may have been able to load egl_softpipe.so and reused their winsys. Is this acceptable for nouveau if I can live with some possibly minor GL dependencies?. I'm looking at dri_glx.c and glxext.c to see how this might be done. - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] gallium (was Re: radeon r6xx DRM...)
On Wed, Jun 4, 2008 at 8:30 PM, Brian Paul [EMAIL PROTECTED] wrote: Dave Airlie wrote: Stephane wrote: Hi Brian, It seems like people are mostly concerned about gallium stability right now. How stable wioll the interfaces be in the future ? Maybe if you could tell us, that'd help others jump in. The gallium interfaces won't change radically, but we are looking at some changes. I think this would be a good time to speak up. My GSoC project involves writing a state tracker for XvMC, aside from the mesa state tracker I understand this is the only other public state tracker around. I don't have any complaints about the current gallium interface, but maybe someone could elaborate on what they have in mind as far as changes go, even if it's preliminary. In particular, the winsys stuff is kind of complicated and we're hoping to simplify and re-organize it somewhat. Winsys basically includes all the stuff needed to interface a portable gallium driver into the non-portable window system and OS which hosts it. The dividing lines, modularity and terminology(!) can be improved in that area. Jakob Bornecrantz may be commiting some changes soon. One thing I've noticed about about winsys is that from my understanding, the state tracker is supposed to be OS and driver independent, but for XvMC and VAAPI the following situation exists: both are passed the drawable that will get rendered to late (after creation), and that forces me to pass the drawable to the winsys throught the state tracker as winsys-flush_frontbuffer(.., ..., drawable) when it seems that last param is intended for pipe_context-priv. Not sure what the intention behind the priv member is, so maybe this might be a bad idea when I target a HW driver instead of softpipe. Beyond that, there'll probably always be some evolutionary changes to the gallium interfaces. It'll have to evolve just has Mesa has had to evolve since we can't predict future needs. None of this should stop anyone from digging into gallium though. Even when it might make it to master, is it planned to land in master.. I would assume Mesa 8.0 or something. Gallium might ultimately wind up in its own repository as a stand-alone project. Afterall, Gallium drivers could be used by APIs other than OpenGL. As an aside, is there any preferred directory structure people would like to see for state trackers? Right now I'm using Nouveau's gallium but this isn't necessarily nouveau specific and may find a home elsewhere in the future. I'll be putting things in gallium/state_trackers/g3dvl (g3dvl being gallium3d video layer) with the following structure: src/ libXvMC/ tests/ libVAAPI/ tests/ vl/ tests/ winsys/ vl/ is where the state tracker stuff is, although since VAAPI and XvMC are somewhat similar (especially for mpeg2) I'm hoping to use the same state tracker. For that reason things don't look like they do in the mesa state tracker, I don't use XvMC types in the state tracker and don't necessarily map 1:1 with XvMC functions. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
