[Mesa-dev] [Bug 71591] Second Life shaders fail to compile
https://bugs.freedesktop.org/show_bug.cgi?id=71591 Petri Latvala changed: What|Removed |Added CC||petri.latv...@intel.com -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71591] Second Life shaders fail to compile
https://bugs.freedesktop.org/show_bug.cgi?id=71591 Eero Tamminen changed: What|Removed |Added CC||eero.t.tammi...@intel.com --- Comment #4 from Eero Tamminen --- E.g. Unigine's Heaven benchmark (v4.0) does this also. It's a shame as that would be a nice test case for recently added geometry shader and GL_ARB_sample_shading support in Mesa. 93 of the shaders in Heaven benchmark (= nearly half of them) have: #extension GL_ARB_sample_shading : enable And in none of them it's at the start. There are no other extension declarations. (In reply to comment #3) > This seems a common mistake. I think we should consider applying it in > upstream mesa too, for sake of compatability. All the Heaven shaders have main(). I think they're concatenated together from different parts and in that case it makes sense to declare extensions required by given part of shader, in the beginning of that part. Program needing to keep track of what extensions are require by different shader parts is inconvenient, especially if those concatenated parts can be edited separately from the program (they e.g. come from disk). (In reply to comment #1) > According to the GLSL specification (1.30, page 14), #extension directives > must come before any non-preprocessor tokens. The spec says: "Each extension can define its allowed granularity of scope. If nothing is said, the granularity is a shader (that is, a single compilation unit), and the extension directives must occur before any non-preprocessor tokens." What if extension defines its allowed scope? -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] glext.h and glcorearb.h?
Hey, so I'm not really uptodate on latest Khronos stuff, but the glext.h from the webpage is out of date and I can't seem to svn checkout the xml files as i'm not a member. So does glext.h contain the 4.4 ARB extensions like ARB_multi_bind or do we need to start distributing glcorearb.h? Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glext.h and glcorearb.h?
On Mon, Nov 18, 2013 at 7:58 PM, Dave Airlie wrote: > Hey, > > so I'm not really uptodate on latest Khronos stuff, but the glext.h > from the webpage is out of date and I can't seem to svn checkout the > xml files as i'm not a member. > > So does glext.h contain the 4.4 ARB extensions like ARB_multi_bind or > do we need to start distributing glcorearb.h? > oh I can get glext.h from the svn via the web interface and it appears to be what I need. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71591] Second Life shaders fail to compile
https://bugs.freedesktop.org/show_bug.cgi?id=71591 --- Comment #5 from MirceaKitsune --- Although I'm not a driver developer and have little technical expertise here, I've gotten a better understanding of the issue. I can see why Mesa deems such shaders as invalid, given the statement is not placed correctly and it is bad writing. However, I believe the Mesa developers should consider that many applications have shaders written this way, with developers who might not care to fix them. Failing with an error here will condemn those with the free drivers to be unable to run what those with the proprietary drivers can. Yes, Mesa's approach is technically correct, the writing is bad and shouldn't be supported... but users of many programs with bad shaders have to suffer the consequences, which I don't think is right. My personal suggestion is to not fail with an error, but print a big warning in the console to let people know the shaders are written poorly. I believe this is a fair approach, and a compromise Mesa can make for the sake of compatibility. Please consider it. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71734] New: Commit to "Dynamically allocate the storage for program local parameters." causes KSP to abort on start up.
https://bugs.freedesktop.org/show_bug.cgi?id=71734 Priority: medium Bug ID: 71734 Assignee: mesa-dev@lists.freedesktop.org Summary: Commit to "Dynamically allocate the storage for program local parameters." causes KSP to abort on start up. Severity: normal Classification: Unclassified OS: Linux (All) Reporter: imroy...@gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Mesa core Product: Mesa Created attachment 89400 --> https://bugs.freedesktop.org/attachment.cgi?id=89400&action=edit KSP/Unity3D log with stack traces After a build of Mesa yesterday, Kerbal Space Program 0.22 no longer started up, crashing during the initial loading screen. It simply returns to the command line reporting that it 'Aborted'. I used git bisect to track down which recent versions of Mesa from git would cause KSP to crash. It came down to commit e5885c119de1e508099cce1c9f8ff00fab88. It causes shader local parameters to be allocated dynamically. I don't know how to debug this. I'm using a Radeon HD 6570 card and running Linux kernel 3.11.3 on AMD64. -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71734] Commit to "Dynamically allocate the storage for program local parameters." causes KSP to abort on start up.
https://bugs.freedesktop.org/show_bug.cgi?id=71734 Alex Deucher changed: What|Removed |Added CC||e...@anholt.net -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rules for merging patches to libdrm
On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: > On 11/09/2013 12:11 AM, Dave Airlie wrote: > >>> How does this interact with the rule that kernel interfaces require an > >>> open source userspace? Is "here are the mesa/libdrm patches that use > >>> it" sufficient to get the kernel interface merged? > >> > >> That's my understanding: open source userspace needs to exist, but it > >> doesn't need to be merged upstream yet. > > > > Having an opensource userspace and having it committed to a final repo > > are different things, as Daniel said patches on the mesa-list were > > sufficient, they're was no hurry to merge them considering a kernel > > release with the code wasn't close, esp with a 3 month release window > > if the kernel merge window is close to that anyways. > > > >>> libdrm is easy to change and its releases are cheap. What problem does > >>> committing code that uses an in-progress kernel interface to libdrm > >>> cause? I guess I'm not understanding something. > >> > > > > Releases are cheap, but ABI breaks aren't so you can't just go release > > a libdrm with an ABI for mesa then decide later it was a bad plan. > > > >> Introducing new kernel API usually involves assigning numbers for things > >> - a new ioctl number, new #defines for bitfield members, and so on. > >> > >> Multiple patches can be in flight at the same time. For example, Abdiel > >> and I both defined execbuf2 flags: > >> > >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > >> #define I915_EXEC_OA (1 << 13) (my code) > >> > >> These obviously conflict. One of the two will land, and the second > >> patch author will need to switch to (1 << 14) and resubmit. > >> > >> If we both decide to push to libdrm, we might get the order backwards, > >> or maybe one series won't get pushed at all (in this case, I'm planning > >> to drop my patch). Waiting until one lands in the kernel avoids that > >> problem. Normally, I believe we copy the kernel headers to userspace > >> and fix them up a bit. > >> > >> Dave may have other reasons; this is just the one I thought of. > > > > But mostly this, we've been stung by this exact thing happening > > before, and we made the process to stop it from happening again. > > Then in all honestly, commits to libdrm should be controlled by either a > single person or a small cabal... just like the kernel and the xserver. > We're clearly in an uncomfortable middle area where we have a stringent > set of restrictions but no way to actually enforce them. That doesn't sound like a bad idea at all. It obviously causes more work for whoever will be the gatekeeper(s). It seems to me that libdrm is currently more of a free-for-all type of project, and whoever merges some new feature required for a particular X or Mesa driver cuts a new release so that the version number can be used to track the dependency. I wonder if perhaps tying the libdrm releases more tightly to Linux kernel releases would help. Since there already is a requirement for new kernel APIs to be merged before the libdrm equivalent can be merged, then having both release cycles in lockstep makes some sense. Thierry pgpPYeCMOUxLk.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding wrote: > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: >> On 11/09/2013 12:11 AM, Dave Airlie wrote: >> >>> How does this interact with the rule that kernel interfaces require an >> >>> open source userspace? Is "here are the mesa/libdrm patches that use >> >>> it" sufficient to get the kernel interface merged? >> >> >> >> That's my understanding: open source userspace needs to exist, but it >> >> doesn't need to be merged upstream yet. >> > >> > Having an opensource userspace and having it committed to a final repo >> > are different things, as Daniel said patches on the mesa-list were >> > sufficient, they're was no hurry to merge them considering a kernel >> > release with the code wasn't close, esp with a 3 month release window >> > if the kernel merge window is close to that anyways. >> > >> >>> libdrm is easy to change and its releases are cheap. What problem does >> >>> committing code that uses an in-progress kernel interface to libdrm >> >>> cause? I guess I'm not understanding something. >> >> >> > >> > Releases are cheap, but ABI breaks aren't so you can't just go release >> > a libdrm with an ABI for mesa then decide later it was a bad plan. >> > >> >> Introducing new kernel API usually involves assigning numbers for things >> >> - a new ioctl number, new #defines for bitfield members, and so on. >> >> >> >> Multiple patches can be in flight at the same time. For example, Abdiel >> >> and I both defined execbuf2 flags: >> >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) >> >> #define I915_EXEC_OA (1 << 13) (my code) >> >> >> >> These obviously conflict. One of the two will land, and the second >> >> patch author will need to switch to (1 << 14) and resubmit. >> >> >> >> If we both decide to push to libdrm, we might get the order backwards, >> >> or maybe one series won't get pushed at all (in this case, I'm planning >> >> to drop my patch). Waiting until one lands in the kernel avoids that >> >> problem. Normally, I believe we copy the kernel headers to userspace >> >> and fix them up a bit. >> >> >> >> Dave may have other reasons; this is just the one I thought of. >> > >> > But mostly this, we've been stung by this exact thing happening >> > before, and we made the process to stop it from happening again. >> >> Then in all honestly, commits to libdrm should be controlled by either a >> single person or a small cabal... just like the kernel and the xserver. >> We're clearly in an uncomfortable middle area where we have a stringent >> set of restrictions but no way to actually enforce them. > > That doesn't sound like a bad idea at all. It obviously causes more work > for whoever will be the gatekeeper(s). > > It seems to me that libdrm is currently more of a free-for-all type of > project, and whoever merges some new feature required for a particular X > or Mesa driver cuts a new release so that the version number can be used > to track the dependency. > > I wonder if perhaps tying the libdrm releases more tightly to Linux > kernel releases would help. Since there already is a requirement for new > kernel APIs to be merged before the libdrm equivalent can be merged, > then having both release cycles in lockstep makes some sense. Not sure about strictly tying it to kernel releases would be ideal. Not *everything* in libdrm is about new kernel APIs. It tends to be the place for things needed both by xorg ddx and mesa driver, which I suppose is why it ends up a bit of a free-for-all. Maybe limiting who does releases would be sufficient. Unless there is someone with enough free time and energy to volunteer to be libdrm maintainer. But tbh I don't think it has been too much of a problem in the past. I'm not sure if I actually read somewhere the rule about not updating kernel headers until the interface is locked in (ie. drm-next), but it seemed like common sense to me. Could be enough just to document this a bit more explicitly. BR, -R > Thierry > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: > On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding > wrote: > > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: > >> On 11/09/2013 12:11 AM, Dave Airlie wrote: > >> >>> How does this interact with the rule that kernel interfaces require an > >> >>> open source userspace? Is "here are the mesa/libdrm patches that use > >> >>> it" sufficient to get the kernel interface merged? > >> >> > >> >> That's my understanding: open source userspace needs to exist, but it > >> >> doesn't need to be merged upstream yet. > >> > > >> > Having an opensource userspace and having it committed to a final repo > >> > are different things, as Daniel said patches on the mesa-list were > >> > sufficient, they're was no hurry to merge them considering a kernel > >> > release with the code wasn't close, esp with a 3 month release window > >> > if the kernel merge window is close to that anyways. > >> > > >> >>> libdrm is easy to change and its releases are cheap. What problem does > >> >>> committing code that uses an in-progress kernel interface to libdrm > >> >>> cause? I guess I'm not understanding something. > >> >> > >> > > >> > Releases are cheap, but ABI breaks aren't so you can't just go release > >> > a libdrm with an ABI for mesa then decide later it was a bad plan. > >> > > >> >> Introducing new kernel API usually involves assigning numbers for things > >> >> - a new ioctl number, new #defines for bitfield members, and so on. > >> >> > >> >> Multiple patches can be in flight at the same time. For example, Abdiel > >> >> and I both defined execbuf2 flags: > >> >> > >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > >> >> #define I915_EXEC_OA (1 << 13) (my code) > >> >> > >> >> These obviously conflict. One of the two will land, and the second > >> >> patch author will need to switch to (1 << 14) and resubmit. > >> >> > >> >> If we both decide to push to libdrm, we might get the order backwards, > >> >> or maybe one series won't get pushed at all (in this case, I'm planning > >> >> to drop my patch). Waiting until one lands in the kernel avoids that > >> >> problem. Normally, I believe we copy the kernel headers to userspace > >> >> and fix them up a bit. > >> >> > >> >> Dave may have other reasons; this is just the one I thought of. > >> > > >> > But mostly this, we've been stung by this exact thing happening > >> > before, and we made the process to stop it from happening again. > >> > >> Then in all honestly, commits to libdrm should be controlled by either a > >> single person or a small cabal... just like the kernel and the xserver. > >> We're clearly in an uncomfortable middle area where we have a stringent > >> set of restrictions but no way to actually enforce them. > > > > That doesn't sound like a bad idea at all. It obviously causes more work > > for whoever will be the gatekeeper(s). > > > > It seems to me that libdrm is currently more of a free-for-all type of > > project, and whoever merges some new feature required for a particular X > > or Mesa driver cuts a new release so that the version number can be used > > to track the dependency. > > > > I wonder if perhaps tying the libdrm releases more tightly to Linux > > kernel releases would help. Since there already is a requirement for new > > kernel APIs to be merged before the libdrm equivalent can be merged, > > then having both release cycles in lockstep makes some sense. > > Not sure about strictly tying it to kernel releases would be ideal. > Not *everything* in libdrm is about new kernel APIs. It tends to be > the place for things needed both by xorg ddx and mesa driver, which I > suppose is why it ends up a bit of a free-for-all. I didn't mean that every release would need to be tied to the Linux kernel. But whenever a new Linux kernel release was made, relevant changes from the public headers could be pulled into libdrm and a release be made. I could even imagine a matching of version numbers. libdrm releases could be numbered using the same major and minor as Linux kernels that they support. Micro version numbers could be used in intermediate releases. > Maybe limiting who does releases would be sufficient. Unless there is > someone with enough free time and energy to volunteer to be libdrm > maintainer. > > But tbh I don't think it has been too much of a problem in the past. > I'm not sure if I actually read somewhere the rule about not updating > kernel headers until the interface is locked in (ie. drm-next), but it > seemed like common sense to me. Could be enough just to document this > a bit more explicitly. It's not something I feel very strongly about. People seemed unhappy about the current state of affairs, so I thought I'd dump a few ideas. =) Thierry pgpl3Su1buwS_.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/m
Re: [Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: >> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding >> wrote: >> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: >> >> On 11/09/2013 12:11 AM, Dave Airlie wrote: >> >> >>> How does this interact with the rule that kernel interfaces require an >> >> >>> open source userspace? Is "here are the mesa/libdrm patches that use >> >> >>> it" sufficient to get the kernel interface merged? >> >> >> >> >> >> That's my understanding: open source userspace needs to exist, but it >> >> >> doesn't need to be merged upstream yet. >> >> > >> >> > Having an opensource userspace and having it committed to a final repo >> >> > are different things, as Daniel said patches on the mesa-list were >> >> > sufficient, they're was no hurry to merge them considering a kernel >> >> > release with the code wasn't close, esp with a 3 month release window >> >> > if the kernel merge window is close to that anyways. >> >> > >> >> >>> libdrm is easy to change and its releases are cheap. What problem does >> >> >>> committing code that uses an in-progress kernel interface to libdrm >> >> >>> cause? I guess I'm not understanding something. >> >> >> >> >> > >> >> > Releases are cheap, but ABI breaks aren't so you can't just go release >> >> > a libdrm with an ABI for mesa then decide later it was a bad plan. >> >> > >> >> >> Introducing new kernel API usually involves assigning numbers for >> >> >> things >> >> >> - a new ioctl number, new #defines for bitfield members, and so on. >> >> >> >> >> >> Multiple patches can be in flight at the same time. For example, >> >> >> Abdiel >> >> >> and I both defined execbuf2 flags: >> >> >> >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) >> >> >> #define I915_EXEC_OA (1 << 13) (my code) >> >> >> >> >> >> These obviously conflict. One of the two will land, and the second >> >> >> patch author will need to switch to (1 << 14) and resubmit. >> >> >> >> >> >> If we both decide to push to libdrm, we might get the order backwards, >> >> >> or maybe one series won't get pushed at all (in this case, I'm planning >> >> >> to drop my patch). Waiting until one lands in the kernel avoids that >> >> >> problem. Normally, I believe we copy the kernel headers to userspace >> >> >> and fix them up a bit. >> >> >> >> >> >> Dave may have other reasons; this is just the one I thought of. >> >> > >> >> > But mostly this, we've been stung by this exact thing happening >> >> > before, and we made the process to stop it from happening again. >> >> >> >> Then in all honestly, commits to libdrm should be controlled by either a >> >> single person or a small cabal... just like the kernel and the xserver. >> >> We're clearly in an uncomfortable middle area where we have a stringent >> >> set of restrictions but no way to actually enforce them. >> > >> > That doesn't sound like a bad idea at all. It obviously causes more work >> > for whoever will be the gatekeeper(s). >> > >> > It seems to me that libdrm is currently more of a free-for-all type of >> > project, and whoever merges some new feature required for a particular X >> > or Mesa driver cuts a new release so that the version number can be used >> > to track the dependency. >> > >> > I wonder if perhaps tying the libdrm releases more tightly to Linux >> > kernel releases would help. Since there already is a requirement for new >> > kernel APIs to be merged before the libdrm equivalent can be merged, >> > then having both release cycles in lockstep makes some sense. >> >> Not sure about strictly tying it to kernel releases would be ideal. >> Not *everything* in libdrm is about new kernel APIs. It tends to be >> the place for things needed both by xorg ddx and mesa driver, which I >> suppose is why it ends up a bit of a free-for-all. > > I didn't mean that every release would need to be tied to the Linux > kernel. But whenever a new Linux kernel release was made, relevant > changes from the public headers could be pulled into libdrm and a > release be made. I could even imagine a matching of version numbers. > libdrm releases could be numbered using the same major and minor as > Linux kernels that they support. Micro version numbers could be used > in intermediate releases. maybe an update-kernel-headers.sh script to grab the headers from drm-next and update libdrm wouldn't be a bad idea? >> Maybe limiting who does releases would be sufficient. Unless there is >> someone with enough free time and energy to volunteer to be libdrm >> maintainer. >> >> But tbh I don't think it has been too much of a problem in the past. >> I'm not sure if I actually read somewhere the rule about not updating >> kernel headers until the interface is locked in (ie. drm-next), but it >> seemed like common sense to me. Could be enough just to document this >> a bit more explicitly. > > It's not something I feel very strongly about. People
Re: [Mesa-dev] rules for merging patches to libdrm
op 09-11-13 22:26, Ian Romanick schreef: > On 11/09/2013 12:11 AM, Dave Airlie wrote: How does this interact with the rule that kernel interfaces require an open source userspace? Is "here are the mesa/libdrm patches that use it" sufficient to get the kernel interface merged? >>> That's my understanding: open source userspace needs to exist, but it >>> doesn't need to be merged upstream yet. >> Having an opensource userspace and having it committed to a final repo >> are different things, as Daniel said patches on the mesa-list were >> sufficient, they're was no hurry to merge them considering a kernel >> release with the code wasn't close, esp with a 3 month release window >> if the kernel merge window is close to that anyways. >> libdrm is easy to change and its releases are cheap. What problem does committing code that uses an in-progress kernel interface to libdrm cause? I guess I'm not understanding something. >> Releases are cheap, but ABI breaks aren't so you can't just go release >> a libdrm with an ABI for mesa then decide later it was a bad plan. >> >>> Introducing new kernel API usually involves assigning numbers for things >>> - a new ioctl number, new #defines for bitfield members, and so on. >>> >>> Multiple patches can be in flight at the same time. For example, Abdiel >>> and I both defined execbuf2 flags: >>> >>> #define I915_EXEC_RS (1 << 13) (Abdiel's code) >>> #define I915_EXEC_OA (1 << 13) (my code) >>> >>> These obviously conflict. One of the two will land, and the second >>> patch author will need to switch to (1 << 14) and resubmit. >>> >>> If we both decide to push to libdrm, we might get the order backwards, >>> or maybe one series won't get pushed at all (in this case, I'm planning >>> to drop my patch). Waiting until one lands in the kernel avoids that >>> problem. Normally, I believe we copy the kernel headers to userspace >>> and fix them up a bit. >>> >>> Dave may have other reasons; this is just the one I thought of. >> But mostly this, we've been stung by this exact thing happening >> before, and we made the process to stop it from happening again. > Then in all honestly, commits to libdrm should be controlled by either a > single person or a small cabal... just like the kernel and the xserver. > We're clearly in an uncomfortable middle area where we have a stringent > set of restrictions but no way to actually enforce them. Most of libdrm is hardware specific, so by necessity it is developed like that. I don't think robclark will touch libdrm/intel for example. I do not think explicit control is needed, just be more careful and don't cause unnecessary headaches by committing code to libdrm before it's in a upstream kernel. Preferably wait until it appears in torvalds/linux.git, but it seems airlied has a lower standard. :) Sometimes software bugs might warrant a release too, so this middle area is needed. ~Maarten ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 05:30:34PM +0100, Maarten Lankhorst wrote: > op 09-11-13 22:26, Ian Romanick schreef: > > On 11/09/2013 12:11 AM, Dave Airlie wrote: > How does this interact with the rule that kernel interfaces require an > open source userspace? Is "here are the mesa/libdrm patches that use > it" sufficient to get the kernel interface merged? > >>> That's my understanding: open source userspace needs to exist, but it > >>> doesn't need to be merged upstream yet. > >> Having an opensource userspace and having it committed to a final repo > >> are different things, as Daniel said patches on the mesa-list were > >> sufficient, they're was no hurry to merge them considering a kernel > >> release with the code wasn't close, esp with a 3 month release window > >> if the kernel merge window is close to that anyways. > >> > libdrm is easy to change and its releases are cheap. What problem does > committing code that uses an in-progress kernel interface to libdrm > cause? I guess I'm not understanding something. > >> Releases are cheap, but ABI breaks aren't so you can't just go release > >> a libdrm with an ABI for mesa then decide later it was a bad plan. > >> > >>> Introducing new kernel API usually involves assigning numbers for things > >>> - a new ioctl number, new #defines for bitfield members, and so on. > >>> > >>> Multiple patches can be in flight at the same time. For example, Abdiel > >>> and I both defined execbuf2 flags: > >>> > >>> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > >>> #define I915_EXEC_OA (1 << 13) (my code) > >>> > >>> These obviously conflict. One of the two will land, and the second > >>> patch author will need to switch to (1 << 14) and resubmit. > >>> > >>> If we both decide to push to libdrm, we might get the order backwards, > >>> or maybe one series won't get pushed at all (in this case, I'm planning > >>> to drop my patch). Waiting until one lands in the kernel avoids that > >>> problem. Normally, I believe we copy the kernel headers to userspace > >>> and fix them up a bit. > >>> > >>> Dave may have other reasons; this is just the one I thought of. > >> But mostly this, we've been stung by this exact thing happening > >> before, and we made the process to stop it from happening again. > > Then in all honestly, commits to libdrm should be controlled by either a > > single person or a small cabal... just like the kernel and the xserver. > > We're clearly in an uncomfortable middle area where we have a stringent > > set of restrictions but no way to actually enforce them. > > Most of libdrm is hardware specific, so by necessity it is developed like > that. Most of the Linux kernel is hardware specific, yet it is developed differently. > I don't think robclark will touch libdrm/intel for example. Certainly a subtree-oriented development model could work well for libdrm. What I mean is that not a single person (or even a set of people) would need to pick patches from a mailing list, but driver maintainers could have separate trees which can be merged into the upstream tree. That could potentially lower the workload on the libdrm maintainer(s). > I do not think explicit control is needed, just be more careful and don't > cause > unnecessary headaches by committing code to libdrm before it's in a upstream > kernel. > Preferably wait until it appears in torvalds/linux.git, but it seems airlied > has a > lower standard. :) > > Sometimes software bugs might warrant a release too, so this middle area is > needed. Having a different development model doesn't exclude the possibility for bugfix releases. Neither does explicit control of what patches are merged. Thierry pgp1nlU9t_Qwp.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote: > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding > wrote: > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: > >> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding > >> wrote: > >> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: > >> >> On 11/09/2013 12:11 AM, Dave Airlie wrote: > >> >> >>> How does this interact with the rule that kernel interfaces require > >> >> >>> an > >> >> >>> open source userspace? Is "here are the mesa/libdrm patches that use > >> >> >>> it" sufficient to get the kernel interface merged? > >> >> >> > >> >> >> That's my understanding: open source userspace needs to exist, but it > >> >> >> doesn't need to be merged upstream yet. > >> >> > > >> >> > Having an opensource userspace and having it committed to a final repo > >> >> > are different things, as Daniel said patches on the mesa-list were > >> >> > sufficient, they're was no hurry to merge them considering a kernel > >> >> > release with the code wasn't close, esp with a 3 month release window > >> >> > if the kernel merge window is close to that anyways. > >> >> > > >> >> >>> libdrm is easy to change and its releases are cheap. What problem > >> >> >>> does > >> >> >>> committing code that uses an in-progress kernel interface to libdrm > >> >> >>> cause? I guess I'm not understanding something. > >> >> >> > >> >> > > >> >> > Releases are cheap, but ABI breaks aren't so you can't just go release > >> >> > a libdrm with an ABI for mesa then decide later it was a bad plan. > >> >> > > >> >> >> Introducing new kernel API usually involves assigning numbers for > >> >> >> things > >> >> >> - a new ioctl number, new #defines for bitfield members, and so on. > >> >> >> > >> >> >> Multiple patches can be in flight at the same time. For example, > >> >> >> Abdiel > >> >> >> and I both defined execbuf2 flags: > >> >> >> > >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > >> >> >> #define I915_EXEC_OA (1 << 13) (my code) > >> >> >> > >> >> >> These obviously conflict. One of the two will land, and the second > >> >> >> patch author will need to switch to (1 << 14) and resubmit. > >> >> >> > >> >> >> If we both decide to push to libdrm, we might get the order > >> >> >> backwards, > >> >> >> or maybe one series won't get pushed at all (in this case, I'm > >> >> >> planning > >> >> >> to drop my patch). Waiting until one lands in the kernel avoids that > >> >> >> problem. Normally, I believe we copy the kernel headers to userspace > >> >> >> and fix them up a bit. > >> >> >> > >> >> >> Dave may have other reasons; this is just the one I thought of. > >> >> > > >> >> > But mostly this, we've been stung by this exact thing happening > >> >> > before, and we made the process to stop it from happening again. > >> >> > >> >> Then in all honestly, commits to libdrm should be controlled by either a > >> >> single person or a small cabal... just like the kernel and the xserver. > >> >> We're clearly in an uncomfortable middle area where we have a stringent > >> >> set of restrictions but no way to actually enforce them. > >> > > >> > That doesn't sound like a bad idea at all. It obviously causes more work > >> > for whoever will be the gatekeeper(s). > >> > > >> > It seems to me that libdrm is currently more of a free-for-all type of > >> > project, and whoever merges some new feature required for a particular X > >> > or Mesa driver cuts a new release so that the version number can be used > >> > to track the dependency. > >> > > >> > I wonder if perhaps tying the libdrm releases more tightly to Linux > >> > kernel releases would help. Since there already is a requirement for new > >> > kernel APIs to be merged before the libdrm equivalent can be merged, > >> > then having both release cycles in lockstep makes some sense. > >> > >> Not sure about strictly tying it to kernel releases would be ideal. > >> Not *everything* in libdrm is about new kernel APIs. It tends to be > >> the place for things needed both by xorg ddx and mesa driver, which I > >> suppose is why it ends up a bit of a free-for-all. > > > > I didn't mean that every release would need to be tied to the Linux > > kernel. But whenever a new Linux kernel release was made, relevant > > changes from the public headers could be pulled into libdrm and a > > release be made. I could even imagine a matching of version numbers. > > libdrm releases could be numbered using the same major and minor as > > Linux kernels that they support. Micro version numbers could be used > > in intermediate releases. > > maybe an update-kernel-headers.sh script to grab the headers from > drm-next and update libdrm wouldn't be a bad idea? Perhaps. But I think it could even be a manual step. It's not something that one person should be doing alone, but rather something that driver maintainers should be doing, since they know best what will be needed in a new version of libdrm. Like I mentioned
[Mesa-dev] [PATCH] mesa: Fix setup of LocalParams array.
i965 passed piglit, but swrast and gallium both segfaulted without this. i965 happened to work because it never ran _mesa_load_state_parameters() on the new program before the test called glProgramLocalParameter(), which was allocating a LocalParams array for the fallback path. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71734 --- src/mesa/program/arbprogparse.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/mesa/program/arbprogparse.c b/src/mesa/program/arbprogparse.c index 5b96650..5d92176 100644 --- a/src/mesa/program/arbprogparse.c +++ b/src/mesa/program/arbprogparse.c @@ -127,6 +127,7 @@ _mesa_parse_arb_fragment_program(struct gl_context* ctx, GLenum target, if (program->Base.Parameters) _mesa_free_parameter_list(program->Base.Parameters); program->Base.Parameters= prog.Parameters; + program->Base.LocalParams = prog.LocalParams; /* Append fog instructions now if the program has "OPTION ARB_fog_exp" * or similar. We used to leave this up to drivers, but it appears -- 1.8.4.rc3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 71734] Commit to "Dynamically allocate the storage for program local parameters." causes KSP to abort on start up.
https://bugs.freedesktop.org/show_bug.cgi?id=71734 Eric Anholt changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mesa-dev@lists.freedesktop. |e...@anholt.net |org | --- Comment #1 from Eric Anholt --- http://lists.freedesktop.org/archives/mesa-dev/2013-November/048589.html -- You are receiving this mail because: You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 27/27] i965: Enable the AMD_performance_monitor extension on Gen5+.
Kenneth Graunke writes: > XXX: Gen6+ needs to be predicated on register writes. > > our register write checking function doesn't work on Gen6. Even if you can just enable it on gen7, this series is: Reviewed-by: Eric Anholt pgpu618mL0Xbn.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] rules for merging patches to libdrm
On Mon, Nov 18, 2013 at 05:41:50PM +0100, Thierry Reding wrote: > On Mon, Nov 18, 2013 at 11:21:36AM -0500, Rob Clark wrote: > > On Mon, Nov 18, 2013 at 10:23 AM, Thierry Reding > > wrote: > > > On Mon, Nov 18, 2013 at 10:17:47AM -0500, Rob Clark wrote: > > >> On Mon, Nov 18, 2013 at 8:29 AM, Thierry Reding > > >> wrote: > > >> > On Sat, Nov 09, 2013 at 01:26:24PM -0800, Ian Romanick wrote: > > >> >> On 11/09/2013 12:11 AM, Dave Airlie wrote: > > >> >> >>> How does this interact with the rule that kernel interfaces > > >> >> >>> require an > > >> >> >>> open source userspace? Is "here are the mesa/libdrm patches that > > >> >> >>> use > > >> >> >>> it" sufficient to get the kernel interface merged? > > >> >> >> > > >> >> >> That's my understanding: open source userspace needs to exist, but > > >> >> >> it > > >> >> >> doesn't need to be merged upstream yet. > > >> >> > > > >> >> > Having an opensource userspace and having it committed to a final > > >> >> > repo > > >> >> > are different things, as Daniel said patches on the mesa-list were > > >> >> > sufficient, they're was no hurry to merge them considering a kernel > > >> >> > release with the code wasn't close, esp with a 3 month release > > >> >> > window > > >> >> > if the kernel merge window is close to that anyways. > > >> >> > > > >> >> >>> libdrm is easy to change and its releases are cheap. What problem > > >> >> >>> does > > >> >> >>> committing code that uses an in-progress kernel interface to > > >> >> >>> libdrm > > >> >> >>> cause? I guess I'm not understanding something. > > >> >> >> > > >> >> > > > >> >> > Releases are cheap, but ABI breaks aren't so you can't just go > > >> >> > release > > >> >> > a libdrm with an ABI for mesa then decide later it was a bad plan. > > >> >> > > > >> >> >> Introducing new kernel API usually involves assigning numbers for > > >> >> >> things > > >> >> >> - a new ioctl number, new #defines for bitfield members, and so on. > > >> >> >> > > >> >> >> Multiple patches can be in flight at the same time. For example, > > >> >> >> Abdiel > > >> >> >> and I both defined execbuf2 flags: > > >> >> >> > > >> >> >> #define I915_EXEC_RS (1 << 13) (Abdiel's code) > > >> >> >> #define I915_EXEC_OA (1 << 13) (my code) > > >> >> >> > > >> >> >> These obviously conflict. One of the two will land, and the second > > >> >> >> patch author will need to switch to (1 << 14) and resubmit. > > >> >> >> > > >> >> >> If we both decide to push to libdrm, we might get the order > > >> >> >> backwards, > > >> >> >> or maybe one series won't get pushed at all (in this case, I'm > > >> >> >> planning > > >> >> >> to drop my patch). Waiting until one lands in the kernel avoids > > >> >> >> that > > >> >> >> problem. Normally, I believe we copy the kernel headers to > > >> >> >> userspace > > >> >> >> and fix them up a bit. > > >> >> >> > > >> >> >> Dave may have other reasons; this is just the one I thought of. > > >> >> > > > >> >> > But mostly this, we've been stung by this exact thing happening > > >> >> > before, and we made the process to stop it from happening again. > > >> >> > > >> >> Then in all honestly, commits to libdrm should be controlled by > > >> >> either a > > >> >> single person or a small cabal... just like the kernel and the > > >> >> xserver. > > >> >> We're clearly in an uncomfortable middle area where we have a > > >> >> stringent > > >> >> set of restrictions but no way to actually enforce them. > > >> > > > >> > That doesn't sound like a bad idea at all. It obviously causes more > > >> > work > > >> > for whoever will be the gatekeeper(s). > > >> > > > >> > It seems to me that libdrm is currently more of a free-for-all type of > > >> > project, and whoever merges some new feature required for a particular > > >> > X > > >> > or Mesa driver cuts a new release so that the version number can be > > >> > used > > >> > to track the dependency. > > >> > > > >> > I wonder if perhaps tying the libdrm releases more tightly to Linux > > >> > kernel releases would help. Since there already is a requirement for > > >> > new > > >> > kernel APIs to be merged before the libdrm equivalent can be merged, > > >> > then having both release cycles in lockstep makes some sense. > > >> > > >> Not sure about strictly tying it to kernel releases would be ideal. > > >> Not *everything* in libdrm is about new kernel APIs. It tends to be > > >> the place for things needed both by xorg ddx and mesa driver, which I > > >> suppose is why it ends up a bit of a free-for-all. > > > > > > I didn't mean that every release would need to be tied to the Linux > > > kernel. But whenever a new Linux kernel release was made, relevant > > > changes from the public headers could be pulled into libdrm and a > > > release be made. I could even imagine a matching of version numbers. > > > libdrm releases could be numbered using the same major and minor as > > > Linux kernels that they support. Micro version numbers could
[Mesa-dev] i965 uniform upload question
Hello all, Yet another questions related to i965. I was taking a gander through the code base hunting down where and how uniforms are uploaded to the GPU; what I do see is that pointers are set directly to the a backing store that holds the uniform values: brw_vec4_prog_data::param array of pointers point to gl_uniform_storage::storage and brw_wm_prog_data::param array of pointers point to gl_uniform_storage::storage. to where they point is modified by _mesa_uniform() and _mesa_uniform_matrix(). I also see that pull_param field seems to be the same-ish as param, for example vec4_visitor::move_uniform_access_to_pull_constants() essentially copies from param to pull_param. and now the questions: 1) what is meant by push and pull constants? 2) why are there both param and pull_param? Is it essentially param is for Gen4 and 5 to o uniform stuff and pull_param for Gen6 or higher? Is it so that pull_param values are sent to the GPU through a buffer object surface? 3) for Gen6 and 7, are the uniform values first dumped into brw_state_state::const_bo which is then viewed as a surface? Is there any means to only "upload" those uniforms that have changed? 4) going further, is there a good reason why the uniforms of the default uniform block not just mapped to a UBO anyways? it seems like this would cut down on code quasi-duplication. Further along, is there a Mesa interface to setup call backs so that when uniform gets modified,? Such a value change callback could be adding an entry in a list of a buffer object update (with the buffer object also mirrored as plain user space data). With that list one could issue a smaller set of buffer object updates and that buffer object holds the values for the default uniform block. Just an idea.. another question on the subject of uniforms is the driver_storage interface thing in Mesa.. it appears that i965 does not use it, is that correct? What does that interface provide that the direct interface of poking into the array does not? I do not see anywhere (yet) in the other drivers that reference it either? does anything use it? Or do I have it utterly wrong? Cheers, -Kevin ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glext.h and glcorearb.h?
On Monday 18 November 2013, Dave Airlie wrote: > On Mon, Nov 18, 2013 at 7:58 PM, Dave Airlie wrote: > > Hey, > > > > so I'm not really uptodate on latest Khronos stuff, but the glext.h > > from the webpage is out of date and I can't seem to svn checkout the > > xml files as i'm not a member. > > > > So does glext.h contain the 4.4 ARB extensions like ARB_multi_bind or > > do we need to start distributing glcorearb.h? > > > > oh I can get glext.h from the svn via the web interface and it appears > to be what I need. I already have an implementation of ARB_multi_bind, but I haven't written any piglit tests for it yet: http://cgit.freedesktop.org/~fredrik/mesa/log/?h=arb-multi-bind Fredrik ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] sampler arrays indexed with non-constant expressions
On 17 November 2013 00:24, Victor Luchitz wrote:
> Hello,
>
> in my opinion GLSL compiler in mesa is too restrictive when it comes to
> sampler arrays. The following code can not be compiled due to the "sampler
> arrays indexed with non-constant expressions is forbidden in GLSL 1.30 and
> later":
>
> #define MAX_SHADOWS 2
>
> varying vec4 v_ShadowProjVector[MAX_SHADOWS];
>
> uniform sampler2DShadow u_ShadowmapTexture[MAX_SHADOWS];
> # define qfShadow2D(t,v) float(shadow2D(t,v))
>
> uniform float u_ShadowAlpha;
> uniform float u_ShadowProjDistance[MAX_SHADOWS];
> uniform vec4 u_ShadowmapTextureParams[MAX_SHADOWS];
>
> void main(void)
> {
> float finalcolor = 1.0;
>
> for (int i = 0; i < MAX_SHADOWS; i++)
> {
> vec3 shadowmaptc = vec3(v_ShadowProjVector[i].xyz /
> v_ShadowProjVector[i].w);
>
> // this keeps shadows from appearing on surfaces behind frustum's
> nearplane
> float d = step(v_ShadowProjVector[i].w, 0.0);
>
> //shadowmaptc = (shadowmaptc + vec3 (1.0)) * vec3 (0.5);
> shadowmaptc.xy = shadowmaptc.xy * u_ShadowmapTextureParams[i].xy;
> // .x - texture width
> shadowmaptc.z = clamp(shadowmaptc.z, 0.0, 1.0);
> shadowmaptc.xy = vec2(clamp(shadowmaptc.x, 0.0,
> u_ShadowmapTextureParams[i].x), clamp(shadowmaptc.y, 0.0,
> u_ShadowmapTextureParams[i].y));
>
> vec2 ShadowMap_TextureScale = u_ShadowmapTextureParams[i].zw;
>
> float f;
>
> f = qfShadow2D(u_ShadowmapTexture[i], vec3(shadowmaptc.xy *
> ShadowMap_TextureScale, shadowmaptc.z));
>
> finalcolor *= clamp(max(max(f, d), u_ShadowAlpha), 0.0, 1.0);
> }
>
> gl_FragColor = vec4(vec3(finalcolor),1.0);
> }
>
>
> Lines 159-136 of src/glsl/ast_array_index.cpp say:
>
> * This restriction was added in GLSL 1.30. Shaders using earlier
> version
> * of the language should not be rejected by the compiler front-end for
> * using this construct. This allows useful things such as using a loop
> * counter as the index to an array of samplers. If the loop in
> unrolled,
> * the code should compile correctly. Instead, emit a warning.
>
> If compiler actually attempted to unroll the loop above, it would notice
> that the does compile correctly. Instead it just emits and error and in my
> opinion, contradicts the comment above but not allowing the "useful thing"
> in question.
>
> Can the compiler be changed to _first_ attempt to unroll the loop and then
> check for sampler array indices being constants?
>
Thanks for the feedback, Victor. We are always interested in hearing
suggestions about how to improve Mesa.
Unfortunately, in this case, your suggestion would make Mesa non-conformant
with the GLSL specs because it would allow shaders that are prohibited by
the spec. Generally we try to avoid this sort of non-spec-conformance
because it leads to portability problems for developers like you (e.g. your
shader works with Mesa, but it fails with other GL implementations). A
further problem is that Mesa has heuristics to decide whether to unroll
loops; if we followed your suggestion, then your shader might work today,
but fail tomorrow if you make a small change to the shader that makes Mesa
decide not to unroll the loop (or we make a change to the heuristics in a
future release of Mesa).
Note that once we finish implementing ARB_gpu_shader5 (which we hope to
finish soon), you will be able to use that--ARB_gpu_shader5 lifts the
restriction that sampler array indices must be constant.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/15] i965: Add a new representation for Broadwell shader instructions.
Kenneth Graunke writes:
> Broadwell significantly changes the EU instruction encoding. Many of
> the fields got moved to different bit positions; some even got split
> in two.
>
> With so many changes, it was infeasible to continue using struct
> brw_instruction. We needed a new representation.
>
> This new approach is a bit different: rather than a struct, I created a
> class that has four DWords, and helper functions that read/write various
> bits. This has several advantages:
>
> 1. We can create several different names for the same bits. For
>example, conditional modifiers, SFID for SEND instructions, and the
>MATH instruction's function opcode are all stored in bits 27:24.
>
>In each situation, we can use the appropriate setter function:
>set_sfid(), set_math_function(), or set_cond_modifier(). This
>is much easier to follow.
>
> 2. Since the fields are expressed using the original 128-bit numbers,
>the code to create the getter/setter functions follows the table in
>the documentation very closely.
>
> To aid in debugging, I've enabled -fkeep-inline-functions when building
> gen8_instruction.cpp. Otherwise, these functions cannot be called by
> gdb, making it insanely difficult to print out anything.
I dislike C++ creep. I think the old structs worked OK, and there are
some minor downsides to access-everything-through-methods, like being
unable to just print the instruction in gdb and see fields all at once,
and having to do the build system hack to inline but also keep the
inlines. But I'm feeling more and more alone on the team.
> diff --git a/src/mesa/drivers/dri/i965/gen8_instruction.cpp
> b/src/mesa/drivers/dri/i965/gen8_instruction.cpp
> new file mode 100644
> index 000..a6f8667
> --- /dev/null
> +++ b/src/mesa/drivers/dri/i965/gen8_instruction.cpp
> +void
> +gen8_instruction::set_dst(struct brw_reg reg)
> +{
> + /* MRFs haven't existed since Gen7, so we better not be using them. */
> + if (reg.file == BRW_MESSAGE_REGISTER_FILE) {
> + reg.file = BRW_GENERAL_REGISTER_FILE;
> + reg.nr += GEN7_MRF_HACK_START;
> + }
> +
> + assert(reg.file != BRW_MESSAGE_REGISTER_FILE);
The comment doesn't match up with code just below to support it. And I
think you could just drop the assert if you're going to still do the MRF
hack. (Same stuff is in set_src0/set_src1).
> +void
> +gen8_instruction::validate_reg(struct brw_reg reg)
> +{
> + int hstride_for_reg[] = {0, 1, 2, 4};
> + int vstride_for_reg[] = {0, 1, 2, 4, 8, 16, 32, 64, 128, 256};
> + int width_for_reg[] = {1, 2, 4, 8, 16};
> + int execsize_for_reg[] = {1, 2, 4, 8, 16};
> + int width, hstride, vstride, execsize;
> +
> + if (reg.file == BRW_IMMEDIATE_VALUE) {
> + /* TODO(gen8): check immediate vectors */
> + return;
> + }
> +
> + if (reg.file == BRW_ARCHITECTURE_REGISTER_FILE)
> + return;
> +
> + assert(reg.hstride >= 0 && reg.hstride < Elements(hstride_for_reg));
> + hstride = hstride_for_reg[reg.hstride];
> +
> + if (reg.vstride == 0xf) {
> + vstride = -1;
> + } else {
> + assert(reg.vstride >= 0 && reg.vstride < Elements(vstride_for_reg));
> + vstride = vstride_for_reg[reg.vstride];
> + }
> +
> + assert(reg.width >= 0 && reg.width < Elements(width_for_reg));
> + width = width_for_reg[reg.width];
> +
> + assert(exec_size() >= 0 && exec_size() < Elements(execsize_for_reg));
> + execsize = execsize_for_reg[exec_size()];
> +
> + /* Restrictions from 3.3.10: Register Region Restrictions. */
> + /* 3. */
> + assert(execsize >= width);
> +
> + /* 4. */
> + if (execsize == width && hstride != 0) {
> + assert(vstride == -1 || vstride == width * hstride);
> + }
> +
> + /* 5. */
> + if (execsize == width && hstride == 0) {
> + /* no restriction on vstride. */
> + }
> +
> + /* 6. */
> + if (width == 1) {
> + assert(hstride == 0);
> + }
> +
> + /* 7. */
> + if (execsize == 1 && width == 1) {
> + assert(hstride == 0);
> + assert(vstride == 0);
> + }
> +
> + /* 8. */
> + if (vstride == 0 && hstride == 0) {
> + assert(width == 1);
> + }
In my spec snapshot, these are 3.3.9.2 A-H now, but there don't seem to
be any changes for bdw. We should really add checks for those other
region restrictions, though. And maybe move all this to after the
instruction is all set up, since we do some tweaks of the strides and
things after validate_reg() in set_src0()/1. Things for later.
> +void
> +gen8_instruction::set_src0(struct brw_reg reg)
> +{
> + validate_reg(reg);
> +
> + set_src0_reg_file(reg.file);
> + set_src0_reg_type(reg.type);
> + set_src0_abs(reg.abs);
> + set_src0_negate(reg.negate);
> +
> + assert(reg.address_mode == BRW_ADDRESS_DIRECT);
> +
> + if (reg.file == BRW_IMMEDIATE_VALUE) {
> + data[3] = reg.dw1.ud;
> +
> + /* Required to set some fields in src1 as well: */
> + set_src1_reg_file(0); /* arf */
Just use BRW_ARCHITECTURE_REGISTER_FI
[Mesa-dev] Mesa 10.0 release candidate 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mesa 10.0 release candidate 1 is now available for testing. The current plan of record is to have release candidate 2 on Friday, November 22nd, and the 10.0 release on Wedensday, November 27th. The tag in the GIT repository for Mesa 10.0-rc1 is 'mesa-10.0-rc1'. Mesa 10.0 release candidate 1 is available for download at ftp://freedesktop.org/pub/mesa/10.0/ md5sums: 62f5dd610c39b20fdd66e5d14fe6da04 MesaLib-10.0.0-rc1.tar.gz 6740ff87262e095fbdf38a01b7575f86 MesaLib-10.0.0-rc1.tar.bz2 c6f901d6f05be94ea43988b10d309934 MesaLib-10.0.0-rc1.zip I have verified building from the .tar.bz2 file by doing: tar -xjf Mesa-10.0.0-rc1.tar.bz2 cd Mesa-10.0.0-rc1 ./configure --enable-gallium-llvm --with-llvm-shared-libs make -j6 make install -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlKKexsACgkQX1gOwKyEAw+fFACfacu1So6R0sTa7s4emSBRIEJi ExcAnjw7l8wl3UetWq6sKDgrLSgdc+sA =V0Ui -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3
On 18/11/13 01:08, Keith Packard wrote:
> libudev doesn't have a stable API/ABI, and if the application wants to use one
> version, we'd best not load another into libGL.
>
> Signed-off-by: Keith Packard
> ---
>
Hi Keith,
Did you had the chance to look at src/gallium/targets/egl-static/egl.c?
It has a different implementation of drm_fd_get_pci_id, whenever udev is
not available.
AFAICS it goes back to the kernel via the relevant ioctl to retrieve the
deviceid/chipid. Currently all but nouveau provide such information. I'm
thinking that this approach might be more reasonable for those concerned
with portability of the udev bits (think on *BSD).
I'm not nitpicking, just thought you might find this interesting.
Cheers,
Emil
> Sorry for the patch spam; I hadn't rebased in a while and there was a
> configure.ac conflict. Here's a version which should apply cleanly to master.
>
> configure.ac | 8
> src/glx/dri3_common.c | 104
> +++---
> 2 files changed, 90 insertions(+), 22 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index fb16338..656d9d0 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -821,9 +821,6 @@ xyesno)
> PKG_CHECK_MODULES([DRI2PROTO], [dri2proto >= $DRI2PROTO_REQUIRED])
> GL_PC_REQ_PRIV="$GL_PC_REQ_PRIV libdrm >= $LIBDRM_REQUIRED"
> if test x"$enable_dri3" = xyes; then
> -if test x"$have_libudev" != xyes; then
> - AC_MSG_ERROR([DRI3 requires libudev >= $LIBUDEV_REQUIRED])
> -fi
> PKG_CHECK_MODULES([DRI3PROTO], [dri3proto >=
> $DRI3PROTO_REQUIRED])
> PKG_CHECK_MODULES([PRESENTPROTO], [presentproto >=
> $PRESENTPROTO_REQUIRED])
> fi
> @@ -847,11 +844,6 @@ xyesno)
> X11_INCLUDES="$X11_INCLUDES $DRIGL_CFLAGS"
> GL_LIB_DEPS="$DRIGL_LIBS"
>
> -if test x"$enable_dri3$have_libudev" = xyesyes; then
> -X11_INCLUDES="$X11_INCLUDES $LIBUDEV_CFLAGS"
> -GL_LIB_DEPS="$GL_LIB_DEPS $LIBUDEV_LIBS"
> -fi
> -
> # need DRM libs, $PTHREAD_LIBS, etc.
> GL_LIB_DEPS="$GL_LIB_DEPS $LIBDRM_LIBS -lm $PTHREAD_LIBS $DLOPEN_LIBS"
> GL_PC_LIB_PRIV="-lm $PTHREAD_LIBS $DLOPEN_LIBS"
> diff --git a/src/glx/dri3_common.c b/src/glx/dri3_common.c
> index c758f96..7330d79 100644
> --- a/src/glx/dri3_common.c
> +++ b/src/glx/dri3_common.c
> @@ -72,22 +72,41 @@
> #include "dri3_priv.h"
>
> #define DRIVER_MAP_DRI3_ONLY
> +
> #include "pci_ids/pci_id_driver_map.h"
>
> +static dev_t
> +dri3_rdev_from_fd(int fd)
> +{
> + struct stat buf;
> +
> + if (fstat(fd, &buf) < 0) {
> + ErrorMessageF("DRI3: failed to stat fd %d", fd);
> + return 0;
> + }
> + return buf.st_rdev;
> +}
> +
> +/*
> + * There are multiple udev library versions, and they aren't polite about
> + * symbols, so just avoid using it until some glorious future when the udev
> + * developers figure out how to not break things
> + */
> +
> +#define USE_UDEV 0
> +#if USE_UDEV
> #include
>
> static struct udev_device *
> dri3_udev_device_new_from_fd(struct udev *udev, int fd)
> {
> struct udev_device *device;
> - struct stat buf;
> + dev_t rdev = dri3_rdev_from_fd(fd);
>
> - if (fstat(fd, &buf) < 0) {
> - ErrorMessageF("DRI3: failed to stat fd %d", fd);
> + if (rdev == 0)
>return NULL;
> - }
>
> - device = udev_device_new_from_devnum(udev, 'c', buf.st_rdev);
> + device = udev_device_new_from_devnum(udev, 'c', rdev);
> if (device == NULL) {
>ErrorMessageF("DRI3: could not create udev device for fd %d", fd);
>return NULL;
> @@ -96,19 +115,20 @@ dri3_udev_device_new_from_fd(struct udev *udev, int fd)
> return device;
> }
>
> -char *
> -dri3_get_driver_for_fd(int fd)
> +static int
> +dri3_get_pci_id_from_fd(int fd, int *vendorp, int *chipp)
> {
> struct udev *udev;
> struct udev_device *device, *parent;
> const char *pci_id;
> - char *driver = NULL;
> - int vendor_id, chip_id, i, j;
> + int ret = 0;
>
> udev = udev_new();
> + if (!udev)
> + goto no_udev;
> device = dri3_udev_device_new_from_fd(udev, fd);
> if (device == NULL)
> - return NULL;
> + goto no_dev;
>
> parent = udev_device_get_parent(device);
> if (parent == NULL) {
> @@ -118,10 +138,69 @@ dri3_get_driver_for_fd(int fd)
>
> pci_id = udev_device_get_property_value(parent, "PCI_ID");
> if (pci_id == NULL ||
> - sscanf(pci_id, "%x:%x", &vendor_id, &chip_id) != 2) {
> + sscanf(pci_id, "%x:%x", vendorp, chipp) != 2) {
>ErrorMessageF("DRI3: malformed or no PCI ID");
>goto out;
> }
> + ret = 1;
> +
> +out:
> + udev_device_unref(device);
> +no_dev:
> + udev_unref(udev);
> +no_udev:
> + return ret;
> +}
> +#else
> +
> +#define SYS_PATH_MAX256
> +
> +static int
> +dri3_read_hex(dev_t rdev, char *entry, int *value)
> +{
> + char path[SYS_PATH_MAX];
> + FILE *f;
> + int
Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/17/2013 06:43 PM, Keith Packard wrote: > Emil Velikov writes: > >> On 18/11/13 01:08, Keith Packard wrote: >>> libudev doesn't have a stable API/ABI, and if the application >>> wants to use one version, we'd best not load another into >>> libGL. >>> >>> Signed-off-by: Keith Packard --- >>> >> Hi Keith, >> >> Firstly, I would like to apologise for the rather daft >> questions. >> >> With that said, looking through your patch I've noticed that >> (most of) your int functions are returning 0 or failure and 1 on >> success. Were those functions meant to return boolean/bool? > > Sure, but I was too lazy to figure out which kind of bool belongs > in that part of mesa... For future reference... for things not accesible to the application or some other library (with its own boolean type), the answer is always bool from stdbool.h. > ___ dri-devel mailing > list dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iEYEARECAAYFAlKKjbcACgkQX1gOwKyEAw9O8gCeM1SQmZcOSaSxJy5yT42ItxQU 1UUAoI9Gl1ah9P1/0AG+huawKAPzF9V9 =d3i2 -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/mesa: pass correct pipe_texture_target to st_choose_format()
We were always passing PIPE_TEXTURE_2D, but not all formats are
supported for all types of textures. In particular, the driver may
not supported texture compression for all types of textures.
---
src/mesa/state_tracker/st_format.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/mesa/state_tracker/st_format.c
b/src/mesa/state_tracker/st_format.c
index 33c2ca6..ec25523 100644
--- a/src/mesa/state_tracker/st_format.c
+++ b/src/mesa/state_tracker/st_format.c
@@ -45,6 +45,7 @@
#include "pipe/p_defines.h"
#include "pipe/p_screen.h"
#include "util/u_format.h"
+#include "st_cb_texture.h"
#include "st_context.h"
#include "st_format.h"
@@ -1726,6 +1727,7 @@ st_ChooseTextureFormat(struct gl_context *ctx, GLenum
target,
struct st_context *st = st_context(ctx);
enum pipe_format pFormat;
unsigned bindings;
+ enum pipe_texture_target pTarget = gl_target_to_pipe(target);
if (target == GL_TEXTURE_1D || target == GL_TEXTURE_1D_ARRAY) {
/* We don't do compression for these texture targets because of
@@ -1782,12 +1784,12 @@ st_ChooseTextureFormat(struct gl_context *ctx, GLenum
target,
}
pFormat = st_choose_format(st, internalFormat, format, type,
- PIPE_TEXTURE_2D, 0, bindings, ctx->Mesa_DXTn);
+ pTarget, 0, bindings, ctx->Mesa_DXTn);
if (pFormat == PIPE_FORMAT_NONE) {
/* try choosing format again, this time without render target bindings */
pFormat = st_choose_format(st, internalFormat, format, type,
- PIPE_TEXTURE_2D, 0, PIPE_BIND_SAMPLER_VIEW,
+ pTarget, 0, PIPE_BIND_SAMPLER_VIEW,
ctx->Mesa_DXTn);
}
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] svga: we don't supported 3D compressed textures
---
src/gallium/drivers/svga/svga_screen.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/drivers/svga/svga_screen.c
b/src/gallium/drivers/svga/svga_screen.c
index 3c013ea..ebcad2c 100644
--- a/src/gallium/drivers/svga/svga_screen.c
+++ b/src/gallium/drivers/svga/svga_screen.c
@@ -23,6 +23,7 @@
*
**/
+#include "util/u_format.h"
#include "util/u_memory.h"
#include "util/u_inlines.h"
#include "util/u_string.h"
@@ -446,6 +447,11 @@ svga_is_format_supported( struct pipe_screen *screen,
}
}
+ if (target == PIPE_TEXTURE_3D && util_format_is_compressed(format)) {
+ /* we don't support compressed 3D textures at this time */
+ return FALSE;
+ }
+
/*
* Query the host capabilities.
*/
--
1.7.10.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] st/mesa: pass correct pipe_texture_target to st_choose_format()
Good catch, both patches in the series are
Reviewed-by: Jakob Bornecrantz
Cheers, Jakob.
On Mon, Nov 18, 2013 at 11:55 PM, Brian Paul wrote:
> We were always passing PIPE_TEXTURE_2D, but not all formats are
> supported for all types of textures. In particular, the driver may
> not supported texture compression for all types of textures.
> ---
> src/mesa/state_tracker/st_format.c |6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/mesa/state_tracker/st_format.c
> b/src/mesa/state_tracker/st_format.c
> index 33c2ca6..ec25523 100644
> --- a/src/mesa/state_tracker/st_format.c
> +++ b/src/mesa/state_tracker/st_format.c
> @@ -45,6 +45,7 @@
> #include "pipe/p_defines.h"
> #include "pipe/p_screen.h"
> #include "util/u_format.h"
> +#include "st_cb_texture.h"
> #include "st_context.h"
> #include "st_format.h"
>
> @@ -1726,6 +1727,7 @@ st_ChooseTextureFormat(struct gl_context *ctx, GLenum
> target,
> struct st_context *st = st_context(ctx);
> enum pipe_format pFormat;
> unsigned bindings;
> + enum pipe_texture_target pTarget = gl_target_to_pipe(target);
>
> if (target == GL_TEXTURE_1D || target == GL_TEXTURE_1D_ARRAY) {
>/* We don't do compression for these texture targets because of
> @@ -1782,12 +1784,12 @@ st_ChooseTextureFormat(struct gl_context *ctx, GLenum
> target,
> }
>
> pFormat = st_choose_format(st, internalFormat, format, type,
> - PIPE_TEXTURE_2D, 0, bindings, ctx->Mesa_DXTn);
> + pTarget, 0, bindings, ctx->Mesa_DXTn);
>
> if (pFormat == PIPE_FORMAT_NONE) {
>/* try choosing format again, this time without render target bindings
> */
>pFormat = st_choose_format(st, internalFormat, format, type,
> - PIPE_TEXTURE_2D, 0, PIPE_BIND_SAMPLER_VIEW,
> + pTarget, 0, PIPE_BIND_SAMPLER_VIEW,
> ctx->Mesa_DXTn);
> }
>
> --
> 1.7.10.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] i965: Link -ldl after libmesa.la
DLOPEN_LIBS is part of DRI_LIB_DEPS. --- src/mesa/drivers/dri/i965/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/mesa/drivers/dri/i965/Makefile.am b/src/mesa/drivers/dri/i965/Makefile.am index 8c0f9a3..3b46af8 100644 --- a/src/mesa/drivers/dri/i965/Makefile.am +++ b/src/mesa/drivers/dri/i965/Makefile.am @@ -46,8 +46,8 @@ TEST_LIBS = \ libi965_dri.la \ ../common/libdricommon.la \ ../common/libmegadriver_stub.la \ - $(DRI_LIB_DEPS) \ ../../../libmesa.la \ + $(DRI_LIB_DEPS) \ -lrt \ ../common/libdri_test_stubs.la -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/15] i965: Add a new representation for Broadwell shader instructions.
On 11/18/2013 12:27 PM, Eric Anholt wrote: > Kenneth Graunke writes: > >> Broadwell significantly changes the EU instruction encoding. Many of >> the fields got moved to different bit positions; some even got split >> in two. >> >> With so many changes, it was infeasible to continue using struct >> brw_instruction. We needed a new representation. >> >> This new approach is a bit different: rather than a struct, I created a >> class that has four DWords, and helper functions that read/write various >> bits. This has several advantages: >> >> 1. We can create several different names for the same bits. For >>example, conditional modifiers, SFID for SEND instructions, and the >>MATH instruction's function opcode are all stored in bits 27:24. >> >>In each situation, we can use the appropriate setter function: >>set_sfid(), set_math_function(), or set_cond_modifier(). This >>is much easier to follow. >> >> 2. Since the fields are expressed using the original 128-bit numbers, >>the code to create the getter/setter functions follows the table in >>the documentation very closely. >> >> To aid in debugging, I've enabled -fkeep-inline-functions when building >> gen8_instruction.cpp. Otherwise, these functions cannot be called by >> gdb, making it insanely difficult to print out anything. > > I dislike C++ creep. I wrote this in C++ because all of the compiler infrastructure which uses it is already in C++. It seemed natural. However, Damien requested that we write it in C so it could be easily copied to xf86-video-intel, intel-gpu-tools, gen4asm/disasm, etc. Which is probably a good thing. He actually already ported it to C. I can dig up that version and see how you like it... > I think the old structs worked OK, and there are > some minor downsides to access-everything-through-methods, like being > unable to just print the instruction in gdb and see fields all at once, Huh. I've never done that. Is that something you actually do? I imagine looking at the raw dump would be pretty huge, and a pretty-printer/disassembler would always be more useful... > and having to do the build system hack to inline but also keep the > inlines. But I'm feeling more and more alone on the team. Well, you're less alone than you think. I believe the build system hack is fairly orthogonal to the C++ issue. We could also have small inline C functions defined in a .h file which also take the get_bits/set_bits approach. I would have appreciated getting "I don't like your design" feedback sooner than a year after I wrote it. But the most important thing is to have the system we want going forward, which people are happy with and can maintain. So I'm open to rewriting it (just a bit grumpy). --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] i965/test: Use unreachable() to silence warning.
---
src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
b/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
index c5a3cfc..83d931c 100644
--- a/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
+++ b/src/mesa/drivers/dri/i965/test_vec4_register_coalesce.cpp
@@ -88,6 +88,7 @@ protected:
virtual vec4_instruction *emit_urb_write_opcode(bool complete)
{
assert(!"Not reached");
+ unreachable();
}
};
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix setup of LocalParams array.
On 11/18/2013 11:07 AM, Eric Anholt wrote:
i965 passed piglit, but swrast and gallium both segfaulted without this.
i965 happened to work because it never ran _mesa_load_state_parameters()
on the new program before the test called glProgramLocalParameter(), which
was allocating a LocalParams array for the fallback path.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D71734&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=n3QosB0LfKkjHz3sK6d%2F4MBWkl%2BZgLi1HA1PNmcAH4Q%3D%0A&s=8ce86f72ab8d603739e1c773d926cb29e6f912ee659e0e7181ee3da13da6ec7b
---
src/mesa/program/arbprogparse.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/program/arbprogparse.c b/src/mesa/program/arbprogparse.c
index 5b96650..5d92176 100644
--- a/src/mesa/program/arbprogparse.c
+++ b/src/mesa/program/arbprogparse.c
@@ -127,6 +127,7 @@ _mesa_parse_arb_fragment_program(struct gl_context* ctx,
GLenum target,
if (program->Base.Parameters)
_mesa_free_parameter_list(program->Base.Parameters);
program->Base.Parameters= prog.Parameters;
+ program->Base.LocalParams = prog.LocalParams;
/* Append fog instructions now if the program has "OPTION ARB_fog_exp"
* or similar. We used to leave this up to drivers, but it appears
The same change needs to be done in the _mesa_parse_arb_vertex_program()
function too:
@@ -205,6 +206,7 @@ _mesa_parse_arb_vertex_program(struct gl_context
*ctx, GLenu
if (program->Base.Parameters)
_mesa_free_parameter_list(program->Base.Parameters);
program->Base.Parameters = prog.Parameters;
+ program->Base.LocalParams = prog.LocalParams;
#if DEBUG_VP
printf("Vertex program %u __\n", program->Base.Id);
With those changes the piglit ARB_vertex/fragment_program crashes are fixed.
If you update the patch:
Tested-by: Brian Paul
Reviewed-by: Brian Paul
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix setup of LocalParams array.
On 11/18/2013 04:25 PM, Brian Paul wrote:
On 11/18/2013 11:07 AM, Eric Anholt wrote:
i965 passed piglit, but swrast and gallium both segfaulted without this.
i965 happened to work because it never ran _mesa_load_state_parameters()
on the new program before the test called glProgramLocalParameter(),
which
was allocating a LocalParams array for the fallback path.
Bugzilla:
https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D71734&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=n3QosB0LfKkjHz3sK6d%2F4MBWkl%2BZgLi1HA1PNmcAH4Q%3D%0A&s=8ce86f72ab8d603739e1c773d926cb29e6f912ee659e0e7181ee3da13da6ec7b
---
src/mesa/program/arbprogparse.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/mesa/program/arbprogparse.c
b/src/mesa/program/arbprogparse.c
index 5b96650..5d92176 100644
--- a/src/mesa/program/arbprogparse.c
+++ b/src/mesa/program/arbprogparse.c
@@ -127,6 +127,7 @@ _mesa_parse_arb_fragment_program(struct
gl_context* ctx, GLenum target,
if (program->Base.Parameters)
_mesa_free_parameter_list(program->Base.Parameters);
program->Base.Parameters= prog.Parameters;
+ program->Base.LocalParams = prog.LocalParams;
/* Append fog instructions now if the program has "OPTION
ARB_fog_exp"
* or similar. We used to leave this up to drivers, but it appears
The same change needs to be done in the _mesa_parse_arb_vertex_program()
function too:
@@ -205,6 +206,7 @@ _mesa_parse_arb_vertex_program(struct gl_context
*ctx, GLenu
if (program->Base.Parameters)
_mesa_free_parameter_list(program->Base.Parameters);
program->Base.Parameters = prog.Parameters;
+ program->Base.LocalParams = prog.LocalParams;
#if DEBUG_VP
printf("Vertex program %u __\n",
program->Base.Id);
And yes, it's lame that the same code is in two places. I could fix
that up in a follow-on patch.
-Brian
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glx: don't fail out when no configs if we have visuals
From: Dave Airlie
GLX 1.2 servers with no SGIX_fbconfigs exist (some citrix thing),
and we fail glxinfo completely in those cases.
Signed-off-by: Dave Airlie
---
src/glx/glxcmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/glx/glxcmds.c b/src/glx/glxcmds.c
index 3b250cc..ec16e8f 100644
--- a/src/glx/glxcmds.c
+++ b/src/glx/glxcmds.c
@@ -183,7 +183,7 @@ GetGLXPrivScreenConfig(Display * dpy, int scrn, struct
glx_display ** ppriv,
/* Check to see if the GL is supported on this screen */
*ppsc = (*ppriv)->screens[scrn];
- if ((*ppsc)->configs == NULL) {
+ if ((*ppsc)->configs == NULL && (*ppsc)->visuals == NULL) {
/* No support for GL on this screen regardless of visual */
return GLX_BAD_VISUAL;
}
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] glxinfo: handle no fbconfigs case better
From: Dave Airlie
If we get a server that has only GLX1.2 and no SGIX_fbconfig, we can
print stuff we shouldn't. If we have no fbconfigs then we don't have core
profile, so don't bother trying visual path when doing core profile.
Signed-off-by: Dave Airlie
---
src/xdemos/glxinfo.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c
index bb9e100..25967f7 100644
--- a/src/xdemos/glxinfo.c
+++ b/src/xdemos/glxinfo.c
@@ -862,13 +862,14 @@ print_screen_info(Display *dpy, int scrnum, Bool
allowDirect,
visinfo = glXGetVisualFromFBConfig(dpy, fbconfigs[0]);
XFree(fbconfigs);
}
- else {
+ else if (!coreProfile) {
visinfo = choose_xvisinfo(dpy, scrnum);
if (visinfo)
ctx = glXCreateContext(dpy, visinfo, NULL, allowDirect);
- }
+ } else
+ visinfo = NULL;
- if (!visinfo) {
+ if (!visinfo && !coreProfile) {
fprintf(stderr, "Error: couldn't find RGB GLX visual or fbconfig\n");
return False;
}
--
1.8.4.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/15] i965: Add a new representation for Broadwell shader instructions.
On 11/18/2013 03:22 PM, Kenneth Graunke wrote: > On 11/18/2013 12:27 PM, Eric Anholt wrote: [snip] >> I think the old structs worked OK, and there are >> some minor downsides to access-everything-through-methods, like being >> unable to just print the instruction in gdb and see fields all at once, > > Huh. I've never done that. Is that something you actually do? I > imagine looking at the raw dump would be pretty huge, and a > pretty-printer/disassembler would always be more useful... In particular, (gdb) p p->store[0] prints 114 lines of text in a format that I find basically unreadable. It also contains information in a redundant form, with sections that only apply to G45, or Sandybridge, or... So I'm having a hard time believing this is what you want. I think a print function which does something like: opcode: 0x84 pad: 0 access_mode: 1 mask_control: 0 ... might be more useful... OTOH, (gdb) p p->store[0].header prints a lot less data, and is pretty readable... Or am I misunderstanding entirely? ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 09/15] i965: Add a new representation for Broadwell shader instructions.
On 11/18/2013 03:22 PM, Kenneth Graunke wrote: > On 11/18/2013 12:27 PM, Eric Anholt wrote: >> Kenneth Graunke writes: >> >>> Broadwell significantly changes the EU instruction encoding. Many of >>> the fields got moved to different bit positions; some even got split >>> in two. >>> >>> With so many changes, it was infeasible to continue using struct >>> brw_instruction. We needed a new representation. >>> >>> This new approach is a bit different: rather than a struct, I created a >>> class that has four DWords, and helper functions that read/write various >>> bits. This has several advantages: >>> >>> 1. We can create several different names for the same bits. For >>>example, conditional modifiers, SFID for SEND instructions, and the >>>MATH instruction's function opcode are all stored in bits 27:24. >>> >>>In each situation, we can use the appropriate setter function: >>>set_sfid(), set_math_function(), or set_cond_modifier(). This >>>is much easier to follow. >>> >>> 2. Since the fields are expressed using the original 128-bit numbers, >>>the code to create the getter/setter functions follows the table in >>>the documentation very closely. >>> >>> To aid in debugging, I've enabled -fkeep-inline-functions when building >>> gen8_instruction.cpp. Otherwise, these functions cannot be called by >>> gdb, making it insanely difficult to print out anything. >> >> I dislike C++ creep. > > I wrote this in C++ because all of the compiler infrastructure which > uses it is already in C++. It seemed natural. > > However, Damien requested that we write it in C so it could be easily > copied to xf86-video-intel, intel-gpu-tools, gen4asm/disasm, etc. Which > is probably a good thing. He actually already ported it to C. For reference, Damien's C port of this code is in the public intel-gpu-tools repo as assember/gen8_instruction.[ch]: http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/plain/assembler/gen8_instruction.h http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/plain/assembler/gen8_instruction.c So I guess we have some options: 1. Use the C++ version of my bitfield approach. 2. Use Damien's C port of my bitfield approach. 3. Rewrite it as a struct of union of structs again. Having a system that Eric likes is important to me. I'm interested to hear other opinions as well... --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 27/27] i965: Enable the AMD_performance_monitor extension on Gen5+.
On 11/18/2013 10:33 AM, Eric Anholt wrote: > Kenneth Graunke writes: > >> XXX: Gen6+ needs to be predicated on register writes. >> >> our register write checking function doesn't work on Gen6. > > Even if you can just enable it on gen7, this series is: > > Reviewed-by: Eric Anholt Now I'm confused. I thought you and Carl found regressions in patch 3 (the tri-state ring enum patch), and that you basically NAK'd patch 04 because it adds code to BEGIN_BATCH. I had thought I needed to rewrite patch 4 before I could upstream this. Please clarify. Thanks, --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix setup of LocalParams array.
Brian Paul writes:
> On 11/18/2013 04:25 PM, Brian Paul wrote:
>> On 11/18/2013 11:07 AM, Eric Anholt wrote:
>>> i965 passed piglit, but swrast and gallium both segfaulted without this.
>>> i965 happened to work because it never ran _mesa_load_state_parameters()
>>> on the new program before the test called glProgramLocalParameter(),
>>> which
>>> was allocating a LocalParams array for the fallback path.
>>>
>>> Bugzilla:
>>> https://urldefense.proofpoint.com/v1/url?u=https://bugs.freedesktop.org/show_bug.cgi?id%3D71734&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=lGQMzzTgII0I7jefp2FHq7WtZ%2BTLs8wadB%2BiIj9xpBY%3D%0A&m=n3QosB0LfKkjHz3sK6d%2F4MBWkl%2BZgLi1HA1PNmcAH4Q%3D%0A&s=8ce86f72ab8d603739e1c773d926cb29e6f912ee659e0e7181ee3da13da6ec7b
>>>
>>> ---
>>> src/mesa/program/arbprogparse.c | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/src/mesa/program/arbprogparse.c
>>> b/src/mesa/program/arbprogparse.c
>>> index 5b96650..5d92176 100644
>>> --- a/src/mesa/program/arbprogparse.c
>>> +++ b/src/mesa/program/arbprogparse.c
>>> @@ -127,6 +127,7 @@ _mesa_parse_arb_fragment_program(struct
>>> gl_context* ctx, GLenum target,
>>> if (program->Base.Parameters)
>>> _mesa_free_parameter_list(program->Base.Parameters);
>>> program->Base.Parameters= prog.Parameters;
>>> + program->Base.LocalParams = prog.LocalParams;
>>>
>>> /* Append fog instructions now if the program has "OPTION
>>> ARB_fog_exp"
>>> * or similar. We used to leave this up to drivers, but it appears
>>>
>>
>> The same change needs to be done in the _mesa_parse_arb_vertex_program()
>> function too:
>>
>> @@ -205,6 +206,7 @@ _mesa_parse_arb_vertex_program(struct gl_context
>> *ctx, GLenu
>> if (program->Base.Parameters)
>> _mesa_free_parameter_list(program->Base.Parameters);
>> program->Base.Parameters = prog.Parameters;
>> + program->Base.LocalParams = prog.LocalParams;
>>
>> #if DEBUG_VP
>> printf("Vertex program %u __\n",
>> program->Base.Id);
>
> And yes, it's lame that the same code is in two places. I could fix
> that up in a follow-on patch.
It's also lame that my patch loses track of the old LocalParams data and
leaks the memory. New patch incoming with a totall different plan for
the fix.
pgp0vHFOao4No.pgp
Description: PGP signature
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] i965: Link -ldl after libmesa.la
Matt Turner writes: > DLOPEN_LIBS is part of DRI_LIB_DEPS. > --- > src/mesa/drivers/dri/i965/Makefile.am | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/mesa/drivers/dri/i965/Makefile.am > b/src/mesa/drivers/dri/i965/Makefile.am > index 8c0f9a3..3b46af8 100644 > --- a/src/mesa/drivers/dri/i965/Makefile.am > +++ b/src/mesa/drivers/dri/i965/Makefile.am > @@ -46,8 +46,8 @@ TEST_LIBS = \ > libi965_dri.la \ > ../common/libdricommon.la \ > ../common/libmegadriver_stub.la \ > - $(DRI_LIB_DEPS) \ > ../../../libmesa.la \ > + $(DRI_LIB_DEPS) \ > -lrt \ > ../common/libdri_test_stubs.la Reviewed-by: Eric Anholt pgpX43lTlqYPQ.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 27/27] i965: Enable the AMD_performance_monitor extension on Gen5+.
Kenneth Graunke writes: > On 11/18/2013 10:33 AM, Eric Anholt wrote: >> Kenneth Graunke writes: >> >>> XXX: Gen6+ needs to be predicated on register writes. >>> >>> our register write checking function doesn't work on Gen6. >> >> Even if you can just enable it on gen7, this series is: >> >> Reviewed-by: Eric Anholt > > Now I'm confused. I thought you and Carl found regressions in patch 3 > (the tri-state ring enum patch), and that you basically NAK'd patch 04 > because it adds code to BEGIN_BATCH. > > I had thought I needed to rewrite patch 4 before I could upstream this. > Please clarify. We found some slight flushing behavior change in patch 3, which we talked over and I thought you'd squashed in the fix for already (the missed true/false -> *_RING). As far as patch 4: I'd almost always rather avoid BEGIN_BATCH overhead since we call it so much, but the last other solution we talked about (explicit ring switching) seemed like a scary maintenance problem because you wouldn't notice when you forgot to add a switch to render, since the ring's almost always in render already anyway. pgp3PLfJluFyn.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Fix setup of LocalParams array.
i965 passed piglit, but swrast and gallium both segfaulted without this.
i965 happened to work because it never ran _mesa_load_state_parameters()
on the new program before the test called glProgramLocalParameter(), which
was allocating a LocalParams array for the fallback path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71734
v2: Since v1 threw away old localparams data, leaked old LocalParams
memory, only fixed fragment programs, and I was dubious of my previous
invariants already (nothing but program_parse.y will generate
LocalParams, and only that one path of program_parse.y will), just
late-allocate localparams at the other point of dereferencing them.
This adds overhead to _mesa_load_state_parameter, which is
uncomfortable, but I'm pretty sure that giant switch statement is
super slow already.
---
src/mesa/program/prog_statevars.c | 14 ++
src/mesa/program/program_parse.y | 7 ---
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/src/mesa/program/prog_statevars.c
b/src/mesa/program/prog_statevars.c
index f6fd535..58e1f49 100644
--- a/src/mesa/program/prog_statevars.c
+++ b/src/mesa/program/prog_statevars.c
@@ -368,6 +368,13 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index state[],
COPY_4V(value, ctx->FragmentProgram.Parameters[idx]);
return;
case STATE_LOCAL:
+ if (!ctx->FragmentProgram.Current->Base.LocalParams) {
+ ctx->FragmentProgram.Current->Base.LocalParams =
+ calloc(MAX_PROGRAM_LOCAL_PARAMS, sizeof(float[4]));
+ if (!ctx->FragmentProgram.Current->Base.LocalParams)
+ return;
+ }
+
COPY_4V(value,
ctx->FragmentProgram.Current->Base.LocalParams[idx]);
return;
default:
@@ -387,6 +394,13 @@ _mesa_fetch_state(struct gl_context *ctx, const
gl_state_index state[],
COPY_4V(value, ctx->VertexProgram.Parameters[idx]);
return;
case STATE_LOCAL:
+ if (!ctx->VertexProgram.Current->Base.LocalParams) {
+ ctx->VertexProgram.Current->Base.LocalParams =
+ calloc(MAX_PROGRAM_LOCAL_PARAMS, sizeof(float[4]));
+ if (!ctx->VertexProgram.Current->Base.LocalParams)
+ return;
+ }
+
COPY_4V(value,
ctx->VertexProgram.Current->Base.LocalParams[idx]);
return;
default:
diff --git a/src/mesa/program/program_parse.y b/src/mesa/program/program_parse.y
index 03c0a3d..a76db4e 100644
--- a/src/mesa/program/program_parse.y
+++ b/src/mesa/program/program_parse.y
@@ -25,7 +25,6 @@
#include
#include
-#include "main/macros.h"
#include "main/mtypes.h"
#include "main/imports.h"
#include "program/program.h"
@@ -2560,12 +2559,6 @@ initialize_symbol_from_param(struct gl_program *prog,
param_var->type = at_param;
param_var->param_binding_type = PROGRAM_STATE_VAR;
- /* Dynamically allocate LocalParams, since it's a large array to have
-* statically in every gl_program otherwise.
-*/
- if (state_tokens[1] == STATE_LOCAL && !prog->LocalParams)
- prog->LocalParams = calloc(MAX_PROGRAM_LOCAL_PARAMS, sizeof(float[4]));
-
/* If we are adding a STATE_ENV or STATE_LOCAL that has multiple elements,
* we need to unroll it and call add_state_reference() for each row
*/
--
1.8.4.rc3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] sampler arrays indexed with non-constant expressions
Hello Paul, thank you for the explanation. I thought that relaxing the spec conformance in this particular harmless case would be beneficial both to programmers and users. I understand and accept your reasoning even though deep in my heart I feel that by-the-book conformance is overly dogmatic. Guess the bug 71723 may be closed now. Thanks again! -- Best regards, Victor Luchitz ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix setup of LocalParams array.
On Mon, 2013-11-18 at 17:27 -0800, Eric Anholt wrote: > i965 passed piglit, but swrast and gallium both segfaulted without this. > i965 happened to work because it never ran _mesa_load_state_parameters() > on the new program before the test called glProgramLocalParameter(), which > was allocating a LocalParams array for the fallback path. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71734 > > v2: Since v1 threw away old localparams data, leaked old LocalParams > memory, only fixed fragment programs, and I was dubious of my previous > invariants already (nothing but program_parse.y will generate > LocalParams, and only that one path of program_parse.y will), just > late-allocate localparams at the other point of dereferencing them. > This adds overhead to _mesa_load_state_parameter, which is > uncomfortable, but I'm pretty sure that giant switch statement is > super slow already. Fixes the piglit crashes with radeonsi, thanks Eric. Tested-by: Michel Dänzer -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 27/27] i965: Enable the AMD_performance_monitor extension on Gen5+.
On 11/18/2013 05:22 PM, Eric Anholt wrote: > Kenneth Graunke writes: > >> On 11/18/2013 10:33 AM, Eric Anholt wrote: >>> Kenneth Graunke writes: >>> XXX: Gen6+ needs to be predicated on register writes. our register write checking function doesn't work on Gen6. >>> >>> Even if you can just enable it on gen7, this series is: >>> >>> Reviewed-by: Eric Anholt >> >> Now I'm confused. I thought you and Carl found regressions in patch 3 >> (the tri-state ring enum patch), and that you basically NAK'd patch 04 >> because it adds code to BEGIN_BATCH. >> >> I had thought I needed to rewrite patch 4 before I could upstream this. >> Please clarify. > > We found some slight flushing behavior change in patch 3, which we > talked over and I thought you'd squashed in the fix for already (the > missed true/false -> *_RING). Right. I don't remember hearing conclusively that it was resolved. > As far as patch 4: I'd almost always rather avoid BEGIN_BATCH overhead > since we call it so much, but the last other solution we talked about > (explicit ring switching) seemed like a scary maintenance problem > because you wouldn't notice when you forgot to add a switch to render, > since the ring's almost always in render already anyway. Okay, I thought you NAK'd both solutions and were hoping I would come up with something else. I guess we can go with this for now, and improve later... I did run OpenArena with INTEL_NO_HW=1 on my Ivybridge with master vs. explicit ring switches, and saw no difference (n=9). Hardly conclusive, but removing the existing implicit-flush overhead didn't seem to be much of win. --Ken ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Don't use libudev for glx/dri3
Emil Velikov writes: > On 18/11/13 01:08, Keith Packard wrote: >> libudev doesn't have a stable API/ABI, and if the application wants to use >> one >> version, we'd best not load another into libGL. >> >> Signed-off-by: Keith Packard >> --- >> > Hi Keith, > > Did you had the chance to look at src/gallium/targets/egl-static/egl.c? > It has a different implementation of drm_fd_get_pci_id, whenever udev is > not available. Yeah, it's ugly in a different way from the udev technique... > AFAICS it goes back to the kernel via the relevant ioctl to retrieve the > deviceid/chipid. Currently all but nouveau provide such information. I'm > thinking that this approach might be more reasonable for those concerned > with portability of the udev bits (think on *BSD). I'd encourage some kind of standard IOCTL from DRM that returns the PCI-ID of the underlying device, rather than relying on the level of kludge present in either the udev (or my fake udev) method or the non-udev path in the egl code... > I'm not nitpicking, just thought you might find this interesting. Definitely interesting; it's almost what we want -- the kernel knows the information, there just isn't a clean way of getting it (and no way at all for some devices). -- keith.pack...@intel.com pgpHiOs5jRUMR.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
