Re: GEM discussion questions
On Mon, 19 May 2008 12:04:16 -0700 Ian Romanick [EMAIL PROTECTED] wrote: The GLX spec says, basically, that the results of changes to a shared object in context A are guaranteed to be visible to context B when context B binds the object. It leaves a lot of slack for changes to show up earlier. This is part of the reason that app developers want NV_fence-like functionality. I quickly browsed glx spec and failed to spot where this topic appear. And what does B binds mean in this context, i am thinking to this use: A B share obj A map B map A do some drawing A unmap A submit draw cmd which change obj B want to draw at mapped obj Here does B should the old content of obj before A modified it or should it map to the actual object (even if there is a drawing going on) Note that i explicitly didn't include anysynchronization btw A B where i believe this 2 applications should sync together. Cheers, Jerome Glisse - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM vs GEM discussion questions
On Sun, 2008-05-18 at 17:55 +0200, Thomas Hellström wrote: Stephane Marchesin wrote: On 5/16/08, Pekka Paalanen [EMAIL PROTECTED] wrote: On Fri, 16 May 2008 10:05:18 +0200 Jerome Glisse [EMAIL PROTECTED] wrote: My current understanding is that on newer GPU each client got its own memory address space on the GPU. I can manage this space transparently based on hint from userspace, ie i can place page either in ram or vram and i can do migration when necessary. As a result i think i have no obligation that page in VRAM to be adjacent each to the other. Of course mapping such thing in userspace vma become cumberstone. This sounds like a feature that could be used to avoid applying any relocations into commands streams, and completely get rid of kernel validation of a command stream beforehand, allowing direct unobstructed command submission from user space to the card. It would just be like applying relocations in hardware, using page tables instead of rewriting addresses in certain spots in a command stream. Or have I misunderstood something? (Oh, in a later email Glisse writes the same idea.) This sounds interesting, since it would promote command submission that does not go through the kernel at all, which is what Nouveau is already interested in. Somehow I have a recollection that TTM would force the command stream through the kernel, but then again, I'm very new to all this. Yes, that was really my point. If the memory manager we use (whatever it is) does not allow this kind of behaviour, that'll force all cards to use a kernel-validated command submission model, which might not be too fast, and more difficult to implement on such hardware. I'm not in favor of having multiple memory managers, but if the chosen one is both slower and more complex to support in the future, that'll be a loss for everyone. Unless we want to have another memory manager implementation in 2 years from now... Stephane First, TTM does not enforce kernel command submission, but it forces you to tell the kernel about command completion status in order for the kernel to be able to move and delete buffers. I'm not sure how you could avoid that with ANY kernel based memory manager, but I would be interested to know how you expect to solve that problem. As for speed, the TTM-based i915tex driver is still substantially more CPU-efficient (which translates to faster for CPU-bound apps), than _any_ of the intel-modified drivers. Among other things, the texsubimage throughput is about 5x that of the Intel drivers, GEM included. We haven't touched the texsubimage path, having not found it in a profile yet. It'll probably be doing map/write/unmap, which (as noted elsewhere in the thread) is pretty much the worst thing you can do. If you have a relevant application where texsubimage is showing up in the profile, I'd enjoy playing with it. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GEM discussion questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerome Glisse wrote: | On Mon, 19 May 2008 12:04:16 -0700 | Ian Romanick [EMAIL PROTECTED] wrote: | | The GLX spec says, basically, that the results of changes to a shared | object in context A are guaranteed to be visible to context B when | context B binds the object. It leaves a lot of slack for changes to | show up earlier. This is part of the reason that app developers want | NV_fence-like functionality. | | I quickly browsed glx spec and failed to spot where this topic appear. | And what does B binds mean in this context, i am thinking to this use: | A B share obj | A map | B map | A do some drawing Which will fail because A has it mapped. Or do you mean some drawing operation not involving the mapped object? | A unmap | A submit draw cmd which change obj | B want to draw at mapped obj Which will fail because B has it mapped. | Here does B should the old content of obj before A modified it or | should it map to the actual object (even if there is a drawing going on) | Note that i explicitly didn't include anysynchronization btw A B | where i believe this 2 applications should sync together. The result is undefined. I think part of the confusion here, and this is my fault, is the difference between the data contents of the object and the object itself. There is no guarantees about the data contents (i.e., the texels of a texture) of an object. Bind is the synchronization point for things that affect the object itself (i.e., using glTexImage2D to change the size of a texture). We're going to update the GLX spec after OpenGL 3.0 ships, and we're going to make a lot of this more explicit. Right now it's mostly implied by language spread through section 2.3, 2.4, 2.5, and 2.7. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFINGiQX1gOwKyEAw8RAlBEAKCbmp3E3n82EY3OjPwhYQB+lTkaggCbB0Lb G98ypfRM76k2H8KJNCBf5QM= =WIwW -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GEM discussion questions
Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jerome Glisse wrote: | On Mon, 19 May 2008 12:04:16 -0700 | Ian Romanick [EMAIL PROTECTED] wrote: | | The GLX spec says, basically, that the results of changes to a shared | object in context A are guaranteed to be visible to context B when | context B binds the object. It leaves a lot of slack for changes to | show up earlier. This is part of the reason that app developers want | NV_fence-like functionality. | | I quickly browsed glx spec and failed to spot where this topic appear. | And what does B binds mean in this context, i am thinking to this use: | A B share obj | A map | B map | A do some drawing Hmm, According to the GL spec, section 2.9 a GL buffer object cannot be mapped again while in the mapped state Given that, am I wrong in assuming that it's legal for B map to fail with an INVALID_OPERATION error, even if there's no intermediate context B bind? Also, what should be the correct action by the driver when an attempt is made to dereference a mapped buffer object with a GL command? /Thomas - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM vs GEM discussion questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Anholt wrote: | We haven't touched the texsubimage path, having not found it in a | profile yet. It'll probably be doing map/write/unmap, which (as noted | elsewhere in the thread) is pretty much the worst thing you can do. If | you have a relevant application where texsubimage is showing up in the | profile, I'd enjoy playing with it. Anything that uses shadow maps (or any other render-to-texture type effect) without framebuffer objects will hit this path. Since iD only uses stencil volume shadows, it's not surprising that you haven't hit it yet. And I don't think glTexSubImage is the problem, I think glCopyTexSubImage is the problem. There are also some Nvidia demos that use pixel buffer objects to do async. glReadPixels. I suspect that path will have the same potential problems. Unless I've completely missed the point... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFINGt/X1gOwKyEAw8RAg+dAJ9tmaxx2hV+J3JQXgiMVRiO3fqsIwCfYvdY ZMxDXteA/mj67W08cjgCgHc= =SH10 -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15376] X aborts on running glxinfo
http://bugs.freedesktop.org/show_bug.cgi?id=15376 Raúl [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #2 from Raúl [EMAIL PROTECTED] 2008-05-21 15:09:44 PST --- Hello: I see you use intel driver, would you mind retest with latest 2.3.1. I think your problem is solved there. Regards, -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: GEM discussion questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Hellström wrote: | Ian Romanick wrote: | Jerome Glisse wrote: | | On Mon, 19 May 2008 12:04:16 -0700 | | Ian Romanick [EMAIL PROTECTED] wrote: | | | | The GLX spec says, basically, that the results of changes to a shared | | object in context A are guaranteed to be visible to context B when | | context B binds the object. It leaves a lot of slack for changes to | | show up earlier. This is part of the reason that app developers want | | NV_fence-like functionality. | | | | I quickly browsed glx spec and failed to spot where this topic appear. | | And what does B binds mean in this context, i am thinking to this use: | | A B share obj | | A map | | B map | | A do some drawing | | Hmm, | According to the GL spec, section 2.9 a GL buffer object cannot be | mapped again while in the mapped state | Given that, am I wrong in assuming that it's legal for B map to fail | with an INVALID_OPERATION error, even if there's no intermediate context | B bind? My recollection is that it was supposed to be possible, but the language seems to indicate otherwise. It would be interesting to see what other implementations do in this case. | Also, what should be the correct action by the driver when an attempt is | made to | dereference a mapped buffer object with a GL command? Generate INVALID_OPERATION. This is in the GL_ARB_vertex_buffer_object spec: ~INVALID_OPERATION is generated if a buffer object that is currently ~mapped is used as a source of GL render data, or as a destination of ~GL query data. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFINL/2X1gOwKyEAw8RArfBAJ9EJLaYQHkQK9LLwtfeSLSwfDHbEACeLd6r +kqRG76ZO7kG5wlTcOWm9js= =VJ/M -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14221] [i965 64bit] ut2004 run abort on mesa 7.0.3 rc1
http://bugs.freedesktop.org/show_bug.cgi?id=14221 --- Comment #6 from Colin.Joe [EMAIL PROTECTED] 2008-05-21 18:33:37 PST --- this bug can be reproduced on latest mesa 7_0_branch -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14966] [i915 mesa_7.0.3-rc2] segment fault with BASE_LEVEL set to 5 for MipMap
http://bugs.freedesktop.org/show_bug.cgi?id=14966 --- Comment #5 from Colin.Joe [EMAIL PROTECTED] 2008-05-21 20:13:14 PST --- this case can run fine on 915 (with mesa 7_0_branch) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
