Re: [Mesa3d-dev] Initial version of GL_MESA_gpu_program3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nicolai Hähnle wrote: > Am Tuesday 13 October 2009 21:20:40 schrieb Ian Romanick: >> Here is the initial version of the assembly extension that was discussed >> at XDC. This is a very early alpha version, and some parts are not yet >> complete. At this point, I am mainly looking for two things in a review: > > Looks good from a very cursory look. > >> - Are there any issues marked "RESOLVED" where you disagree with the >> resolution? I'm especially interested in issues 2, 4, and 19. > > Note: The following replies are based on my understanding of the hardware. > There may still be some missing or unclear information in the docs by AMD. If > this is the case, then it can hopefully be clarified in the course of this > thread. > > Issue 2: > 1) R500 supports unstructured branching in fragment programs but not in > vertex > programs, so I'm happy about leaving it out. Weird. That's backwards from how other SM3 GPUs do it. Usually you get unstructured branching in the AoS vertex shader. > 2) R500 supports address registers as described in vertex programs (including > input/output offsets), but has no address registers at all in fragment > programs. A loop address register can be used as offsets in loops, but the > values loaded into this register must be determined at compile time. I had intended to move the grammar for ARL and ARR out of the generic GPU grammar and into the vertex program-specific grammar. The intention is that LOOP/ENDLOOP is the only way to load an address register in a fragment program. LOOP/ENDLOOP set the .x component and leave the other components undefined. Since the ENDLOOP restores the "previous" value of the address register, the last ENDLOOP restores garbage. My intention was to provide consistent syntactic sugar over the constrained functionality of the loop index. > Issue 4: Agreed. R500 does not support address register math. I looked at the documentation, and I didn't see a way to do it. > Issue 6 (predicate registers): > Is it correct that there is only a PSEQ instruction and not the full > orthogonal set? The grammar includes the full orthogonal set, but the > instruction list seems to be missing something. The full complement is supposed to be there. I created the entry fro PSEQ, got distracted, and never came back to it. > I assume predicate registers can be used to mask writes of ordinary ALU > instructions. Can they also mask TEX instructions? (R500 supports both, and > it's easy to emulate, but see caveat). Yes. Predicates can apply to anything. > I think we can do everything you throw at us on R500. The only difficulty is > that R500 is a bit schizophrenic in that vertex programs are very different > from fragment programs, but we can emulate things. The only stupid weakness > is > that swizzling predicates in fragment programs is essentially impossible (the > only natively supported swizzles are .rgba and the smears ., ., > ., > .). Obviously we can emulate this. How painful would it be to emulate? We could restrict the set of available predicate swizzles. I think this matches D3D, so it shouldn't be a problem for Wine. > Issue 11: > R500 supposedly supports relative addressing of temporary registers in vertex > programs, and also in fragment programs (but only using loop indices). I have > never tested whether it actually works, though. This would be a good feature to have. Would it be possible to hack up a test? Do you know of any limitations? > Issue 13: > Similar to issue 2, R500 fragment programs support unstructured everything > but > vertex programs don't, so not overlapping sounds good to me. > > Issue 15: > I know R500 fragment programs can support a CONT, but I'm not so familiar > with > the R500 vertex programs, and they seem generally less flexible. I didn't see an explicit CONT instruction. If there's no unstructured branch, there probably isn't a way to do it. > Issue 17: > I would *expect* negative addressing offsets to work on R500, but somehow I > haven't been able to get them to work. I'll see if I can look into it again. No hardware that I'm aware of supports true negative offsets in the instructions. This is made to work with program parameters by putting the base of the array at a large enough positive offset to make the largest negative offset be zero. For example, if the program uses my_array[A0.x - 10], the driver has to place my_array at parameter slot 10 or higher. I don't think we can do similar trickery for attributes and results. I think we may have to leave the negative offsets just for program parameters and only allow positive offsets for attributes and results. Note that NV_gpu_program4 only allows positive offsets. It can get away with this because SM4 has general purpose integer instructions and any register can be used for indirect addressing. > Issue 34: > I don't see any support for an address register
Re: [Mesa3d-dev] texformat-rework branch
On Mon, Oct 5, 2009 at 9:14 PM, Brian Paul wrote: > The texformat-rework branch cleans up the texture format code. The > gl_texture_format struct is replaced by a simple gl_format enum (see > formats.h). This leads to assorted clean-ups in core mesa and the > drivers. This is a step toward unifying and cleaning up the texture > image and renderbuffer data structures. > > There may be some regressions in the tdfx and savage drivers. If/when > anyone complains I can help diagnose/fix the regressions. > > I'd like to merge this branch to master by the end of the week. Let > me know if there's any concerns. I've been too busy to merge this to master, but hopefully soon. In the mean time, it'd be great if someone could test this branch with one of the radeon Rxxx drivers. Everything seems OK with the Intel drivers and gallium. -Brian -- 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] Initial version of GL_MESA_gpu_program3
Am Tuesday 13 October 2009 21:20:40 schrieb Ian Romanick: > Here is the initial version of the assembly extension that was discussed > at XDC. This is a very early alpha version, and some parts are not yet > complete. At this point, I am mainly looking for two things in a review: Looks good from a very cursory look. > - Are there any issues marked "RESOLVED" where you disagree with the > resolution? I'm especially interested in issues 2, 4, and 19. Note: The following replies are based on my understanding of the hardware. There may still be some missing or unclear information in the docs by AMD. If this is the case, then it can hopefully be clarified in the course of this thread. Issue 2: 1) R500 supports unstructured branching in fragment programs but not in vertex programs, so I'm happy about leaving it out. 2) R500 supports address registers as described in vertex programs (including input/output offsets), but has no address registers at all in fragment programs. A loop address register can be used as offsets in loops, but the values loaded into this register must be determined at compile time. Issue 4: Agreed. R500 does not support address register math. Issue 6 (predicate registers): Is it correct that there is only a PSEQ instruction and not the full orthogonal set? The grammar includes the full orthogonal set, but the instruction list seems to be missing something. I assume predicate registers can be used to mask writes of ordinary ALU instructions. Can they also mask TEX instructions? (R500 supports both, and it's easy to emulate, but see caveat). I think we can do everything you throw at us on R500. The only difficulty is that R500 is a bit schizophrenic in that vertex programs are very different from fragment programs, but we can emulate things. The only stupid weakness is that swizzling predicates in fragment programs is essentially impossible (the only natively supported swizzles are .rgba and the smears ., ., ., .). Obviously we can emulate this. Issue 11: R500 supposedly supports relative addressing of temporary registers in vertex programs, and also in fragment programs (but only using loop indices). I have never tested whether it actually works, though. Issue 13: Similar to issue 2, R500 fragment programs support unstructured everything but vertex programs don't, so not overlapping sounds good to me. Issue 15: I know R500 fragment programs can support a CONT, but I'm not so familiar with the R500 vertex programs, and they seem generally less flexible. Issue 17: I would *expect* negative addressing offsets to work on R500, but somehow I haven't been able to get them to work. I'll see if I can look into it again. Issue 34: I don't see any support for an address register stack on R500, or anything else to provide for a subroutine stack. Thanks for working on this! cu, Nicolai > > - Are there any issues marked "UNRESOLVED" that you have an opinion on > or data to support a resolution? I'm especially interested in issues 7, > 11, 15, and 34 (resolution may be related to 4). > > - Are there any instructions listed that cannot be trivially supported > on some relevant hardware? Some instructions expand to multiple real > instructions (e.g., NRM). As long as the expansion is trivial and only > adds one or two extra instructions, this is okay. > > - Is there some important SM3 feature that's missing? I plan to > circulate this around the Wine community after the next revision. > > There is some goofy formatting and issue numbering. This is done to > minimize the diffs with GL_NV_gpu_program4. The output of 'diff -d > --side-by-side -W 165 MESA_gpu_program3 NV_gpu_program4' is pretty > readable and useful. > > http://people.freedesktop.org/~idr/MESA_gpu_program3.txt > > --- >--- 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 -- 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 1/2] ac: Fix AIX shared library builds.
tom fogal wrote: > Brian Paul writes: >> tom fogal wrote: >>> Sorry, should have used an intro comment mail. >>> >>> (Assuming all's well,) It would be great if these two could make it >>> onto a branch (e.g. 7.6) in addition to master. >> Both look good to me. You can commit, right? > > In theory, but it hasn't gone through yet: > > https://bugs.freedesktop.org/show_bug.cgi?id=23311 OK, I've committed them to the 7.6 branch. -Brian -- 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 1/2] ac: Fix AIX shared library builds.
Brian Paul writes: > tom fogal wrote: > > Sorry, should have used an intro comment mail. > > > > (Assuming all's well,) It would be great if these two could make it > > onto a branch (e.g. 7.6) in addition to master. > > Both look good to me. You can commit, right? In theory, but it hasn't gone through yet: https://bugs.freedesktop.org/show_bug.cgi?id=23311 -tom -- 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 1/2] ac: Fix AIX shared library builds.
tom fogal wrote: > Sorry, should have used an intro comment mail. > > (Assuming all's well,) It would be great if these two could make it > onto a branch (e.g. 7.6) in addition to master. Both look good to me. You can commit, right? -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24207] Extension for S3TC decompression only
http://bugs.freedesktop.org/show_bug.cgi?id=24207 --- Comment #8 from JasonErickson 2009-10-13 14:31:27 PST --- That solution might work for linux usersbut anyone have a solution for windows users? Believe it or not, but I'm using this project for windows in a VM environment for some autoplay testing. S3TC would be very valuable for that effort. I just need a DLL and a patch for mesa to use the dll correctly. On Fri, Oct 2, 2009 at 11:15 PM, wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=24207 > > > > > > --- Comment #6 from Ian Romanick 2009-10-02 23:15:12 > PST --- > (In reply to comment #5) > >> Anyway, we're wasting time while the solution is pretty simple: we should >> just >> ignore patents (in particular, they don't apply in my country, so I can't >> feel >> sad). > > You and me both. > >> If the powers that be don't want it in mesa git, maybe someone should >> just fork mesa, add the patended bits and let distros pick their choice. > > While we're trying to actually fix this issue with the help of OIN, the plan > that came out of XDC is to take the freetype approach: have configure-time > options to enable certain bits of code. These options would be, by default, > disabled. I believe S3TC should stay in an external library. It works that > way, and is easier for users: just drop the library into your system and be > happy. > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are the assignee for the bug. > > -- > Come build with us! The BlackBerry® 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/devconf > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
Re: [Mesa3d-dev] [Bug 24207] Extension for S3TC decompression only
That solution might work for linux usersbut anyone have a solution for windows users? Believe it or not, but I'm using this project for windows in a VM environment for some autoplay testing. S3TC would be very valuable for that effort. I just need a DLL and a patch for mesa to use the dll correctly. On Fri, Oct 2, 2009 at 11:15 PM, wrote: > http://bugs.freedesktop.org/show_bug.cgi?id=24207 > > > > > > --- Comment #6 from Ian Romanick 2009-10-02 23:15:12 > PST --- > (In reply to comment #5) > >> Anyway, we're wasting time while the solution is pretty simple: we should >> just >> ignore patents (in particular, they don't apply in my country, so I can't >> feel >> sad). > > You and me both. > >> If the powers that be don't want it in mesa git, maybe someone should >> just fork mesa, add the patended bits and let distros pick their choice. > > While we're trying to actually fix this issue with the help of OIN, the plan > that came out of XDC is to take the freetype approach: have configure-time > options to enable certain bits of code. These options would be, by default, > disabled. I believe S3TC should stay in an external library. It works that > way, and is easier for users: just drop the library into your system and be > happy. > > > -- > Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are the assignee for the bug. > > -- > Come build with us! The BlackBerry® 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/devconf > ___ > Mesa3d-dev mailing list > Mesa3d-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev > -- My Website http://www.codelandia.com Jennys Website http://www.dontbflat.com -- 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] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
Corbin Simpson wrote: > On 10/13/2009 08:34 AM, Brian Paul wrote: >> José Fonseca wrote: >>> On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: Module: Mesa Branch: master Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 Author: Corbin Simpson Date: Mon Oct 12 20:47:00 2009 -0700 r300g: Fallback on surfaces we can't render to or from. Still not sure why st keeps handing down things we can't render to. >>> Corbin, >>> >>> This is a problem of the Mesa state tracker and most co-statetrackers >>> that sit on top of it. It's better than it was before but there are >>> still a few places where it uses formats without querying the driver. A >>> typical problem are PIPE_FORMAT_x -> Mesa visual translation. I had to >>> solve this in the WGL state tracker, but it would be nice if we had >>> shared code for that in src/mesa/state_tracker . >> This is just happening with surface_copy() and surface_fill(), right? >> >> I think the assumption was that if the driver can create a surface in >> format X, then it can copy and fill regions in format X by one means or >> another (and not necessarily by 3D rendering). > > Well, yes and no. Byte-for-byte copies are pretty easy with a fallback, > and I could probably get those to be pretty speedy with BO moves and a > custom libdrm hook. > > Shifting formats is iffy though, and at that point we're talking about > turning on the blitter. For surface_copy() the src and dst surfaces will always be of the same format. >> Corbin, it looks like you're using quads/points to do the copy/fill. >> Can't some sort of blit be used instead? > > And here's where we get fun. > > Turning on the blitter is non-trivial in r300/r500. We have to flush, > send a 2D-only command packet with the fill/copy, and then flush again > when we go back to 3D. This is messy and painful. Kernel-side, the > kernel actually has to idle most of the card to do the switch. If we're > doing any serious 3D work, anybody doing glClear() at the beginning of > their frame is incurring a massive penalty. It's important to understand when/where surface_copy() and surface_fill() are used: Currently, surface_fill() is only used for the util_clear() utility/fallback function. Most drivers should do something smarter for clear(), I think. surface_copy() is mainly used to copy mipmap levels from one texture to another, glCopyTex[Sub]Image() and glCopyPixels(). I believe we'll often be flushing the 3D pipe before doing these things anyway. > We could turn on the blitter, but I'd rather see this handled with > PIPE_CAP_BLITTER or something similar, because r600g will be > blitter-less and completely dependent on its 3D engine, and I'd like to > be prepared sooner rather than later. Sure. I totally understand the desire to avoid using the blitter. I'm just trying to clarify those two functions. If surface_copy() is always done with 3D rendering, it has to be able to cope with any src texture format as a possible destination (ex: for mipmap level copying). In the state tracker we could avoid calling surface_copy() when the driver doesn't support rendering to the dest format. We'd probably fall back to map/memcpy/unmap but that's what util_surface_copy() does already. So it's just a matter of who calls it. > Aside: We use points for fills because fglrx uses points for > clears/fills, and we seem to be getting really good speeds that way. > Silly, but effective. -Brian -- 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] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
On 10/13/2009 08:34 AM, Brian Paul wrote: > José Fonseca wrote: >> On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: >>> Module: Mesa >>> Branch: master >>> Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 >>> URL: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 >>> >>> >>> Author: Corbin Simpson >>> Date: Mon Oct 12 20:47:00 2009 -0700 >>> >>> r300g: Fallback on surfaces we can't render to or from. >>> >>> Still not sure why st keeps handing down things we can't render to. >> >> Corbin, >> >> This is a problem of the Mesa state tracker and most co-statetrackers >> that sit on top of it. It's better than it was before but there are >> still a few places where it uses formats without querying the driver. A >> typical problem are PIPE_FORMAT_x -> Mesa visual translation. I had to >> solve this in the WGL state tracker, but it would be nice if we had >> shared code for that in src/mesa/state_tracker . > > This is just happening with surface_copy() and surface_fill(), right? > > I think the assumption was that if the driver can create a surface in > format X, then it can copy and fill regions in format X by one means or > another (and not necessarily by 3D rendering). Well, yes and no. Byte-for-byte copies are pretty easy with a fallback, and I could probably get those to be pretty speedy with BO moves and a custom libdrm hook. Shifting formats is iffy though, and at that point we're talking about turning on the blitter. > Corbin, it looks like you're using quads/points to do the copy/fill. > Can't some sort of blit be used instead? And here's where we get fun. Turning on the blitter is non-trivial in r300/r500. We have to flush, send a 2D-only command packet with the fill/copy, and then flush again when we go back to 3D. This is messy and painful. Kernel-side, the kernel actually has to idle most of the card to do the switch. If we're doing any serious 3D work, anybody doing glClear() at the beginning of their frame is incurring a massive penalty. We could turn on the blitter, but I'd rather see this handled with PIPE_CAP_BLITTER or something similar, because r600g will be blitter-less and completely dependent on its 3D engine, and I'd like to be prepared sooner rather than later. Aside: We use points for fills because fglrx uses points for clears/fills, and we seem to be getting really good speeds that way. Silly, but effective. ~ C. -- 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] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
On 10/13/2009 03:28 AM, José Fonseca wrote: > On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: >> Module: Mesa >> Branch: master >> Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 >> >> Author: Corbin Simpson >> Date: Mon Oct 12 20:47:00 2009 -0700 >> >> r300g: Fallback on surfaces we can't render to or from. >> >> Still not sure why st keeps handing down things we can't render to. > > Corbin, > > This is a problem of the Mesa state tracker and most co-statetrackers > that sit on top of it. It's better than it was before but there are > still a few places where it uses formats without querying the driver. A > typical problem are PIPE_FORMAT_x -> Mesa visual translation. I had to > solve this in the WGL state tracker, but it would be nice if we had > shared code for that in src/mesa/state_tracker . On one hand, it's my opinion that if I say no to is_format_supported for RENDER_TARGETs (or SAMPLERs, for copying), then the state tracker is misbehaving if it proceeds to request surface_fill or surface_copy with those. On the other hand, this fallback is kind of okay with me because it goes right next to the fallbacks for overlapping blits, which aren't okay on the 3D engine. On the *other* other hand, it'd be really nice if we had PIPE_CAP_BLITTER, which encapsulated all of this. ~ C. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] Initial version of GL_MESA_gpu_program3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the initial version of the assembly extension that was discussed at XDC. This is a very early alpha version, and some parts are not yet complete. At this point, I am mainly looking for two things in a review: - - Are there any issues marked "RESOLVED" where you disagree with the resolution? I'm especially interested in issues 2, 4, and 19. - - Are there any issues marked "UNRESOLVED" that you have an opinion on or data to support a resolution? I'm especially interested in issues 7, 11, 15, and 34 (resolution may be related to 4). - - Are there any instructions listed that cannot be trivially supported on some relevant hardware? Some instructions expand to multiple real instructions (e.g., NRM). As long as the expansion is trivial and only adds one or two extra instructions, this is okay. - - Is there some important SM3 feature that's missing? I plan to circulate this around the Wine community after the next revision. There is some goofy formatting and issue numbering. This is done to minimize the diffs with GL_NV_gpu_program4. The output of 'diff -d - --side-by-side -W 165 MESA_gpu_program3 NV_gpu_program4' is pretty readable and useful. http://people.freedesktop.org/~idr/MESA_gpu_program3.txt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrU0wUACgkQX1gOwKyEAw+lxQCgi+hjDeERsB163Ljyv+iyPz7W z98AnRleHrs1R9Hb1wlk6qLk45gFXfVf =fggv -END PGP SIGNATURE- -- 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 1/2] ac: Fix AIX shared library builds.
Sorry, should have used an intro comment mail. (Assuming all's well,) It would be great if these two could make it onto a branch (e.g. 7.6) in addition to master. -tom Tom Fogal writes: > AIX uses ".a" for both static and shared library extensions. > --- > configure.ac |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) -- 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 0/5] egl: core updates
Chia-I Wu wrote: > Hi, > > This patch series introduces two features to EGL core and fixes some > conformance issues. The first feature is support for built-in driver. > The other one is to allow driver to install a customized logger for > _eglLog(). > > The first patch adds built-in driver support. It is adapted from > WINDOWS_STATIC_LINK, with better error reporting and integrate better > with current driver model. It is a matter of changing the Makefile to > build a libEGL.so with the driver built-in. > > The second patch removes core EGL functions from eglGetProcAddress, as > required by the spec. > > The third patch tries to fix an issue that eglGetProcAddress is called > really early (before any EGLDisplay is created). The best shot is to > try to preload a driver, and get proc address from the preloaded driver. > > The fourth patch allows any client api to be bound. This simplifies the > code a bit, and it makes more sense. Config attribute > EGL_RENDERABLE_TYPE is supposed to be used to choose a config that > support certain apis. The apis supported by a display can also be > queried through EGL_CLIENT_APIS. > > The last patch allows the log level and the logger to be changed by a > driver. This is helpful on systems with an alternative logging > facility. Committed. Sorry for the slow follow-up. -Brian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 1/2] ac: Fix AIX shared library builds.
AIX uses ".a" for both static and shared library extensions. --- configure.ac |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 7518976..44fb779 100644 --- a/configure.ac +++ b/configure.ac @@ -230,6 +230,8 @@ else LIB_EXTENSION='dylib' ;; cygwin* ) LIB_EXTENSION='dll' ;; +aix* ) +LIB_EXTENSION='a' ;; * ) LIB_EXTENSION='so' ;; esac -- 1.6.3.3 -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [PATCH 2/2] Fix build when PROGRAM_DIRS is empty.
SUBDIRS just takes PROGRAM_DIRS value. If PROGRAM_DIRS gets set to the empty string (as can happen when building only OSMesa), a 'for' loop will lack anything to iterate over, causing a parse error. This fixes the issue by making sure SUBDIRS is the null string when PROGRAM_DIRS is, and wrapping the for loops in if's, causing them only to execute if there are directories to iterate over. --- progs/Makefile | 26 +++--- 1 files changed, 15 insertions(+), 11 deletions(-) diff --git a/progs/Makefile b/progs/Makefile index c99f4ee..064e5a2 100644 --- a/progs/Makefile +++ b/progs/Makefile @@ -4,7 +4,7 @@ TOP = .. include $(TOP)/configs/current -SUBDIRS = $(PROGRAM_DIRS) +SUBDIRS ="$(PROGRAM_DIRS)" default: message subdirs @@ -15,18 +15,22 @@ message: subdirs: - @for dir in $(SUBDIRS) ; do \ - if [ -d $$dir ] ; then \ - (cd $$dir && $(MAKE)) || exit 1 ; \ - fi \ - done + @if test -n "$(SUBDIRS)" ; then \ + for dir in $(SUBDIRS) ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE)) || exit 1 ; \ + fi \ + done \ + fi # Dummy install target install: clean: - -...@for dir in $(SUBDIRS) tests ; do \ - if [ -d $$dir ] ; then \ - (cd $$dir && $(MAKE) clean) ; \ - fi \ - done + -...@if test -n "$(SUBDIRS)" ; then \ + for dir in $(SUBDIRS) tests ; do \ + if [ -d $$dir ] ; then \ + (cd $$dir && $(MAKE) clean) ; \ + fi \ + done \ + fi -- 1.6.3.3 -- 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] Store clipping distance for user clip planes as part of vertex processing
Looks good to me.
-Brian
Ian Romanick wrote:
> From: Ian Romanick
>
> Once the clipping distance is calculated and stored per vertex, the
> distances can be re-used when clipping is actually performed. This
> doesn't have any immediate benefit, but it paves the way for
> implementing gl_ClipDistance in vertex shaders and result.clip[] in
> vertex programs.
>
> This has not produces any oglconform regressions on my G31 system
> which uses software TNL.
>
> Signed-off-by: Ian Romanick
> ---
> src/mesa/tnl/t_context.h|1 +
> src/mesa/tnl/t_vb_cliptmp.h | 103 --
> src/mesa/tnl/t_vb_program.c | 15 ++
> src/mesa/tnl/t_vb_vertex.c | 31 -
> 4 files changed, 132 insertions(+), 18 deletions(-)
>
> diff --git a/src/mesa/tnl/t_context.h b/src/mesa/tnl/t_context.h
> index 6137c2d..ca4edcf 100644
> --- a/src/mesa/tnl/t_context.h
> +++ b/src/mesa/tnl/t_context.h
> @@ -207,6 +207,7 @@ struct vertex_buffer
> GLvector4f *EyePtr;/* _TNL_BIT_POS */
> GLvector4f *ClipPtr; /* _TNL_BIT_POS */
> GLvector4f *NdcPtr; /* _TNL_BIT_POS */
> + GLfloat *ClipDistancePtr[MAX_CLIP_PLANES]; /* _TNL_BIT_POS */
> GLubyte ClipOrMask; /* _TNL_BIT_POS */
> GLubyte ClipAndMask;/* _TNL_BIT_POS */
> GLubyte *ClipMask; /* _TNL_BIT_POS */
> diff --git a/src/mesa/tnl/t_vb_cliptmp.h b/src/mesa/tnl/t_vb_cliptmp.h
> index 618b8b3..0d2183a 100644
> --- a/src/mesa/tnl/t_vb_cliptmp.h
> +++ b/src/mesa/tnl/t_vb_cliptmp.h
> @@ -80,6 +80,58 @@ do {
> \
> } while (0)
>
>
> +#define POLY_USERCLIP(PLANE) \
> +do { \
> + if (mask & CLIP_USER_BIT) { \
> + GLuint idxPrev = inlist[0]; \
> + GLfloat dpPrev = VB->ClipDistancePtr[PLANE][idxPrev];\
> + GLuint outcount = 0; \
> + GLuint i;
> \
> + \
> + inlist[n] = inlist[0]; /* prevent rotation of vertices */
> \
> + for (i = 1; i <= n; i++) { \
> +GLuint idx = inlist[i];\
> +GLfloat dp = VB->ClipDistancePtr[PLANE][idx]; \
> + \
> +if (!IS_NEGATIVE(dpPrev)) {\
> + outlist[outcount++] = idxPrev; \
> +} \
> + \
> +if (DIFFERENT_SIGNS(dp, dpPrev)) { \
> + if (IS_NEGATIVE(dp)) { \
> + /* Going out of bounds. Avoid division by zero as we\
> + * know dp != dpPrev from DIFFERENT_SIGNS, above.\
> + */ \
> + GLfloat t = dp / (dp - dpPrev); \
> + INTERP_4F( t, coord[newvert], coord[idx], coord[idxPrev]); \
> + interp( ctx, t, newvert, idx, idxPrev, GL_TRUE );\
> + } else {\
> + /* Coming back in. \
> + */ \
> + GLfloat t = dpPrev / (dpPrev - dp); \
> + INTERP_4F( t, coord[newvert], coord[idxPrev], coord[idx]); \
> + interp( ctx, t, newvert, idxPrev, idx, GL_FALSE ); \
> + } \
> +outlist[outcount++] = newvert++; \
> +} \
> + \
> +idxPrev = idx; \
> +dpPrev = dp; \
> + }
> \
> + \
> + if (outcount < 3)
> \
> +return;\
> +
Re: [Mesa3d-dev] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
José Fonseca wrote: > On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: >> Module: Mesa >> Branch: master >> Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 >> URL: >> http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 >> >> Author: Corbin Simpson >> Date: Mon Oct 12 20:47:00 2009 -0700 >> >> r300g: Fallback on surfaces we can't render to or from. >> >> Still not sure why st keeps handing down things we can't render to. > > Corbin, > > This is a problem of the Mesa state tracker and most co-statetrackers > that sit on top of it. It's better than it was before but there are > still a few places where it uses formats without querying the driver. A > typical problem are PIPE_FORMAT_x -> Mesa visual translation. I had to > solve this in the WGL state tracker, but it would be nice if we had > shared code for that in src/mesa/state_tracker . This is just happening with surface_copy() and surface_fill(), right? I think the assumption was that if the driver can create a surface in format X, then it can copy and fill regions in format X by one means or another (and not necessarily by 3D rendering). Corbin, it looks like you're using quads/points to do the copy/fill. Can't some sort of blit be used instead? -Brian -- 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] Mesa (master): r300g: Fallback on surfaces we can't render to or from.
On Tue, 2009-10-13 at 00:12 -0700, Corbin Simpson wrote: > Module: Mesa > Branch: master > Commit: 95a05621eb750c07e5c7a5eb64b8458d202192b3 > URL: > http://cgit.freedesktop.org/mesa/mesa/commit/?id=95a05621eb750c07e5c7a5eb64b8458d202192b3 > > Author: Corbin Simpson > Date: Mon Oct 12 20:47:00 2009 -0700 > > r300g: Fallback on surfaces we can't render to or from. > > Still not sure why st keeps handing down things we can't render to. Corbin, This is a problem of the Mesa state tracker and most co-statetrackers that sit on top of it. It's better than it was before but there are still a few places where it uses formats without querying the driver. A typical problem are PIPE_FORMAT_x -> Mesa visual translation. I had to solve this in the WGL state tracker, but it would be nice if we had shared code for that in src/mesa/state_tracker . Jose -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24425] rv770 hangs when trying to play nexuiz (mesa bisected)
http://bugs.freedesktop.org/show_bug.cgi?id=24425 --- Comment #6 from Marcin Baczyński 2009-10-13 01:37:43 PST --- I get the same dmesg messages on my mobility 2400 (m72/rv610). See bug #24218 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
[Mesa3d-dev] [Bug 24425] rv770 hangs when trying to play nexuiz (mesa bisected)
http://bugs.freedesktop.org/show_bug.cgi?id=24425 --- Comment #5 from Asbjørn Sannes 2009-10-13 01:21:58 PST --- Hm, well nexuiz definitly makes it hang within 20 minutes, but it seems it is not connected to that commit at all now, atleast when it hangs I do not get any off the output I put in there.. only thing is that it seems to happen more often with that commit, but that could be a coincident .. drmRadeonCmdBuffer: -16. Kernel failed to parse or rejected command stream. See dmesg for more info. And in dmesg: [ 330.458381] [drm:radeon_ib_get] *ERROR* radeon: IB(2:0x10121000:15872) [ 330.458384] [drm:radeon_ib_get] *ERROR* radeon: GPU lockup detected, fail to get a IB [ 330.458386] [drm:radeon_cs_ioctl] *ERROR* Failed to get ib ! So since it hangs, sometimes quicker than other times, and the correlation does not seem strong enough, maybe this bug should just be closed? I actually spent a lot of time to make sure that it was that commit that caused the difference before reporting a bug, and now I can't reproduce it. Sorry to waste your time like this.. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
