Re: [Mesa-dev] [PATCH 1/4] r600g/compute: Don't leak cbufs in compute state
surface_destroy should never be called directly, because surfaces have
a reference counter. For unreferencing resources, use
pipe_surface_reference(pointer, NULL). It will call surface_destroy
if needed.
Marek
On Fri, Nov 14, 2014 at 12:43 AM, Aaron Watry awa...@gmail.com wrote:
Walk the array of cbufs backwards and free all of them.
v3: Rebase on top of changes since Aug 2014
Signed-off-by: Aaron Watry awa...@gmail.com
---
src/gallium/drivers/r600/evergreen_compute.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/gallium/drivers/r600/evergreen_compute.c
b/src/gallium/drivers/r600/evergreen_compute.c
index 90fdd79..4334743 100644
--- a/src/gallium/drivers/r600/evergreen_compute.c
+++ b/src/gallium/drivers/r600/evergreen_compute.c
@@ -252,6 +252,15 @@ void evergreen_delete_compute_state(struct pipe_context
*ctx, void* state)
if (!shader)
return;
+ if (shader-ctx){
+ struct pipe_framebuffer_state *fb_state =
shader-ctx-framebuffer.state;
+ for (int i = fb_state-nr_cbufs - 1; fb_state-nr_cbufs 0 ;
i--){
+ shader-ctx-b.b.surface_destroy(ctx,
fb_state-cbufs[i]);
+ fb_state-cbufs[i] = NULL;
+ fb_state-nr_cbufs--;
+ }
+ }
+
FREE(shader);
}
--
2.1.0
___
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] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
On 05/11/14 20:39, Eric Anholt wrote: Marek Olšák mar...@gmail.com writes: Hi everybody, I'm about to address this long-standing issue: The EGL state tracker is redundant. It duplicates what st/dri does and it also duplicates what the common loader egl_dri2 does, which is used by all classic drivers and even works better with gallium drivers. Let's compare EGL extensions for both backends: I'd love to see VG get nuked at the same time, but still: Reviewed-by: Eric Anholt e...@anholt.net Ideally yes. Yet with this series we error out, which should give insensitive for someone to come forward and implement the missing bits. So can we consider Jose's statement [1] as acked-by and get this in for 10.4 ? Or are we going to keep the zombie for another XXX months ? Jose ? Cheers Emil [1] In short, stop caring about st/egl on Linux, maybe even remove DRI support out st/egl if you must, but please don't go out of your way to break EGL on non-linux platforms. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. Afaics he's already applied to commit access with the sole perpose to maintain the state-tracker. Thanks Emil P.S. Patches 3 and 6 have minor comments to address. I don't mind if patch 6 is resolved after the merge. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Move mesa version scheme to a more common style ?
Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. The plan is to still keep the branch point later on today, but to push the tag on Monday. Thanks Emil ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 84724] [regression, bisected] commit 4155d1c7 broke i915g
https://bugs.freedesktop.org/show_bug.cgi?id=84724 yas...@windowslive.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from yas...@windowslive.com --- Fixed by: http://cgit.freedesktop.org/mesa/mesa/commit/?id=2b6e703863f7e5469ba8d82003282cc42f277d5e Thanks! -- 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 0/2] Disable the EGL state tracker for Linux/DRI builds
I googled and tried to find any evidence of anybody using Mesa's EGL on Windows over the last years but couldn't. Furthermore since my last reply on this thread I become quite fond of GLX/WGL_EXT_create_context_es/es2_profile extensions. They seem a much easier mechanism to use and test OpenGL ES contexts, than dealing with EGL on desktop OSes (and the ensuing interactions between EGL + GLX/WGL). I still suspect EGL outside Linux+DRI will have a future, but I don't feel strongly about it anymore. So feel free to remove whatever you want (st/egl, openvg) as far as I'm concerned. We can always bring it back later from git history. Jose From: Emil Velikov emil.l.veli...@gmail.com Sent: 14 November 2014 14:08 To: Eric Anholt; Marek Olšák; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com; Jose Fonseca Subject: Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds On 05/11/14 20:39, Eric Anholt wrote: Marek Olšák mar...@gmail.com writes: Hi everybody, I'm about to address this long-standing issue: The EGL state tracker is redundant. It duplicates what st/dri does and it also duplicates what the common loader egl_dri2 does, which is used by all classic drivers and even works better with gallium drivers. Let's compare EGL extensions for both backends: I'd love to see VG get nuked at the same time, but still: Reviewed-by: Eric Anholt e...@anholt.net Ideally yes. Yet with this series we error out, which should give insensitive for someone to come forward and implement the missing bits. So can we consider Jose's statement [1] as acked-by and get this in for 10.4 ? Or are we going to keep the zombie for another XXX months ? Jose ? Cheers Emil [1] In short, stop caring about st/egl on Linux, maybe even remove DRI support out st/egl if you must, but please don't go out of your way to break EGL on non-linux platforms. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Does this really make it a more conventional numbering scheme? I've personally seen the 10.4.1-rc1-scheme way more often than the 10.4.0.901-scheme. In fact, I think this is the first time I've seen the latter used. But I haven't exactly gone out of my way looking for versioning schemes. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. Shouldn't it be the other way around? IMO we should have strong arguments for *changing* it, rather than keep going as-is... Any change can break something, so only changes that have clear benefits should be done, no? AFAICT, the current scheme conveys more relevant, obvious information than the proposed one, namely that it's a release *candidate* for v10.4.1. If no blocking issues are found, it'll become the *actual* release... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On Fri, Nov 14, 2014 at 9:14 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. To the best of my knowledge, wine has no intent on merging anything related to nine/st. There are no tests, either. What's the path forward for this project? I know it's a pain to maintain out of tree, but that alone isn't a good reason to merge something. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. Huh? What's wrong with the current thing? Can I put in an alternate suggestion of getting the other projects to switch to the mesa (and linux kernel and wine and many many many other projects) rc version naming scheme? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote: To the best of my knowledge, wine has no intent on merging anything related to nine/st. That's a bit broader than I'd put it, but yes, in it's current form this is not something we'd merge. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
We plan make automatized tests based on apitrace (documented how to use it with wine just few days ago) of used games. Also we have wine tests. About merging to wine, it needs more work to be done, but in generally, we have packages for wide range of distributions, inlucluding livecd etc. Maintaining it out-of tree make us bisecting more difficult, so it would be really blessing to have it in upstream repository. David On 11/14/2014 04:21 PM, Ilia Mirkin wrote: On Fri, Nov 14, 2014 at 9:14 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 02/11/14 18:27, David Heidelberg wrote: Hello everyone! First I'd like thank you for great feedback. Sending third Gallium Nine merge request. We reduced number of commits to necessary minimum. I hope all proposed changes are incorporated in v3. Thank you Gents, Can we get an acked-by/reviewed-by for this ? Would be a shame to torture David to keep rebasing this for another three months. To the best of my knowledge, wine has no intent on merging anything related to nine/st. There are no tests, either. What's the path forward for this project? I know it's a pain to maintain out of tree, but that alone isn't a good reason to merge something. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 11/14/2014 04:31 PM, Henri Verbeet wrote: On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote: To the best of my knowledge, wine has no intent on merging anything related to nine/st. That's a bit broader than I'd put it, but yes, in it's current form this is not something we'd merge. At this moment we still improving wine tests compliance and catching bugs. We're ready to accept any ideas to make it better, which helps accepting into wine upstream. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On Fri, Nov 14, 2014 at 10:31 AM, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 16:21, Ilia Mirkin imir...@alum.mit.edu wrote: To the best of my knowledge, wine has no intent on merging anything related to nine/st. That's a bit broader than I'd put it, but yes, in it's current form this is not something we'd merge. Is there a different form that you believe would be more likely to be merged? -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 3/3] glx: Allow to create any OpenGL ES version.
It looks like you're missing minor_ver checking here? For instance, 2.99
isn't a valid GLES version.
I think these things are already validated on GLX/eGL, but I confess I'm not
100% sure.
Jose
From: Daniel Stone dan...@fooishbar.org
Sent: 12 November 2014 18:16
To: Jose Fonseca
Cc: mesa-dev@lists.freedesktop.org
Subject: Re: [Mesa-dev] [PATCH 3/3] glx: Allow to create any OpenGL ES version.
Hi,
On 12 November 2014 12:37, jfons...@vmware.commailto:jfons...@vmware.com
wrote:
@@ -544,9 +544,22 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
case GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
*api = __DRI_API_OPENGL;
break;
- case GLX_CONTEXT_ES2_PROFILE_BIT_EXT:
-*api = __DRI_API_GLES2;
-break;
+ case GLX_CONTEXT_ES_PROFILE_BIT_EXT:
+ switch (*major_ver) {
+ case 3:
+*api = __DRI_API_GLES3;
+break;
+ case 2:
+*api = __DRI_API_GLES2;
+break;
+ case 1:
+*api = __DRI_API_GLES;
+break;
+ default:
+*error = __DRI_CTX_ERROR_BAD_API;
+return false;
+ }
+ break;
default:
*error = __DRI_CTX_ERROR_BAD_API;
return false;
@@ -577,19 +590,6 @@ dri2_convert_glx_attribs(unsigned num_attribs, const
uint32_t *attribs,
return false;
}
- /* The GLX_EXT_create_context_es2_profile spec says:
-*
-* ... If the version requested is 2.0, and the
-* GLX_CONTEXT_ES2_PROFILE_BIT_EXT bit is set in the
-* GLX_CONTEXT_PROFILE_MASK_ARB attribute (see below), then the context
-* returned will implement OpenGL ES 2.0. This is the only way in which
-* an implementation may request an OpenGL ES 2.0 context.
-*/
- if (*api == __DRI_API_GLES2 (*major_ver != 2 || *minor_ver != 0)) {
It looks like you're missing minor_ver checking here? For instance, 2.99 isn't
a valid GLES version.
Cheers,
Daniel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds
FYI, I've pushed these patches. Marek On Fri, Nov 14, 2014 at 3:51 PM, Jose Fonseca jfons...@vmware.com wrote: I googled and tried to find any evidence of anybody using Mesa's EGL on Windows over the last years but couldn't. Furthermore since my last reply on this thread I become quite fond of GLX/WGL_EXT_create_context_es/es2_profile extensions. They seem a much easier mechanism to use and test OpenGL ES contexts, than dealing with EGL on desktop OSes (and the ensuing interactions between EGL + GLX/WGL). I still suspect EGL outside Linux+DRI will have a future, but I don't feel strongly about it anymore. So feel free to remove whatever you want (st/egl, openvg) as far as I'm concerned. We can always bring it back later from git history. Jose From: Emil Velikov emil.l.veli...@gmail.com Sent: 14 November 2014 14:08 To: Eric Anholt; Marek Olšák; mesa-dev@lists.freedesktop.org Cc: emil.l.veli...@gmail.com; Jose Fonseca Subject: Re: [Mesa-dev] [PATCH 0/2] Disable the EGL state tracker for Linux/DRI builds On 05/11/14 20:39, Eric Anholt wrote: Marek Olšák mar...@gmail.com writes: Hi everybody, I'm about to address this long-standing issue: The EGL state tracker is redundant. It duplicates what st/dri does and it also duplicates what the common loader egl_dri2 does, which is used by all classic drivers and even works better with gallium drivers. Let's compare EGL extensions for both backends: I'd love to see VG get nuked at the same time, but still: Reviewed-by: Eric Anholt e...@anholt.net Ideally yes. Yet with this series we error out, which should give insensitive for someone to come forward and implement the missing bits. So can we consider Jose's statement [1] as acked-by and get this in for 10.4 ? Or are we going to keep the zombie for another XXX months ? Jose ? Cheers Emil [1] In short, stop caring about st/egl on Linux, maybe even remove DRI support out st/egl if you must, but please don't go out of your way to break EGL on non-linux platforms. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On 14/11/14 15:07, Erik Faye-Lund wrote: On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Does this really make it a more conventional numbering scheme? I've personally seen the 10.4.1-rc1-scheme way more often than the 10.4.0.901-scheme. In fact, I think this is the first time I've seen the latter used. But I haven't exactly gone out of my way looking for versioning schemes. Come on Eric, seriously ? Most/all the projects that I can see on fd.o and gnome, that have stable branches use this scheme. Eg. libX11, libXext, xorg-server, evince, clutter... I would love to be proven wrong, that they are the minority. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. Shouldn't it be the other way around? IMO we should have strong arguments for *changing* it, rather than keep going as-is... Any change can break something, so only changes that have clear benefits should be done, no? Note that we're talking about the rc versions/development branch. For releases things are as normal. Most of the times I tend to think hard before I propose something that seems ground breaking, and in this case I cannot even remotely see a case where something will break. This almost sounds like don't go outside because something can fall from the sky and hit you. No disrespect there. I'll take your and Ilia's views, and would encourage the input from someone that has done this sort of thing (stable branches). Cheers, Emil AFAICT, the current scheme conveys more relevant, obvious information than the proposed one, namely that it's a release *candidate* for v10.4.1. If no blocking issues are found, it'll become the *actual* release... ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On 14/11/14 15:24, Ilia Mirkin wrote: On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. Huh? What's wrong with the current thing? Can I put in an alternate suggestion of getting the other projects to switch to the mesa (and linux kernel and wine and many many many other projects) rc version naming scheme? To be perfectly honest, I don't think I can think of any (apart from the kernel and wine) that have a stable branch(es) and use rc. Can you kindly point me to some or if you have some ideas of a search phrase that would be appreciated. I have the feeling that X related projects tend to exclusively use proposed format, so I'm trying to keep mesa close/related to X, non-alien and consistent. Is that so much to ask for ? -Emil -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On Fri, Nov 14, 2014 at 11:15 AM, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Dave Airlie's virgl work is creating a gallium driver which actually uses OpenGL for hardware. I'm not sure how far he is, but I believe he has enough for GL3. This could be a way forward towards *only* using gallium (since otherwise you'd still have to have an OpenGL-based backend for the hw/platforms that don't have gallium drivers). However gallium will never support fixed-function hardware, so that may still not work for you. Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. While I don't have this justification, I always just assumed this was due to mismatches between how d3d wanted to do things and how OpenGL let you do things, so you ended up having to do some fairly heavy-handed things in OpenGL solely due to the silliness of the API. Let's say that all such things could be identified and extensions created for, you'd still end up effectively managing 2 backends -- one that assumes that the various d3d-helper extensions are there, and one that doesn't. I strongly doubt that the performance increases are due to better d3d9 bytecode - TGSI conversion than - glsl - tgsi conversion -- most serious backends (r600, radeonsi, nouveau) have optimizing compilers that should take care of such issues. They won't, however, take care of issues where you had to change the way resources are managed, the data passed to the GPU, etc. Anyways, from your comments it sounds like the only way forward and given the current capabilities of nine/st would be to create some sort of out-of-tree solution that plugs into wine, providing native d3d9.dll or whatever it's called. That way you guys aren't stuck maintaining 2 backends, and people can get improved performance on d3d9 games on linux. Henri, if you take the fact that people want to use nine/st in its ~current form on linux as a given, is there a different, simpler approach that I'm overlooking? Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
Hi, On 14 November 2014 15:07, Erik Faye-Lund kusmab...@gmail.com wrote: On Fri, Nov 14, 2014 at 3:39 PM, Emil Velikov emil.l.veli...@gmail.com wrote: Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. Shouldn't it be the other way around? IMO we should have strong arguments for *changing* it, rather than keep going as-is... Any change can break something, so only changes that have clear benefits should be done, no? AFAICT, the current scheme conveys more relevant, obvious information than the proposed one, namely that it's a release *candidate* for v10.4.1. If no blocking issues are found, it'll become the *actual* release... You can encode that in the versions too. The other advantage is especially when checking for dependencies, that you have a linear version comparison. Cheers, Daniel ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
[...] We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. Yes, I don't recommend gallium for that. It sounds you want to design a WINE D3D9 DDI pretty much along the lines of the WDDM D3D9 DDI: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552927(v=vs.85).aspx Basically, the runtime is one, but there would be two implementations of that DDI. Runtime would do validation, keep copy of current state for application state queries, etc. Jose From: mesa-dev mesa-dev-boun...@lists.freedesktop.org on behalf of Henri Verbeet hverb...@gmail.com Sent: 14 November 2014 16:15 To: Ilia Mirkin Cc: mesa-dev@lists.freedesktop.org; Emil Velikov; David Heidelberg Subject: Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddevd=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=o3EpupCH7razLQXx0J0R5qQH6tzqk37RKYUG-_pJTl0s=35b52J3rqlzw27gT9LOmvCEHU8Vau408cZeCj5kRU1Ae= ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On Fri, Nov 14, 2014 at 11:17 AM, Emil Velikov emil.l.veli...@gmail.com wrote: On 14/11/14 15:24, Ilia Mirkin wrote: On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. Huh? What's wrong with the current thing? Can I put in an alternate suggestion of getting the other projects to switch to the mesa (and linux kernel and wine and many many many other projects) rc version naming scheme? To be perfectly honest, I don't think I can think of any (apart from the kernel and wine) that have a stable branch(es) and use rc. Can you kindly point me to some or if you have some ideas of a search phrase that would be appreciated. Hmmm... well, most projects don't *have* rc's, so it's definitely a reduced set. But let's see... just thinking about various software I use and plugging it into my favourite search engine: emacs: http://lists.gnu.org/archive/html/info-gnu-emacs/2014-10/msg1.html openssl: https://www.openssl.org/source/ (does -beta1 instead of -rc1, but same idea) pidgin did beta tags for 2.0, but not for all releases: https://hg.pidgin.im/pidgin/main/tags BTW, it's not like I'm leaving out ones that use some other scheme... other ones I looked up just didn't have any such thing at all. I have the feeling that X related projects tend to exclusively use proposed format, so I'm trying to keep mesa close/related to X, non-alien and consistent. Is that so much to ask for ? https://www.youtube.com/watch?v=a7DdyChR8JU -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14/11/2014 17:15, Henri Verbeet wrote : On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. [] Hi, We understand the will of wine devs not to support two implementations. However first, we will maintain that implementation, and the wine bits are rather small (a few files). It's more important for us to be merged in Mesa, because it is much easier for users to install a custom wine build (via playOnLinux, etc) than Mesa. Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL. As for me, I contributed only since a few months ago, and was able to implement a lot of things quite easily, for exemple: . Respect the number of backbuffer asked by the app (as far as I know wine doesn't support = 2 and behaves like 1) . Support the Render-ahead d3d9 behaviour (d3d9 doesn't have tripple buffering like Opengl can have) . wine seems to have a lot of issues with stuttering, etc. We have control of throttling and vsync, and thus don't have any particular issue there . We have very good DRI_PRIME support (better than what GLX has currently). The fact that nine was develloped so fast by few devs show well that it was easier. Some glitches that wine has do not appear on nine. (we have others, but we fix them rapidly when we find them). Nine gets better performance than wine. On my AMD hd 7730m, I get a consistent 10% gain (I'm gpu limited). Others with better cards get better gains. But above all, games fell much more playable due to stable framerate. Third Nine doesn't harm wine implementation. The user explicitly enable/disable Nine support in wine, and if it is enabled and fails to load, it will fallback to normal wine support. User gets a message in console to tell him why it failed/ if Nine is activated. I hope these arguments will help convince you, Axel Davy ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] st/xlib: Generate errors as specified.
From: José Fonseca jfons...@vmware.com
Tested with piglit glx tests.
---
src/gallium/state_trackers/glx/xlib/glx_api.c | 125 ++
1 file changed, 109 insertions(+), 16 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 810910e..1807edb 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -33,6 +33,9 @@
#define GLX_GLXEXT_PROTOTYPES
#include GL/glx.h
+#include X11/Xmd.h
+#include GL/glxproto.h
+
#include xm_api.h
@@ -647,6 +650,52 @@ register_with_display(Display *dpy)
}
+/**
+ * Fake an error.
+ */
+static int
+generate_error(Display *dpy,
+ unsigned char error_code,
+ XID resourceid,
+ unsigned char minor_code,
+ Bool core)
+{
+ XErrorHandler handler;
+ int major_opcode;
+ int first_event;
+ int first_error;
+ XEvent event;
+
+ handler = XSetErrorHandler(NULL);
+ XSetErrorHandler(handler);
+ if (!handler) {
+ return 0;
+ }
+
+ if (!XQueryExtension(dpy, GLX_EXTENSION_NAME, major_opcode, first_event,
first_error)) {
+ major_opcode = 0;
+ first_event = 0;
+ first_error = 0;
+ }
+
+ if (!core) {
+ error_code += first_error;
+ }
+
+ memset(event, 0, sizeof event);
+
+ event.xerror.type = X_Error;
+ event.xerror.display = dpy;
+ event.xerror.resourceid = resourceid;
+ event.xerror.serial = NextRequest(dpy) - 1;
+ event.xerror.error_code = error_code;
+ event.xerror.request_code = major_opcode;
+ event.xerror.minor_code = minor_code;
+
+ return handler(dpy, event.xerror);
+}
+
+
/**/
/*** Begin Fake GLX API Functions ***/
/**/
@@ -2082,8 +2131,10 @@ glXQueryDrawable(Display *dpy, GLXDrawable draw, int
attribute,
{
GLuint width, height;
XMesaBuffer xmbuf = XMesaFindBuffer(dpy, draw);
- if (!xmbuf)
+ if (!xmbuf) {
+ generate_error(dpy, GLXBadDrawable, draw, X_GLXGetDrawableAttributes,
False);
return;
+ }
/* make sure buffer's dimensions are up to date */
xmesa_get_window_size(dpy, xmbuf, width, height);
@@ -2117,7 +2168,8 @@ glXQueryDrawable(Display *dpy, GLXDrawable draw, int
attribute,
#endif
default:
- return; /* raise BadValue error */
+ generate_error(dpy, BadValue, 0, X_GLXCreateContextAtrribsARB, true);
+ return;
}
}
@@ -2669,6 +2721,7 @@ glXReleaseTexImageEXT(Display *dpy, GLXDrawable drawable,
int buffer)
/*** GLX_ARB_create_context ***/
+
GLXContext
glXCreateContextAttribsARB(Display *dpy, GLXFBConfig config,
GLXContext shareCtx, Bool direct,
@@ -2683,6 +2736,7 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig
config,
Bool done = False;
const int contextFlagsAll = (GLX_CONTEXT_DEBUG_BIT_ARB |
GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB);
+ GLXContext ctx;
/* parse attrib_list */
for (i = 0; !done attrib_list attrib_list[i]; i++) {
@@ -2708,37 +2762,76 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig
config,
break;
default:
/* bad attribute */
- /* XXX generate BadValue X Error */
+ generate_error(dpy, BadValue, 0, X_GLXCreateContextAtrribsARB, True);
return NULL;
}
}
/* check contextFlags */
if (contextFlags ~contextFlagsAll) {
- return NULL; /* generate BadValue X Error */
+ generate_error(dpy, BadValue, 0, X_GLXCreateContextAtrribsARB, True);
+ return NULL;
}
/* check profileMask */
if (profileMask != GLX_CONTEXT_CORE_PROFILE_BIT_ARB
profileMask != GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB
profileMask != GLX_CONTEXT_ES_PROFILE_BIT_EXT) {
- return NULL; /* generate BadValue X Error */
+ generate_error(dpy, GLXBadProfileARB, 0, X_GLXCreateContextAtrribsARB,
False);
+ return NULL;
+ }
+
+ /* check renderType */
+ if (renderType != GLX_RGBA_TYPE
+ renderType != GLX_COLOR_INDEX_TYPE) {
+ generate_error(dpy, BadValue, 0, X_GLXCreateContextAtrribsARB, True);
+ return NULL;
}
- /* check version (generate BadMatch if bad) */
- if (majorVersion 0 || minorVersion 0)
+ /* check version */
+ if (majorVersion = 0 ||
+ minorVersion 0 ||
+ (profileMask != GLX_CONTEXT_ES_PROFILE_BIT_EXT
+((majorVersion == 1 minorVersion 5) ||
+ (majorVersion == 2 minorVersion 1) ||
+ (majorVersion == 3 minorVersion 3) ||
+ (majorVersion == 4 minorVersion 5) ||
+ majorVersion 4))) {
+ generate_error(dpy, BadMatch, 0, X_GLXCreateContextAtrribsARB, True);
return NULL;
+ }
+ if (profileMask == GLX_CONTEXT_ES_PROFILE_BIT_EXT
+
[Mesa-dev] [PATCH 2/2] st/wgl: Implement WGL_EXT_create_context_es/es2_profile.
From: José Fonseca jfons...@vmware.com
Derived from st/glx's GLX_EXT_create_context_es/es2_profile implementation.
Tested with an OpenGL ES 2.0 ApiTrace.
---
src/gallium/state_trackers/wgl/stw_context.c | 74 +-
src/gallium/state_trackers/wgl/stw_ext_context.c | 65 +--
.../state_trackers/wgl/stw_ext_extensionsstring.c | 2 +
3 files changed, 78 insertions(+), 63 deletions(-)
diff --git a/src/gallium/state_trackers/wgl/stw_context.c
b/src/gallium/state_trackers/wgl/stw_context.c
index 99debfd..2ed6c2bf 100644
--- a/src/gallium/state_trackers/wgl/stw_context.c
+++ b/src/gallium/state_trackers/wgl/stw_context.c
@@ -201,35 +201,51 @@ stw_create_context_attribs(HDC hdc, INT iLayerPlane,
DHGLRC hShareContext,
if (contextFlags WGL_CONTEXT_DEBUG_BIT_ARB)
attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
- /* There are no profiles before OpenGL 3.2. The
-* WGL_ARB_create_context_profile spec says:
-*
-* If the requested OpenGL version is less than 3.2,
-* WGL_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality of the
-* context is determined solely by the requested version.
-*
-* The spec also says:
-*
-* The default value for WGL_CONTEXT_PROFILE_MASK_ARB is
-* WGL_CONTEXT_CORE_PROFILE_BIT_ARB.
-*
-* The spec also says:
-*
-* If version 3.1 is requested, the context returned may implement
-* any of the following versions:
-*
-* * Version 3.1. The GL_ARB_compatibility extension may or may not
-* be implemented, as determined by the implementation.
-* * The core profile of version 3.2 or greater.
-*
-* and because Mesa doesn't support GL_ARB_compatibility, the only chance to
-* honour a 3.1 context is through core profile.
-*/
- attribs.profile = ST_PROFILE_DEFAULT;
- if (((majorVersion 3 || (majorVersion == 3 minorVersion = 2))
- ((profileMask WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB) == 0)) ||
- (majorVersion == 3 minorVersion == 1))
- attribs.profile = ST_PROFILE_OPENGL_CORE;
+ switch (profileMask) {
+ case WGL_CONTEXT_CORE_PROFILE_BIT_ARB:
+ /* There are no profiles before OpenGL 3.2. The
+ * WGL_ARB_create_context_profile spec says:
+ *
+ * If the requested OpenGL version is less than 3.2,
+ * WGL_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
+ * of the context is determined solely by the requested version.
+ */
+ if (majorVersion 3 || (majorVersion == 3 minorVersion = 2)) {
+ attribs.profile = ST_PROFILE_OPENGL_CORE;
+ break;
+ }
+ /* fall-through */
+ case WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
+ /*
+ * The spec also says:
+ *
+ * If version 3.1 is requested, the context returned may implement
+ * any of the following versions:
+ *
+ * * Version 3.1. The GL_ARB_compatibility extension may or may not
+ * be implemented, as determined by the implementation.
+ * * The core profile of version 3.2 or greater.
+ *
+ * and because Mesa doesn't support GL_ARB_compatibility, the only
chance to
+ * honour a 3.1 context is through core profile.
+ */
+ if (majorVersion == 3 minorVersion == 1) {
+ attribs.profile = ST_PROFILE_OPENGL_CORE;
+ } else {
+ attribs.profile = ST_PROFILE_DEFAULT;
+ }
+ break;
+ case WGL_CONTEXT_ES_PROFILE_BIT_EXT:
+ if (majorVersion = 2) {
+ attribs.profile = ST_PROFILE_OPENGL_ES2;
+ } else {
+ attribs.profile = ST_PROFILE_OPENGL_ES1;
+ }
+ break;
+ default:
+ assert(0);
+ goto no_st_ctx;
+ }
ctx-st = stw_dev-stapi-create_context(stw_dev-stapi,
stw_dev-smapi, attribs, ctx_err, shareCtx ? shareCtx-st : NULL);
diff --git a/src/gallium/state_trackers/wgl/stw_ext_context.c
b/src/gallium/state_trackers/wgl/stw_ext_context.c
index 451f330..8a96cac 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_context.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_context.c
@@ -62,6 +62,8 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
int profileMask = WGL_CONTEXT_CORE_PROFILE_BIT_ARB;
int i;
BOOL done = FALSE;
+ const int contextFlagsAll = (WGL_CONTEXT_DEBUG_BIT_ARB |
+WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB);
/* parse attrib_list */
if (attribList) {
@@ -94,34 +96,36 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
}
}
+ /* check contextFlags */
+ if (contextFlags ~contextFlagsAll) {
+ SetLastError(ERROR_INVALID_PARAMETER);
+ return NULL;
+ }
+
+ /* check profileMask */
+ if (profileMask != WGL_CONTEXT_CORE_PROFILE_BIT_ARB
+ profileMask != WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB
+ profileMask
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 17:37, Ilia Mirkin imir...@alum.mit.edu wrote: Dave Airlie's virgl work is creating a gallium driver which actually uses OpenGL for hardware. I'm not sure how far he is, but I believe he has enough for GL3. This could be a way forward towards *only* using gallium (since otherwise you'd still have to have an OpenGL-based backend for the hw/platforms that don't have gallium drivers). However gallium will never support fixed-function hardware, so that may still not work for you. Fixed-function hardware is becoming less and less relevant, but on the other hand we try to avoid breaking things that currently work. But yes, that's certainly something that's interesting to see how it turns out. Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. While I don't have this justification, I always just assumed this was due to mismatches between how d3d wanted to do things and how OpenGL let you do things, so you ended up having to do some fairly heavy-handed things in OpenGL solely due to the silliness of the API. Well yes, but the issues tend to be things like those solved by ARB_clip_control, ARB_vertex_array_bgra, ARB_provoking_vertex, etc. Let's say that all such things could be identified and extensions created for, you'd still end up effectively managing 2 backends -- one that assumes that the various d3d-helper extensions are there, and one that doesn't. Yes, but that's much more limited in scope than replacing all of OpenGL. I strongly doubt that the performance increases are due to better d3d9 bytecode - TGSI conversion than - glsl - tgsi conversion -- most serious backends (r600, radeonsi, nouveau) have optimizing compilers that should take care of such issues. It was just an example, but at least in the past I've seen for example the translation for D3D cnd and cmp result in pretty sub-optimal code in r600g. In GLSL 1.30 and up mix() with a bool argument could perhaps make it easier for the driver to end up with something reasonable. But not knowing where the actual differences/advantages are is a large part of what makes it hard to discuss st/nine in concrete terms from a Wine perspective. Anyways, from your comments it sounds like the only way forward and given the current capabilities of nine/st would be to create some sort of out-of-tree solution that plugs into wine, providing native d3d9.dll or whatever it's called. That way you guys aren't stuck maintaining 2 backends, and people can get improved performance on d3d9 games on linux. Henri, if you take the fact that people want to use nine/st in its ~current form on linux as a given, is there a different, simpler approach that I'm overlooking? Probably not. For what it's worth, while I think the approach of doing the analysis mentioned above will ultimately have better results both for Wine and other GL applications, I realise very well that that's real work and not necessarily a lot of fun. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 17:42, Jose Fonseca jfons...@vmware.com wrote: [...] We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. Yes, I don't recommend gallium for that. It sounds you want to design a WINE D3D9 DDI pretty much along the lines of the WDDM D3D9 DDI: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552927(v=vs.85).aspx Basically, the runtime is one, but there would be two implementations of that DDI. Runtime would do validation, keep copy of current state for application state queries, etc. Yeah, essentially. In a way we already have that kind of interface, but it's wined3d internal instead of a proper API. And of course we'll want d3d10/11 as well at some point. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] dri/kms: Always zero out struct drm_mode_create_dumb
On Thu, Nov 13, 2014 at 07:05:51PM +0100, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com The DRM_IOCTL_MODE_CREATE_DUMB (and others) IOCTL isn't very rigorously specified, which has the effect that some kernel drivers do not consider the .pitch and .size fields of struct drm_mode_create_dumb outputs only. Instead they will use these as lower bounds and overwrite them only if the values that they compute are larger than what userspace provided. This works if and only if userspace initializes the fields explicitly to either 0 or some meaningful value. However, if userspace just leaves the values uninitialized and the struct drm_mode_create_dumb is allocated on the stack for example, the driver may try to overallocate buffers. Fortunately most userspace does zero out the structure before passing it to the IOCTL, but there are rare exceptions. Mesa is one of them. In an attempt to rectify this situation, kernel drivers are being updated to not use the .pitch and .size fields as inputs. However in order to fix the issue with older kernels, make sure that Mesa always zeros out the structure as well. Future IOCTLs should be more rigorously defined so that structures can be validated and IOCTLs rejected if output fields aren't set to zero. Signed-off-by: Thierry Reding tred...@nvidia.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c | 2 +- src/gbm/backends/dri/gbm_dri.c| 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c index ee71027c5872..507983ec251a 100644 --- a/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c +++ b/src/gallium/winsys/sw/kms-dri/kms_dri_sw_winsys.c @@ -131,10 +131,10 @@ kms_sw_displaytarget_create(struct sw_winsys *ws, kms_sw_dt-width = width; kms_sw_dt-height = height; + memset(create_req, 0, sizeof(create_req)); create_req.bpp = 32; create_req.width = width; create_req.height = height; - create_req.handle = 0; ret = drmIoctl(kms_sw-fd, DRM_IOCTL_MODE_CREATE_DUMB, create_req); if (ret) goto free_bo; diff --git a/src/gbm/backends/dri/gbm_dri.c b/src/gbm/backends/dri/gbm_dri.c index 470a54f3dd89..bc263297ec33 100644 --- a/src/gbm/backends/dri/gbm_dri.c +++ b/src/gbm/backends/dri/gbm_dri.c @@ -774,6 +774,7 @@ create_dumb(struct gbm_device *gbm, if (bo == NULL) return NULL; + memset(create_arg, 0, sizeof(create_arg)); create_arg.bpp = 32; create_arg.width = width; create_arg.height = height; -- 2.1.3 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 14 November 2014 17:52, Axel Davy axel.d...@ens.fr wrote: Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL. As for me, I contributed only since a few months ago, and was able to implement a lot of things quite easily, for exemple: . Respect the number of backbuffer asked by the app (as far as I know wine doesn't support = 2 and behaves like 1) . Support the Render-ahead d3d9 behaviour (d3d9 doesn't have tripple buffering like Opengl can have) . wine seems to have a lot of issues with stuttering, etc. We have control of throttling and vsync, and thus don't have any particular issue there Most of the stuttering I'm aware of is GLSL compiler related. . We have very good DRI_PRIME support (better than what GLX has currently). The fact that nine was develloped so fast by few devs show well that it was easier. I don't want to sound overly negative, but I'm afraid that what you're seeing is mostly just the first 80% of any project being a lot easier than the last 1% or so. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
Le 14/11/2014 18:40, Henri Verbeet a écrit : On 14 November 2014 17:52, Axel Davy axel.d...@ens.fr wrote: Second d3d9 as gallium state tracker seems much easier than d3d9 on OpenGL. As for me, I contributed only since a few months ago, and was able to implement a lot of things quite easily, for exemple: . Respect the number of backbuffer asked by the app (as far as I know wine doesn't support = 2 and behaves like 1) . Support the Render-ahead d3d9 behaviour (d3d9 doesn't have tripple buffering like Opengl can have) . wine seems to have a lot of issues with stuttering, etc. We have control of throttling and vsync, and thus don't have any particular issue there Most of the stuttering I'm aware of is GLSL compiler related. As far as I have seen with our logs, games generally compile shaders during game load, but then are done with it. Do you mean you compile them again and again ? . We have very good DRI_PRIME support (better than what GLX has currently). The fact that nine was develloped so fast by few devs show well that it was easier. I don't want to sound overly negative, but I'm afraid that what you're seeing is mostly just the first 80% of any project being a lot easier than the last 1% or so. I'm not expert, but I think we have sufficiently complex apps working perfectly to say we are more than 80% and near wine state (again, wine has some bugs we haven't, and nine has some bugs wine doesn't have, but that seems easier to solve). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] aux/pipe_loader: Don't leak error string on dlopen failure
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v4: Call dlerror() twice instead of freeing glibc's memory.
Prevents issues on C Libraries that don't malloc the error string.
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..f103497 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,10 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ /* Retrieve the dlerror() str twice. Once to populate the error,
twice to clear it. */
+dlerror();
+dlerror();
}
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Suboptimal code generation
[changing subjects not to derail original discussion] On Fri, Nov 14, 2014 at 12:25 PM, Henri Verbeet hverb...@gmail.com wrote: I strongly doubt that the performance increases are due to better d3d9 bytecode - TGSI conversion than - glsl - tgsi conversion -- most serious backends (r600, radeonsi, nouveau) have optimizing compilers that should take care of such issues. It was just an example, but at least in the past I've seen for example the translation for D3D cnd and cmp result in pretty sub-optimal code in r600g. In GLSL 1.30 and up mix() with a bool argument could perhaps make it easier for the driver to end up with something reasonable. But I can't speak for the radeon guys, but I know I sure would love to see any reports of poor code being generated by nouveau in response to legitimate-seeming TGSI (or GLSL). In some cases, a simple optimization can be added to take care of it, and I'd definitely appreciate the extra pair of eyeballs on driver-generated code :) The report can be as simple as here is the TGSI snippet, take a look at how crappy the code it generates is. At least for nouveau, I can feed that directly into a compiler that can target any of the relevant backends. [Note, r600g didn't have an optimizer enabled until ~1y ago; not sure if your analysis was with or without sb.] Cheers, -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] aux/pipe_loader: Don't leak error string on dlopen failure
On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry awa...@gmail.com wrote:
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v4: Call dlerror() twice instead of freeing glibc's memory.
Prevents issues on C Libraries that don't malloc the error string.
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..f103497 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,10 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ /* Retrieve the dlerror() str twice. Once to populate the error,
twice to clear it. */
+dlerror();
+dlerror();
Is this portable? Perhaps just if PIPE_OS_UNIX or something? (For the
include as well...)
I could be wrong on that though. But please check :)
}
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/wgl: Implement WGL_EXT_create_context_es/es2_profile.
Just one minor comment below. Otherwise looks fine.
Reviewed-by: Brian Paul bri...@vmware.com
On 11/14/2014 10:20 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Derived from st/glx's GLX_EXT_create_context_es/es2_profile implementation.
Tested with an OpenGL ES 2.0 ApiTrace.
---
src/gallium/state_trackers/wgl/stw_context.c | 74 +-
src/gallium/state_trackers/wgl/stw_ext_context.c | 65 +--
.../state_trackers/wgl/stw_ext_extensionsstring.c | 2 +
3 files changed, 78 insertions(+), 63 deletions(-)
diff --git a/src/gallium/state_trackers/wgl/stw_context.c
b/src/gallium/state_trackers/wgl/stw_context.c
index 99debfd..2ed6c2bf 100644
--- a/src/gallium/state_trackers/wgl/stw_context.c
+++ b/src/gallium/state_trackers/wgl/stw_context.c
@@ -201,35 +201,51 @@ stw_create_context_attribs(HDC hdc, INT iLayerPlane,
DHGLRC hShareContext,
if (contextFlags WGL_CONTEXT_DEBUG_BIT_ARB)
attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
- /* There are no profiles before OpenGL 3.2. The
-* WGL_ARB_create_context_profile spec says:
-*
-* If the requested OpenGL version is less than 3.2,
-* WGL_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality of the
-* context is determined solely by the requested version.
-*
-* The spec also says:
-*
-* The default value for WGL_CONTEXT_PROFILE_MASK_ARB is
-* WGL_CONTEXT_CORE_PROFILE_BIT_ARB.
-*
-* The spec also says:
-*
-* If version 3.1 is requested, the context returned may implement
-* any of the following versions:
-*
-* * Version 3.1. The GL_ARB_compatibility extension may or may not
-* be implemented, as determined by the implementation.
-* * The core profile of version 3.2 or greater.
-*
-* and because Mesa doesn't support GL_ARB_compatibility, the only chance to
-* honour a 3.1 context is through core profile.
-*/
- attribs.profile = ST_PROFILE_DEFAULT;
- if (((majorVersion 3 || (majorVersion == 3 minorVersion = 2))
- ((profileMask WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB) == 0)) ||
- (majorVersion == 3 minorVersion == 1))
- attribs.profile = ST_PROFILE_OPENGL_CORE;
+ switch (profileMask) {
+ case WGL_CONTEXT_CORE_PROFILE_BIT_ARB:
+ /* There are no profiles before OpenGL 3.2. The
+ * WGL_ARB_create_context_profile spec says:
+ *
+ * If the requested OpenGL version is less than 3.2,
+ * WGL_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
+ * of the context is determined solely by the requested version.
+ */
+ if (majorVersion 3 || (majorVersion == 3 minorVersion = 2)) {
+ attribs.profile = ST_PROFILE_OPENGL_CORE;
+ break;
+ }
+ /* fall-through */
+ case WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
+ /*
+ * The spec also says:
+ *
+ * If version 3.1 is requested, the context returned may implement
+ * any of the following versions:
+ *
+ * * Version 3.1. The GL_ARB_compatibility extension may or may not
+ * be implemented, as determined by the implementation.
+ * * The core profile of version 3.2 or greater.
+ *
+ * and because Mesa doesn't support GL_ARB_compatibility, the only
chance to
+ * honour a 3.1 context is through core profile.
+ */
+ if (majorVersion == 3 minorVersion == 1) {
+ attribs.profile = ST_PROFILE_OPENGL_CORE;
+ } else {
+ attribs.profile = ST_PROFILE_DEFAULT;
+ }
+ break;
+ case WGL_CONTEXT_ES_PROFILE_BIT_EXT:
+ if (majorVersion = 2) {
+ attribs.profile = ST_PROFILE_OPENGL_ES2;
+ } else {
+ attribs.profile = ST_PROFILE_OPENGL_ES1;
+ }
+ break;
+ default:
+ assert(0);
+ goto no_st_ctx;
+ }
ctx-st = stw_dev-stapi-create_context(stw_dev-stapi,
stw_dev-smapi, attribs, ctx_err, shareCtx ? shareCtx-st : NULL);
diff --git a/src/gallium/state_trackers/wgl/stw_ext_context.c
b/src/gallium/state_trackers/wgl/stw_ext_context.c
index 451f330..8a96cac 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_context.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_context.c
@@ -62,6 +62,8 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
int profileMask = WGL_CONTEXT_CORE_PROFILE_BIT_ARB;
int i;
BOOL done = FALSE;
+ const int contextFlagsAll = (WGL_CONTEXT_DEBUG_BIT_ARB |
+WGL_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB);
/* parse attrib_list */
if (attribList) {
@@ -94,34 +96,36 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
}
}
+ /* check contextFlags */
+ if (contextFlags ~contextFlagsAll) {
+ SetLastError(ERROR_INVALID_PARAMETER);
+ return NULL;
+ }
+
+ /*
[Mesa-dev] [PATCH] mesa: Fix _mesa_uint_array_min_max linker error.
Fixes build process failure when providing -mno-sse4.1 CFLAGS:
vbo_exec_array.c:(.text+0x9bb): undefined reference to
`_mesa_uint_array_min_max'
Similar bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71547
---
src/mesa/vbo/vbo_exec_array.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index e623b36..6362dd4 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -121,12 +121,14 @@ vbo_get_minmax_index(struct gl_context *ctx,
}
}
else {
+#ifdef __SSE4_1__
#if defined(USE_SSE41)
if (cpu_has_sse4_1) {
_mesa_uint_array_min_max(ui_indices, min_ui, max_ui, count);
}
else
#endif
+#endif
for (i = 0; i count; i++) {
if (ui_indices[i] max_ui) max_ui = ui_indices[i];
if (ui_indices[i] min_ui) min_ui = ui_indices[i];
--
2.1.3
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] aux/pipe_loader: Don't leak error string on dlopen failure
On Fri, Nov 14, 2014 at 12:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry awa...@gmail.com wrote:
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v4: Call dlerror() twice instead of freeing glibc's memory.
Prevents issues on C Libraries that don't malloc the error string.
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..f103497 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,10 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ /* Retrieve the dlerror() str twice. Once to populate the error,
twice to clear it. */
+dlerror();
+dlerror();
Is this portable? Perhaps just if PIPE_OS_UNIX or something? (For the
include as well...)
I could be wrong on that though. But please check :)
How about changing dlerror to util_dl_error? It takes care of the
os-portability issues.
--Aaron
}
}
--
2.1.0
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] aux/pipe_loader: Don't leak error string on dlopen failure
On Fri, Nov 14, 2014 at 1:31 PM, Aaron Watry awa...@gmail.com wrote:
On Fri, Nov 14, 2014 at 12:04 PM, Ilia Mirkin imir...@alum.mit.edu wrote:
On Fri, Nov 14, 2014 at 12:48 PM, Aaron Watry awa...@gmail.com wrote:
Signed-off-by: Aaron Watry awa...@gmail.com
CC: Ilia Mirkin imir...@alum.mit.edu
v4: Call dlerror() twice instead of freeing glibc's memory.
Prevents issues on C Libraries that don't malloc the error string.
v3: Switch comment to C-Style
v2: Use strdup instead of calloc/strcpy
---
src/gallium/auxiliary/pipe-loader/pipe_loader.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
index 8e79f85..f103497 100644
--- a/src/gallium/auxiliary/pipe-loader/pipe_loader.c
+++ b/src/gallium/auxiliary/pipe-loader/pipe_loader.c
@@ -25,6 +25,8 @@
*
**/
+#include dlfcn.h
+
#include pipe_loader_priv.h
#include util/u_inlines.h
@@ -101,6 +103,10 @@ pipe_loader_find_module(struct pipe_loader_device *dev,
if (lib) {
return lib;
}
+
+ /* Retrieve the dlerror() str twice. Once to populate the error,
twice to clear it. */
+dlerror();
+dlerror();
Is this portable? Perhaps just if PIPE_OS_UNIX or something? (For the
include as well...)
I could be wrong on that though. But please check :)
How about changing dlerror to util_dl_error? It takes care of the
os-portability issues.
Even better.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH V2] mesa: Permanently enable features supported by target CPU at compile time.
On 11/10/2014 04:28 AM, Emil Velikov wrote: On 09/11/14 04:37, Siavash Eliasi wrote: On 11/08/2014 09:55 PM, Emil Velikov wrote: [...] Can you confirm that it does not cause issues with interesting setups such as https://bugs.freedesktop.org/show_bug.cgi?id=71547 Challenge accepted! What my patch is doing is to check for provided compile flags (-msse, ...) on compile time (__SSE__, ...) and set cpu_has_sse macro to 1 which allows any sane compiler to turn this pieces of code: I'm not sure did you just said that you've checked it, or that's what it ought to do ? There is a reason why I'm so picky - this bizarre (as one might call it) setup is just the tip of the iceberg when it comes to people building mesa themselves. Would be nice to get your patch in as long as it does not break stuff :) -Emil I tried building with same CFLAGS in that bug report, no build failures; ofcourse after applying this patch: http://patchwork.freedesktop.org/patch/36869/ Best regards, Siavash Eliasi. Best regards, Siavash Eliasi. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On Friday, November 14, 2014 02:39:24 PM Emil Velikov wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. The plan is to still keep the branch point later on today, but to push the tag on Monday. Thanks Emil Using .99.9xx seems fine by me, but I don't have a strong preference either way. However, it would be great if we could be consistent about using '.0' on the first release in a new series. For example: ftp://ftp.freedesktop.org/pub/mesa/10.3/MesaLib-10.3.0.tar.gz the tarball is named 10.3.0 but the directory is called 10.3 (and only contains 10.3.0 and RCs - stable releases go in directories called 10.3.1, etc.) glxinfo uses 10.3.0: OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.0 (git-1b12af3) but the tag is called mesa-10.3, not mesa-10.3.0. I believe that consistently using the .0 would making life a little easier for packagers. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Suboptimal code generation
On 14 November 2014 18:50, Ilia Mirkin imir...@alum.mit.edu wrote: I can't speak for the radeon guys, but I know I sure would love to see any reports of poor code being generated by nouveau in response to legitimate-seeming TGSI (or GLSL). In some cases, a simple optimization can be added to take care of it, and I'd definitely appreciate the extra pair of eyeballs on driver-generated code :) The report can be as simple as here is the TGSI snippet, take a look at how crappy the code it generates is. At least for nouveau, I can feed that directly into a compiler that can target any of the relevant backends. [Note, r600g didn't have an optimizer enabled until ~1y ago; not sure if your analysis was with or without sb.] It was with sb, but probably before TGSI got FSLT/FSGE/etc. For reference, what currently happens for r600g is something like this: D3D: cnd r[0], r[0].w, c[1], c[2] GLSL: R0.xyzw = (R0.w 0.5 ? ps_c[1].xyzw : ps_c[2].xyzw); TGSI: FSLT TEMP[0].x, IMM[0]., TEMP[0]. UIF TEMP[0]. :0 MOV TEMP[0], CONST[1] ELSE :0 MOV TEMP[0], CONST[2] ENDIF R600: SETGE_DX10 T0.x, 0.5, T0.x CNDE_INT R0.x, T0.x, KC0[1].x, KC0[2].x CNDE_INT R0.y, T0.x, KC0[1].y, KC0[2].y CNDE_INT R0.z, T0.x, KC0[1].z, KC0[2].z CNDE_INT R0.w, T0.x, KC0[1].w, KC0[2].w While ideally that would just be 4 CNDGE's, that's better than what I remember. IIRC there used to be a bunch of int/float conversions as well. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Fix _mesa_uint_array_min_max linker error.
And disables the optimization unless you're building with a -march
that has sse4.1... thus defeating the purpose of doing it this way.
On Fri, Nov 14, 2014 at 1:23 PM, Siavash Eliasi siavashser...@gmail.com wrote:
Fixes build process failure when providing -mno-sse4.1 CFLAGS:
vbo_exec_array.c:(.text+0x9bb): undefined reference to
`_mesa_uint_array_min_max'
Similar bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71547
---
src/mesa/vbo/vbo_exec_array.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index e623b36..6362dd4 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -121,12 +121,14 @@ vbo_get_minmax_index(struct gl_context *ctx,
}
}
else {
+#ifdef __SSE4_1__
#if defined(USE_SSE41)
if (cpu_has_sse4_1) {
_mesa_uint_array_min_max(ui_indices, min_ui, max_ui, count);
}
else
#endif
+#endif
for (i = 0; i count; i++) {
if (ui_indices[i] max_ui) max_ui = ui_indices[i];
if (ui_indices[i] min_ui) min_ui = ui_indices[i];
--
2.1.3
___
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] [PATCH] mesa: Fix _mesa_uint_array_min_max linker error.
You are right. Any suggestions on how to fix this build failure?
On 11/14/2014 10:10 PM, Ilia Mirkin wrote:
And disables the optimization unless you're building with a -march
that has sse4.1... thus defeating the purpose of doing it this way.
On Fri, Nov 14, 2014 at 1:23 PM, Siavash Eliasi siavashser...@gmail.com wrote:
Fixes build process failure when providing -mno-sse4.1 CFLAGS:
vbo_exec_array.c:(.text+0x9bb): undefined reference to
`_mesa_uint_array_min_max'
Similar bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71547
---
src/mesa/vbo/vbo_exec_array.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index e623b36..6362dd4 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -121,12 +121,14 @@ vbo_get_minmax_index(struct gl_context *ctx,
}
}
else {
+#ifdef __SSE4_1__
#if defined(USE_SSE41)
if (cpu_has_sse4_1) {
_mesa_uint_array_min_max(ui_indices, min_ui, max_ui, count);
}
else
#endif
+#endif
for (i = 0; i count; i++) {
if (ui_indices[i] max_ui) max_ui = ui_indices[i];
if (ui_indices[i] min_ui) min_ui = ui_indices[i];
--
2.1.3
___
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] [PATCH] i965: Don't call _mesa_load_state_parameters when nr_params == 0.
On Thu, Nov 13, 2014 at 11:22 PM, Kenneth Graunke kenn...@whitecape.org wrote:
Saves a tiny bit of CPU overhead.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
---
src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 10 +-
src/mesa/drivers/dri/i965/gen6_vs_state.c| 12 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
b/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
index 1cc96cf..4e18c7d 100644
--- a/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
+++ b/src/mesa/drivers/dri/i965/brw_vs_surface_state.c
@@ -59,11 +59,6 @@ brw_upload_pull_constants(struct brw_context *brw,
int i;
uint32_t surf_index = prog_data-binding_table.pull_constants_start;
- /* Updates the ParamaterValues[i] pointers for all parameters of the
-* basic type of PROGRAM_STATE_VAR.
-*/
- _mesa_load_state_parameters(brw-ctx, prog-Parameters);
-
if (!prog_data-nr_pull_params) {
This check is different from the one below and what the commit summary says.
Assuming that's what you expected
Reviewed-by: Matt Turner matts...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/wgl: Implement WGL_EXT_create_context_es/es2_profile.
Thanks for the review.
I'd probably put the version checking logic into a helper function, but
not a big deal.
Good idea. I'll do that in a follow on patch.
It looks like we're not doing as extensive version checking in the glx code.
It's actually the same amount of checking. But on GLX we somehow need to return
a different error for ES profiles to make piglit happy.
Jose
From: Brian Paul bri...@vmware.com
Sent: 14 November 2014 18:20
To: Jose Fonseca; mesa-dev@lists.freedesktop.org
Subject: Re: [PATCH 2/2] st/wgl: Implement
WGL_EXT_create_context_es/es2_profile.
Just one minor comment below. Otherwise looks fine.
Reviewed-by: Brian Paul bri...@vmware.com
On 11/14/2014 10:20 AM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
Derived from st/glx's GLX_EXT_create_context_es/es2_profile implementation.
Tested with an OpenGL ES 2.0 ApiTrace.
---
src/gallium/state_trackers/wgl/stw_context.c | 74
+-
src/gallium/state_trackers/wgl/stw_ext_context.c | 65 +--
.../state_trackers/wgl/stw_ext_extensionsstring.c | 2 +
3 files changed, 78 insertions(+), 63 deletions(-)
diff --git a/src/gallium/state_trackers/wgl/stw_context.c
b/src/gallium/state_trackers/wgl/stw_context.c
index 99debfd..2ed6c2bf 100644
--- a/src/gallium/state_trackers/wgl/stw_context.c
+++ b/src/gallium/state_trackers/wgl/stw_context.c
@@ -201,35 +201,51 @@ stw_create_context_attribs(HDC hdc, INT iLayerPlane,
DHGLRC hShareContext,
if (contextFlags WGL_CONTEXT_DEBUG_BIT_ARB)
attribs.flags |= ST_CONTEXT_FLAG_DEBUG;
- /* There are no profiles before OpenGL 3.2. The
-* WGL_ARB_create_context_profile spec says:
-*
-* If the requested OpenGL version is less than 3.2,
-* WGL_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality of
the
-* context is determined solely by the requested version.
-*
-* The spec also says:
-*
-* The default value for WGL_CONTEXT_PROFILE_MASK_ARB is
-* WGL_CONTEXT_CORE_PROFILE_BIT_ARB.
-*
-* The spec also says:
-*
-* If version 3.1 is requested, the context returned may implement
-* any of the following versions:
-*
-* * Version 3.1. The GL_ARB_compatibility extension may or may not
-* be implemented, as determined by the implementation.
-* * The core profile of version 3.2 or greater.
-*
-* and because Mesa doesn't support GL_ARB_compatibility, the only chance
to
-* honour a 3.1 context is through core profile.
-*/
- attribs.profile = ST_PROFILE_DEFAULT;
- if (((majorVersion 3 || (majorVersion == 3 minorVersion = 2))
- ((profileMask WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB) == 0))
||
- (majorVersion == 3 minorVersion == 1))
- attribs.profile = ST_PROFILE_OPENGL_CORE;
+ switch (profileMask) {
+ case WGL_CONTEXT_CORE_PROFILE_BIT_ARB:
+ /* There are no profiles before OpenGL 3.2. The
+ * WGL_ARB_create_context_profile spec says:
+ *
+ * If the requested OpenGL version is less than 3.2,
+ * WGL_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
+ * of the context is determined solely by the requested version.
+ */
+ if (majorVersion 3 || (majorVersion == 3 minorVersion = 2)) {
+ attribs.profile = ST_PROFILE_OPENGL_CORE;
+ break;
+ }
+ /* fall-through */
+ case WGL_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB:
+ /*
+ * The spec also says:
+ *
+ * If version 3.1 is requested, the context returned may implement
+ * any of the following versions:
+ *
+ * * Version 3.1. The GL_ARB_compatibility extension may or may
not
+ * be implemented, as determined by the implementation.
+ * * The core profile of version 3.2 or greater.
+ *
+ * and because Mesa doesn't support GL_ARB_compatibility, the only
chance to
+ * honour a 3.1 context is through core profile.
+ */
+ if (majorVersion == 3 minorVersion == 1) {
+ attribs.profile = ST_PROFILE_OPENGL_CORE;
+ } else {
+ attribs.profile = ST_PROFILE_DEFAULT;
+ }
+ break;
+ case WGL_CONTEXT_ES_PROFILE_BIT_EXT:
+ if (majorVersion = 2) {
+ attribs.profile = ST_PROFILE_OPENGL_ES2;
+ } else {
+ attribs.profile = ST_PROFILE_OPENGL_ES1;
+ }
+ break;
+ default:
+ assert(0);
+ goto no_st_ctx;
+ }
ctx-st = stw_dev-stapi-create_context(stw_dev-stapi,
stw_dev-smapi, attribs, ctx_err, shareCtx ? shareCtx-st :
NULL);
diff --git a/src/gallium/state_trackers/wgl/stw_ext_context.c
b/src/gallium/state_trackers/wgl/stw_ext_context.c
index 451f330..8a96cac 100644
---
Re: [Mesa-dev] How difficult would it be to have debugging information for Jitted code show up?
This issue isn't totally just that. LIBGL_ALWAYS_SOFTWARE=true mode does use LLVM doesn't it? And I find profiling information trailing from a perf-foo.map file that seems to correspond to JITted code. So, I think this is still valid for LIBGL_ALWAYS_SOFTWARE=true mode. I was mistaken for unset LIBGL_ALWAYS_SOFTWARE though I think. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How difficult would it be to have debugging information for Jitted code show up?
And I find profiling information trailing from a perf-foo.map file that seems to correspond to JITted code. Yep. That sounds like llmvpipe. See http://mesa3d.org/llvmpipe.html for details. But note that have source lines for jit code is hard: - Some of the LLVM IR we generate comes from TGSI which has no source line info. We could have the info from the GLSL, but that has no source files. . - Some of TGSI doesn't come from GLSL, but rather fixed function. - Some of the LLVM IR doesn't even come from TGSI or any shaders, but its bound state like depth-stencil test, or format conversion. None of that IR has source files. We could use the debug info from the C code that generates the LLVM IR that generates the . In short, we could try to improve things a bit, but JIT code will always be quite different from static C code. Jose From: mesa-dev mesa-dev-boun...@lists.freedesktop.org on behalf of Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca Sent: 14 November 2014 19:23 To: Emil Velikov Cc: ML mesa-dev Subject: Re: [Mesa-dev] How difficult would it be to have debugging information for Jitted code show up? This issue isn't totally just that. LIBGL_ALWAYS_SOFTWARE=true mode does use LLVM doesn't it? And I find profiling information trailing from a perf-foo.map file that seems to correspond to JITted code. So, I think this is still valid for LIBGL_ALWAYS_SOFTWARE=true mode. I was mistaken for unset LIBGL_ALWAYS_SOFTWARE though I think. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddevd=AAIGaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzEm=IVw7I-5WEvdqar1LGKpNSi56XoZMlsmzcc5IKTLmvYAs=iCS5PuoCjw1nnf0AgSWX0cNGwCa1NET5erjzE8lrX8Ue= ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/wgl: Implement WGL_EXT_create_context_es/es2_profile.
On 11/14/2014 12:13 PM, Jose Fonseca wrote: Thanks for the review. I'd probably put the version checking logic into a helper function, but not a big deal. Good idea. I'll do that in a follow on patch. It looks like we're not doing as extensive version checking in the glx code. It's actually the same amount of checking. But on GLX we somehow need to return a different error for ES profiles to make piglit happy. Ah right, I was looking at the unpatched code. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Suboptimal code generation
On Fri, Nov 14, 2014 at 1:38 PM, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 18:50, Ilia Mirkin imir...@alum.mit.edu wrote: I can't speak for the radeon guys, but I know I sure would love to see any reports of poor code being generated by nouveau in response to legitimate-seeming TGSI (or GLSL). In some cases, a simple optimization can be added to take care of it, and I'd definitely appreciate the extra pair of eyeballs on driver-generated code :) The report can be as simple as here is the TGSI snippet, take a look at how crappy the code it generates is. At least for nouveau, I can feed that directly into a compiler that can target any of the relevant backends. [Note, r600g didn't have an optimizer enabled until ~1y ago; not sure if your analysis was with or without sb.] It was with sb, but probably before TGSI got FSLT/FSGE/etc. For reference, what currently happens for r600g is something like this: D3D: cnd r[0], r[0].w, c[1], c[2] GLSL: R0.xyzw = (R0.w 0.5 ? ps_c[1].xyzw : ps_c[2].xyzw); TGSI: FSLT TEMP[0].x, IMM[0]., TEMP[0]. UIF TEMP[0]. :0 MOV TEMP[0], CONST[1] ELSE :0 MOV TEMP[0], CONST[2] ENDIF R600: SETGE_DX10 T0.x, 0.5, T0.x CNDE_INT R0.x, T0.x, KC0[1].x, KC0[2].x CNDE_INT R0.y, T0.x, KC0[1].y, KC0[2].y CNDE_INT R0.z, T0.x, KC0[1].z, KC0[2].z CNDE_INT R0.w, T0.x, KC0[1].w, KC0[2].w While ideally that would just be 4 CNDGE's, that's better than what I remember. IIRC there used to be a bunch of int/float conversions as well. In the future, a full TGSI program would be preferred, since then it can just be fed in... for this one (with a few assumptions baked in about the immediate, where TEMP[0] comes from, etc), targeted to nvc0 (GF100): : fff01c06 0600 ld b32 $r0 a[0x0] 0x0 unk39 0008: fc01dc00 220e set $p0 0x1 gt f32 $r0 0x0 0010: 43f000c6 1400 $p0 ld b128 $r0q c0[0x10] 0018: 83f020c6 1400 (not $p0) ld b128 $r0q c0[0x20] 0020: 03f01c66 0a7e st b128 a[0x0] $r0:$r1:$r2:$r3 0x0 unk39 Which seems pretty reasonable. -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Suboptimal code generation
Am 14.11.2014 um 19:38 schrieb Henri Verbeet: On 14 November 2014 18:50, Ilia Mirkin imir...@alum.mit.edu wrote: I can't speak for the radeon guys, but I know I sure would love to see any reports of poor code being generated by nouveau in response to legitimate-seeming TGSI (or GLSL). In some cases, a simple optimization can be added to take care of it, and I'd definitely appreciate the extra pair of eyeballs on driver-generated code :) The report can be as simple as here is the TGSI snippet, take a look at how crappy the code it generates is. At least for nouveau, I can feed that directly into a compiler that can target any of the relevant backends. [Note, r600g didn't have an optimizer enabled until ~1y ago; not sure if your analysis was with or without sb.] It was with sb, but probably before TGSI got FSLT/FSGE/etc. For reference, what currently happens for r600g is something like this: D3D: cnd r[0], r[0].w, c[1], c[2] GLSL: R0.xyzw = (R0.w 0.5 ? ps_c[1].xyzw : ps_c[2].xyzw); TGSI: FSLT TEMP[0].x, IMM[0]., TEMP[0]. UIF TEMP[0]. :0 MOV TEMP[0], CONST[1] ELSE :0 MOV TEMP[0], CONST[2] ENDIF R600: SETGE_DX10 T0.x, 0.5, T0.x CNDE_INT R0.x, T0.x, KC0[1].x, KC0[2].x CNDE_INT R0.y, T0.x, KC0[1].y, KC0[2].y CNDE_INT R0.z, T0.x, KC0[1].z, KC0[2].z CNDE_INT R0.w, T0.x, KC0[1].w, KC0[2].w While ideally that would just be 4 CNDGE's, that's better than what I remember. IIRC there used to be a bunch of int/float conversions as well. That looks quite ok to me. Slightly suboptimal maybe but quite reasonable - you can't really expect optimal code always. (With the proposal to nuke cnd from tgsi though you'd just generate the same in any case probably.) I suspect the bunch of int/float conversions got away when switching comparison operation stuff in glsl to tgsi translation to using ints ones on hardware which supports integers (a year ago or so). I know this made some tgsi look a bit nicer but I don't know the effects this had on backends (which also probably learned some new tricks since then). ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/wgl: Implement WGL_EXT_create_context_es/es2_profile.
I'd probably put the version checking logic into a helper function, but not a big deal. Any suggestion to where put such helper? I'm searching but I'm not confident where's the best place to put it so that it can be used everywhere. Would src/mesa/main/version.[ch] be ok? This would at least be good enough for st/glx and st/wgl. Like: boolean _mesa_is_valid_opengl_version(int major, int minor) boolean _mesa_is_valid_opengl_es_version() Jose From: Brian Paul bri...@vmware.com Sent: 14 November 2014 19:37 To: Jose Fonseca; mesa-dev@lists.freedesktop.org Subject: Re: [PATCH 2/2] st/wgl: Implement WGL_EXT_create_context_es/es2_profile. On 11/14/2014 12:13 PM, Jose Fonseca wrote: Thanks for the review. I'd probably put the version checking logic into a helper function, but not a big deal. Good idea. I'll do that in a follow on patch. It looks like we're not doing as extensive version checking in the glx code. It's actually the same amount of checking. But on GLX we somehow need to return a different error for ES profiles to make piglit happy. Ah right, I was looking at the unpatched code. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
Am 14.11.2014 um 15:39 schrieb Emil Velikov: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 mesa 10.4.1-rc1 - 10.4.0.901 ... you get the idea. Afaics most freedesktop project use it plus a big hunk of gnome. Are there any objections if I move to the above format starting with mesa 10.4-rc1 ? I would appreciate any feedback over the next 2-3 days, and based on it I'll tag the first RC. The plan is to still keep the branch point later on today, but to push the tag on Monday. FWIW both schemes look reasonable to me. So I don't really care one way or the other. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] st/wgl: Implement WGL_EXT_create_context_es/es2_profile.
On 11/14/2014 12:44 PM, Jose Fonseca wrote: I'd probably put the version checking logic into a helper function, but not a big deal. Any suggestion to where put such helper? I'm searching but I'm not confident where's the best place to put it so that it can be used everywhere. Would src/mesa/main/version.[ch] be ok? This would at least be good enough for st/glx and st/wgl. Like: boolean _mesa_is_valid_opengl_version(int major, int minor) boolean _mesa_is_valid_opengl_es_version() Yeah, I'd put it in version.[ch] -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Move mesa version scheme to a more common style ?
On Fri, Nov 14, 2014 at 9:39 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Hello all, This is an old question that I had laying around - why doesn't mesa use a more conventional numbering for the development/rc releases ? Eg. mesa 10.4.0-rc1 - 10.3.99.901 mesa 10.4.0-rc2 - 10.3.99.902 ... mesa 10.4.0 - 10.4.0 Something else that occurred to me -- you want to still make a stable 10.3 release, so 10.3.x will come out after 10.3.99.901? Seems confusing... -ilia ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] radeonsi: Disable asynchronous DMA except for PIPE_BUFFER
Reviewed-by: Grigori Goronzy g...@chown.ath.cx I've been using a similar patch to fix stability issues on my machine for quite a while. Still, it's a pity we have to go that far to get everything stable again. On 13.11.2014 07:52, Michel Dänzer wrote: From: Michel Dänzer michel.daen...@amd.com Using the asynchronous DMA engine for multi-dimensional operations seems to cause random GPU lockups for various people. While the root cause for this might need to be fixed in the kernel, let's disable it for now. Before re-enabling this, please make sure you can hit all newly enabled paths in your testing, preferably with both piglit and real world apps, and get in touch with people on the bug reports below for stability testing. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85647 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83500 Cc: mesa-sta...@lists.freedesktop.org Signed-off-by: Michel Dänzer michel.daen...@amd.com --- src/gallium/drivers/radeonsi/si_dma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/gallium/drivers/radeonsi/si_dma.c b/src/gallium/drivers/radeonsi/si_dma.c index b1bd5e7..1d3b524 100644 --- a/src/gallium/drivers/radeonsi/si_dma.c +++ b/src/gallium/drivers/radeonsi/si_dma.c @@ -250,6 +250,9 @@ void si_dma_copy(struct pipe_context *ctx, return; } + /* XXX: The paths below cause lockups for some */ + goto fallback; + if (src-format != dst-format || src_box-depth 1 || rdst-dirty_level_mask != 0 || rdst-cmask.size || rdst-fmask.size || signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Suboptimal code generation
On 14 November 2014 20:41, Roland Scheidegger srol...@vmware.com wrote: That looks quite ok to me. Slightly suboptimal maybe but quite reasonable - you can't really expect optimal code always. (With the proposal to nuke cnd from tgsi though you'd just generate the same in any case probably.) I suspect the bunch of int/float conversions got away when switching comparison operation stuff in glsl to tgsi translation to using ints ones on hardware which supports integers (a year ago or so). I know this made some tgsi look a bit nicer but I don't know the effects this had on backends (which also probably learned some new tricks since then). Yeah, pretty much. I haven't seen anything particularly bad recently, but that could just be because I haven't been actively looking. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa, st/glx, st/wgl: Move GL version validation into an helper.
From: José Fonseca jfons...@vmware.com
As suggested by Brian Paul.
Tested with piglit glx-create-context-invalid-{gl,es}-version.
---
src/gallium/state_trackers/glx/xlib/glx_api.c| 13 +++---
src/gallium/state_trackers/wgl/stw_ext_context.c | 13 +++---
src/mesa/main/version.c | 33
src/mesa/main/version.h | 6 +
4 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 1807edb..d4e028c 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -36,6 +36,8 @@
#include X11/Xmd.h
#include GL/glxproto.h
+#include main/version.h
+
#include xm_api.h
@@ -2792,19 +2794,12 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig
config,
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != GLX_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4))) {
+!_mesa_is_valid_version(majorVersion, minorVersion))) {
generate_error(dpy, BadMatch, 0, X_GLXCreateContextAtrribsARB, True);
return NULL;
}
if (profileMask == GLX_CONTEXT_ES_PROFILE_BIT_EXT
- ((majorVersion == 1 minorVersion 1) ||
-(majorVersion == 2 minorVersion 0) ||
-(majorVersion == 3 minorVersion 1) ||
-majorVersion 3)) {
+ !_mesa_is_valid_es_version(majorVersion, minorVersion)) {
/* GLX_EXT_create_context_es2_profile says nothing to justifying a
* different error code for invalid ES versions, but this is what NVIDIA
* does and piglit expects.
diff --git a/src/gallium/state_trackers/wgl/stw_ext_context.c
b/src/gallium/state_trackers/wgl/stw_ext_context.c
index 8a96cac..ee46334 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_context.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_context.c
@@ -30,6 +30,8 @@
#include GL/gl.h
#include GL/wglext.h
+#include main/version.h
+
#include stw_icd.h
#include stw_context.h
#include stw_device.h
@@ -114,16 +116,9 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4)) ||
+!_mesa_is_valid_version(majorVersion, minorVersion)) ||
(profileMask == WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 1) ||
- (majorVersion == 2 minorVersion 0) ||
- (majorVersion == 3 minorVersion 1) ||
- majorVersion 3))) {
+!_mesa_is_valid_es_version(majorVersion, minorVersion))) {
SetLastError(ERROR_INVALID_VERSION_ARB);
return NULL;
}
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 4951891..5bdef16 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -460,3 +460,36 @@ _mesa_compute_version(struct gl_context *ctx)
break;
}
}
+
+
+GLboolean
+_mesa_is_valid_version(int major, int minor)
+{
+ static const char max_minor_version[] = {
+ /* 1 . */ 5,
+ /* 2 . */ 1,
+ /* 3 . */ 3,
+ /* 4 . */ 5,
+ };
+
+ return (major = 0
+ major sizeof max_minor_version
+ minor = 0
+ minor = max_minor_version[major - 1]);
+}
+
+
+GLboolean
+_mesa_is_valid_es_version(int major, int minor)
+{
+ static const char max_minor_version[] = {
+ /* 1 . */ 1,
+ /* 2 . */ 0,
+ /* 3 . */ 1,
+ };
+
+ return (major = 0
+ major sizeof max_minor_version
+ minor = 0
+ minor = max_minor_version[major - 1]);
+}
diff --git a/src/mesa/main/version.h b/src/mesa/main/version.h
index 450a0e3..e2e1fc2 100644
--- a/src/mesa/main/version.h
+++ b/src/mesa/main/version.h
@@ -50,4 +50,10 @@ _mesa_override_glsl_version(struct gl_constants *consts);
extern int
_mesa_get_gl_version_override(void);
+extern GLboolean
+_mesa_is_valid_version(int major, int minor);
+
+extern GLboolean
+_mesa_is_valid_es_version(int major, int minor);
+
#endif /* VERSION_H */
--
2.1.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa, st/glx, st/wgl: Move GL version validation into an helper.
On Fri, Nov 14, 2014 at 3:33 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
As suggested by Brian Paul.
Tested with piglit glx-create-context-invalid-{gl,es}-version.
---
src/gallium/state_trackers/glx/xlib/glx_api.c| 13 +++---
src/gallium/state_trackers/wgl/stw_ext_context.c | 13 +++---
src/mesa/main/version.c | 33
src/mesa/main/version.h | 6 +
4 files changed, 47 insertions(+), 18 deletions(-)
Is it OK to depend on mesa/main from state trackers? (other than the
GL state tracker, obviously)
diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 1807edb..d4e028c 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -36,6 +36,8 @@
#include X11/Xmd.h
#include GL/glxproto.h
+#include main/version.h
+
#include xm_api.h
@@ -2792,19 +2794,12 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig
config,
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != GLX_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4))) {
+!_mesa_is_valid_version(majorVersion, minorVersion))) {
generate_error(dpy, BadMatch, 0, X_GLXCreateContextAtrribsARB, True);
return NULL;
}
if (profileMask == GLX_CONTEXT_ES_PROFILE_BIT_EXT
- ((majorVersion == 1 minorVersion 1) ||
-(majorVersion == 2 minorVersion 0) ||
-(majorVersion == 3 minorVersion 1) ||
-majorVersion 3)) {
+ !_mesa_is_valid_es_version(majorVersion, minorVersion)) {
/* GLX_EXT_create_context_es2_profile says nothing to justifying a
* different error code for invalid ES versions, but this is what
NVIDIA
* does and piglit expects.
diff --git a/src/gallium/state_trackers/wgl/stw_ext_context.c
b/src/gallium/state_trackers/wgl/stw_ext_context.c
index 8a96cac..ee46334 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_context.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_context.c
@@ -30,6 +30,8 @@
#include GL/gl.h
#include GL/wglext.h
+#include main/version.h
+
#include stw_icd.h
#include stw_context.h
#include stw_device.h
@@ -114,16 +116,9 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4)) ||
+!_mesa_is_valid_version(majorVersion, minorVersion)) ||
(profileMask == WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 1) ||
- (majorVersion == 2 minorVersion 0) ||
- (majorVersion == 3 minorVersion 1) ||
- majorVersion 3))) {
+!_mesa_is_valid_es_version(majorVersion, minorVersion))) {
SetLastError(ERROR_INVALID_VERSION_ARB);
return NULL;
}
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 4951891..5bdef16 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -460,3 +460,36 @@ _mesa_compute_version(struct gl_context *ctx)
break;
}
}
+
+
+GLboolean
+_mesa_is_valid_version(int major, int minor)
+{
+ static const char max_minor_version[] = {
+ /* 1 . */ 5,
+ /* 2 . */ 1,
+ /* 3 . */ 3,
+ /* 4 . */ 5,
+ };
+
+ return (major = 0
+ major sizeof max_minor_version
+ minor = 0
+ minor = max_minor_version[major - 1]);
+}
+
+
+GLboolean
+_mesa_is_valid_es_version(int major, int minor)
+{
+ static const char max_minor_version[] = {
+ /* 1 . */ 1,
+ /* 2 . */ 0,
+ /* 3 . */ 1,
+ };
+
+ return (major = 0
+ major sizeof max_minor_version
+ minor = 0
+ minor = max_minor_version[major - 1]);
+}
diff --git a/src/mesa/main/version.h b/src/mesa/main/version.h
index 450a0e3..e2e1fc2 100644
--- a/src/mesa/main/version.h
+++ b/src/mesa/main/version.h
@@ -50,4 +50,10 @@ _mesa_override_glsl_version(struct gl_constants *consts);
extern int
_mesa_get_gl_version_override(void);
+extern GLboolean
+_mesa_is_valid_version(int major, int minor);
+
+extern GLboolean
+_mesa_is_valid_es_version(int major, int minor);
+
#endif /* VERSION_H */
--
2.1.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
Re: [Mesa-dev] [PATCH] mesa, st/glx, st/wgl: Move GL version validation into an helper.
piglit didn't catch this but I just noticed there a bug. It should be:
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 5bdef16..3f08d31 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -472,8 +472,8 @@ _mesa_is_valid_version(int major, int minor)
/* 4 . */ 5,
};
- return (major = 0
- major sizeof max_minor_version
+ return (major 0
+ major = sizeof max_minor_version
minor = 0
minor = max_minor_version[major - 1]);
}
@@ -488,8 +488,8 @@ _mesa_is_valid_es_version(int major, int minor)
/* 3 . */ 1,
};
- return (major = 0
- major sizeof max_minor_version
+ return (major 0
+ major = sizeof max_minor_version
minor = 0
minor = max_minor_version[major - 1]);
}
From: mesa-dev mesa-dev-boun...@lists.freedesktop.org on behalf of
jfons...@vmware.com jfons...@vmware.com
Sent: 14 November 2014 20:33
To: mesa-dev@lists.freedesktop.org; Brian Paul
Subject: [Mesa-dev] [PATCH] mesa, st/glx, st/wgl: Move GL version
validation into an helper.
From: José Fonseca jfons...@vmware.com
As suggested by Brian Paul.
Tested with piglit glx-create-context-invalid-{gl,es}-version.
---
src/gallium/state_trackers/glx/xlib/glx_api.c| 13 +++---
src/gallium/state_trackers/wgl/stw_ext_context.c | 13 +++---
src/mesa/main/version.c | 33
src/mesa/main/version.h | 6 +
4 files changed, 47 insertions(+), 18 deletions(-)
diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 1807edb..d4e028c 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -36,6 +36,8 @@
#include X11/Xmd.h
#include GL/glxproto.h
+#include main/version.h
+
#include xm_api.h
@@ -2792,19 +2794,12 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig
config,
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != GLX_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4))) {
+!_mesa_is_valid_version(majorVersion, minorVersion))) {
generate_error(dpy, BadMatch, 0, X_GLXCreateContextAtrribsARB, True);
return NULL;
}
if (profileMask == GLX_CONTEXT_ES_PROFILE_BIT_EXT
- ((majorVersion == 1 minorVersion 1) ||
-(majorVersion == 2 minorVersion 0) ||
-(majorVersion == 3 minorVersion 1) ||
-majorVersion 3)) {
+ !_mesa_is_valid_es_version(majorVersion, minorVersion)) {
/* GLX_EXT_create_context_es2_profile says nothing to justifying a
* different error code for invalid ES versions, but this is what NVIDIA
* does and piglit expects.
diff --git a/src/gallium/state_trackers/wgl/stw_ext_context.c
b/src/gallium/state_trackers/wgl/stw_ext_context.c
index 8a96cac..ee46334 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_context.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_context.c
@@ -30,6 +30,8 @@
#include GL/gl.h
#include GL/wglext.h
+#include main/version.h
+
#include stw_icd.h
#include stw_context.h
#include stw_device.h
@@ -114,16 +116,9 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4)) ||
+!_mesa_is_valid_version(majorVersion, minorVersion)) ||
(profileMask == WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 1) ||
- (majorVersion == 2 minorVersion 0) ||
- (majorVersion == 3 minorVersion 1) ||
- majorVersion 3))) {
+!_mesa_is_valid_es_version(majorVersion, minorVersion))) {
SetLastError(ERROR_INVALID_VERSION_ARB);
return NULL;
}
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 4951891..5bdef16 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -460,3 +460,36 @@ _mesa_compute_version(struct gl_context *ctx)
break;
}
}
+
+
+GLboolean
+_mesa_is_valid_version(int major, int minor)
+{
+ static const char max_minor_version[] = {
+ /* 1 . */ 5,
+ /* 2 . */ 1,
+ /* 3 . */ 3,
+ /* 4 . */ 5,
+ };
+
+ return (major = 0
+ major sizeof max_minor_version
+ minor = 0
+ minor = max_minor_version[major - 1]);
+}
+
+
+GLboolean
+_mesa_is_valid_es_version(int
Re: [Mesa-dev] [PATCH] mesa, st/glx, st/wgl: Move GL version validation into an helper.
Is it OK to depend on mesa/main from state trackers? (other than the GL state
tracker, obviously)
No, not in general. It's only because these two state trackers are GL state
trackers, and already depend on mesa/main. (The code src/mesa/state_tracker
doesn't completely hide classic Mesa internals, and there's no harm in that.)
But a, vega, d3d state tracker, should not depend on mesa/main. I think
noawadays the place for putting code that should be used by gallium and mesa is
src/util..
Jose
From: ibmir...@gmail.com ibmir...@gmail.com on behalf of Ilia Mirkin
imir...@alum.mit.edu
Sent: 14 November 2014 20:36
To: Jose Fonseca
Cc: mesa-dev@lists.freedesktop.org; Brian Paul
Subject: Re: [Mesa-dev] [PATCH] mesa, st/glx, st/wgl: Move GL version
validation into an helper.
On Fri, Nov 14, 2014 at 3:33 PM, jfons...@vmware.com wrote:
From: José Fonseca jfons...@vmware.com
As suggested by Brian Paul.
Tested with piglit glx-create-context-invalid-{gl,es}-version.
---
src/gallium/state_trackers/glx/xlib/glx_api.c| 13 +++---
src/gallium/state_trackers/wgl/stw_ext_context.c | 13 +++---
src/mesa/main/version.c | 33
src/mesa/main/version.h | 6 +
4 files changed, 47 insertions(+), 18 deletions(-)
Is it OK to depend on mesa/main from state trackers? (other than the
GL state tracker, obviously)
diff --git a/src/gallium/state_trackers/glx/xlib/glx_api.c
b/src/gallium/state_trackers/glx/xlib/glx_api.c
index 1807edb..d4e028c 100644
--- a/src/gallium/state_trackers/glx/xlib/glx_api.c
+++ b/src/gallium/state_trackers/glx/xlib/glx_api.c
@@ -36,6 +36,8 @@
#include X11/Xmd.h
#include GL/glxproto.h
+#include main/version.h
+
#include xm_api.h
@@ -2792,19 +2794,12 @@ glXCreateContextAttribsARB(Display *dpy, GLXFBConfig
config,
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != GLX_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4))) {
+!_mesa_is_valid_version(majorVersion, minorVersion))) {
generate_error(dpy, BadMatch, 0, X_GLXCreateContextAtrribsARB, True);
return NULL;
}
if (profileMask == GLX_CONTEXT_ES_PROFILE_BIT_EXT
- ((majorVersion == 1 minorVersion 1) ||
-(majorVersion == 2 minorVersion 0) ||
-(majorVersion == 3 minorVersion 1) ||
-majorVersion 3)) {
+ !_mesa_is_valid_es_version(majorVersion, minorVersion)) {
/* GLX_EXT_create_context_es2_profile says nothing to justifying a
* different error code for invalid ES versions, but this is what
NVIDIA
* does and piglit expects.
diff --git a/src/gallium/state_trackers/wgl/stw_ext_context.c
b/src/gallium/state_trackers/wgl/stw_ext_context.c
index 8a96cac..ee46334 100644
--- a/src/gallium/state_trackers/wgl/stw_ext_context.c
+++ b/src/gallium/state_trackers/wgl/stw_ext_context.c
@@ -30,6 +30,8 @@
#include GL/gl.h
#include GL/wglext.h
+#include main/version.h
+
#include stw_icd.h
#include stw_context.h
#include stw_device.h
@@ -114,16 +116,9 @@ wglCreateContextAttribsARB(HDC hDC, HGLRC hShareContext,
const int *attribList)
if (majorVersion = 0 ||
minorVersion 0 ||
(profileMask != WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 5) ||
- (majorVersion == 2 minorVersion 1) ||
- (majorVersion == 3 minorVersion 3) ||
- (majorVersion == 4 minorVersion 5) ||
- majorVersion 4)) ||
+!_mesa_is_valid_version(majorVersion, minorVersion)) ||
(profileMask == WGL_CONTEXT_ES_PROFILE_BIT_EXT
-((majorVersion == 1 minorVersion 1) ||
- (majorVersion == 2 minorVersion 0) ||
- (majorVersion == 3 minorVersion 1) ||
- majorVersion 3))) {
+!_mesa_is_valid_es_version(majorVersion, minorVersion))) {
SetLastError(ERROR_INVALID_VERSION_ARB);
return NULL;
}
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index 4951891..5bdef16 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -460,3 +460,36 @@ _mesa_compute_version(struct gl_context *ctx)
break;
}
}
+
+
+GLboolean
+_mesa_is_valid_version(int major, int minor)
+{
+ static const char max_minor_version[] = {
+ /* 1 . */ 5,
+ /* 2 . */ 1,
+ /* 3 . */ 3,
+ /* 4 . */ 5,
+ };
+
+ return (major = 0
+ major sizeof max_minor_version
+ minor = 0
+ minor = max_minor_version[major - 1]);
+}
+
+
+GLboolean
+_mesa_is_valid_es_version(int major, int minor)
+{
+ static const char max_minor_version[] = {
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
While I agree it would be useful to have some D3D features in OpenGL as extensions to facilitate porting D3D apps to GL, I don't think the features would be very useful for playing Windows D3D games on Linux, because I don't believe that translating D3D to GL is even an option if you want performance. As a fallback, sure why not, but not as a solution that everybody should use. We should take the shortest route from D3D to hardware, skip all these useless translations between APIs and driver interfaces which only add more cruft into shaders and constant buffers and more state changes, resulting in more work for the CPU and the GPU in the end, skip all the useless shader IRs because D3D shaders are actually optimized to a certain degree by the D3D shader compiler from the beginning and only need a hw-specific shader backend. No useless layers and shader IRs, no fallbacks, no workarounds for missing features, no shader variants outside of the hw-specific code, and straight to hardware, please. Marek On Fri, Nov 14, 2014 at 5:15 PM, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 16:36, Ilia Mirkin imir...@alum.mit.edu wrote: Is there a different form that you believe would be more likely to be merged? The main issue is probably that we'd really like to avoid having two parallel implementations of the high-level d3d9 stuff. I.e., anything dealing with (d3d9) devices, stateblocks, swapchains, etc. We'd potentially be open to using something closer to the Gallium interface instead of OpenGL on the backend in wined3d. In that scenario wined3d would essentially be the statetracker. The main issue with that approach has always been that the Gallium statetracker/driver interface isn't meant to be stable, and neither is the internal interface between wined3d and e.g. d3d9. (So it wouldn't help to e.g. move wined3d into the Mesa tree either.) Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. ___ 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] [PATCH 4/4] tgsi/ureg: simplify code for declaring properties
All four Tested-by: Nick Sarnie commendsar...@gmail.com using Gallium
Nine.
On Sun, Nov 9, 2014 at 6:08 PM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
---
src/gallium/auxiliary/tgsi/tgsi_ureg.c| 153
++
src/gallium/auxiliary/tgsi/tgsi_ureg.h| 35 +-
src/gallium/auxiliary/util/u_simple_shaders.c | 2 +-
src/mesa/state_tracker/st_glsl_to_tgsi.cpp| 12 +-
src/mesa/state_tracker/st_mesa_to_tgsi.c | 12 +-
src/mesa/state_tracker/st_program.c | 23 ++--
6 files changed, 43 insertions(+), 194 deletions(-)
diff --git a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
index 6d3ac91..f524dfb 100644
--- a/src/gallium/auxiliary/tgsi/tgsi_ureg.c
+++ b/src/gallium/auxiliary/tgsi/tgsi_ureg.c
@@ -165,15 +165,7 @@ struct ureg_program
struct const_decl const_decls;
struct const_decl const_decls2D[PIPE_MAX_CONSTANT_BUFFERS];
- unsigned property_gs_input_prim;
- unsigned property_gs_output_prim;
- unsigned property_gs_max_vertices;
- unsigned property_gs_invocations;
- unsigned char property_fs_coord_origin; /* = TGSI_FS_COORD_ORIGIN_* */
- unsigned char property_fs_coord_pixel_center; /* =
TGSI_FS_COORD_PIXEL_CENTER_* */
- unsigned char property_fs_color0_writes_all_cbufs; /* =
TGSI_FS_COLOR0_WRITES_ALL_CBUFS * */
- unsigned char property_fs_depth_layout; /* TGSI_FS_DEPTH_LAYOUT */
- boolean property_vs_window_space_position; /*
TGSI_VS_WINDOW_SPACE_POSITION */
+ unsigned properties[TGSI_PROPERTY_COUNT];
unsigned nr_addrs;
unsigned nr_preds;
@@ -278,65 +270,10 @@ ureg_dst_register( unsigned file,
void
-ureg_property_gs_input_prim(struct ureg_program *ureg,
-unsigned input_prim)
+ureg_property(struct ureg_program *ureg, unsigned name, unsigned value)
{
- ureg-property_gs_input_prim = input_prim;
-}
-
-void
-ureg_property_gs_output_prim(struct ureg_program *ureg,
- unsigned output_prim)
-{
- ureg-property_gs_output_prim = output_prim;
-}
-
-void
-ureg_property_gs_max_vertices(struct ureg_program *ureg,
- unsigned max_vertices)
-{
- ureg-property_gs_max_vertices = max_vertices;
-}
-void
-ureg_property_gs_invocations(struct ureg_program *ureg,
- unsigned invocations)
-{
- ureg-property_gs_invocations = invocations;
-}
-
-void
-ureg_property_fs_coord_origin(struct ureg_program *ureg,
-unsigned fs_coord_origin)
-{
- ureg-property_fs_coord_origin = fs_coord_origin;
-}
-
-void
-ureg_property_fs_coord_pixel_center(struct ureg_program *ureg,
-unsigned fs_coord_pixel_center)
-{
- ureg-property_fs_coord_pixel_center = fs_coord_pixel_center;
-}
-
-void
-ureg_property_fs_color0_writes_all_cbufs(struct ureg_program *ureg,
-unsigned fs_color0_writes_all_cbufs)
-{
- ureg-property_fs_color0_writes_all_cbufs = fs_color0_writes_all_cbufs;
-}
-
-void
-ureg_property_fs_depth_layout(struct ureg_program *ureg,
- unsigned fs_depth_layout)
-{
- ureg-property_fs_depth_layout = fs_depth_layout;
-}
-
-void
-ureg_property_vs_window_space_position(struct ureg_program *ureg,
- boolean vs_window_space_position)
-{
- ureg-property_vs_window_space_position = vs_window_space_position;
+ assert(name Elements(ureg-properties));
+ ureg-properties[name] = value;
}
struct ureg_src
@@ -1452,77 +1389,9 @@ static void emit_decls( struct ureg_program *ureg )
{
unsigned i;
- if (ureg-property_gs_input_prim != ~0) {
- assert(ureg-processor == TGSI_PROCESSOR_GEOMETRY);
-
- emit_property(ureg,
-TGSI_PROPERTY_GS_INPUT_PRIM,
-ureg-property_gs_input_prim);
- }
-
- if (ureg-property_gs_output_prim != ~0) {
- assert(ureg-processor == TGSI_PROCESSOR_GEOMETRY);
-
- emit_property(ureg,
-TGSI_PROPERTY_GS_OUTPUT_PRIM,
-ureg-property_gs_output_prim);
- }
-
- if (ureg-property_gs_max_vertices != ~0) {
- assert(ureg-processor == TGSI_PROCESSOR_GEOMETRY);
-
- emit_property(ureg,
-TGSI_PROPERTY_GS_MAX_OUTPUT_VERTICES,
-ureg-property_gs_max_vertices);
- }
-
- if (ureg-property_gs_invocations != ~0) {
- assert(ureg-processor == TGSI_PROCESSOR_GEOMETRY);
-
- emit_property(ureg,
-TGSI_PROPERTY_GS_INVOCATIONS,
-ureg-property_gs_invocations);
- }
-
- if (ureg-property_fs_coord_origin) {
- assert(ureg-processor == TGSI_PROCESSOR_FRAGMENT);
-
- emit_property(ureg,
-TGSI_PROPERTY_FS_COORD_ORIGIN,
-ureg-property_fs_coord_origin);
Re: [Mesa-dev] [PATCH] radeonsi: implement TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION
Tested-by: Nick Sarnie commendsar...@gmail.com using Gallium Nine.
On Sun, Nov 9, 2014 at 6:09 PM, Marek Olšák mar...@gmail.com wrote:
From: Marek Olšák marek.ol...@amd.com
Required by Nine.
---
src/gallium/drivers/radeonsi/si_pipe.c | 2 +-
src/gallium/drivers/radeonsi/si_state.c | 1 -
src/gallium/drivers/radeonsi/si_state_draw.c | 16 +++-
3 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/src/gallium/drivers/radeonsi/si_pipe.c
b/src/gallium/drivers/radeonsi/si_pipe.c
index 7c479d6..279d7ce 100644
--- a/src/gallium/drivers/radeonsi/si_pipe.c
+++ b/src/gallium/drivers/radeonsi/si_pipe.c
@@ -211,6 +211,7 @@ static int si_get_param(struct pipe_screen* pscreen,
enum pipe_cap param)
case PIPE_CAP_SAMPLE_SHADING:
case PIPE_CAP_DRAW_INDIRECT:
case PIPE_CAP_CLIP_HALFZ:
+ case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
return 1;
case PIPE_CAP_TEXTURE_MULTISAMPLE:
@@ -249,7 +250,6 @@ static int si_get_param(struct pipe_screen* pscreen,
enum pipe_cap param)
case PIPE_CAP_TGSI_TEXCOORD:
case PIPE_CAP_FAKE_SW_MSAA:
case PIPE_CAP_TEXTURE_GATHER_OFFSETS:
- case PIPE_CAP_TGSI_VS_WINDOW_SPACE_POSITION:
case PIPE_CAP_TGSI_FS_FINE_DERIVATIVE:
case PIPE_CAP_CONDITIONAL_RENDER_INVERTED:
case PIPE_CAP_SAMPLER_VIEW_TARGET:
diff --git a/src/gallium/drivers/radeonsi/si_state.c
b/src/gallium/drivers/radeonsi/si_state.c
index 030d6e9..ea8e61a 100644
--- a/src/gallium/drivers/radeonsi/si_state.c
+++ b/src/gallium/drivers/radeonsi/si_state.c
@@ -3184,7 +3184,6 @@ void si_init_config(struct si_context *sctx)
si_pm4_set_reg(pm4, R_028230_PA_SC_EDGERULE, 0x);
si_pm4_set_reg(pm4, R_0282D0_PA_SC_VPORT_ZMIN_0, 0x);
si_pm4_set_reg(pm4, R_0282D4_PA_SC_VPORT_ZMAX_0, 0x3F80);
- si_pm4_set_reg(pm4, R_028818_PA_CL_VTE_CNTL, 0x043F);
si_pm4_set_reg(pm4, R_028820_PA_CL_NANINF_CNTL, 0x);
si_pm4_set_reg(pm4, R_028BE8_PA_CL_GB_VERT_CLIP_ADJ, 0x3F80);
si_pm4_set_reg(pm4, R_028BEC_PA_CL_GB_VERT_DISC_ADJ, 0x3F80);
diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c
b/src/gallium/drivers/radeonsi/si_state_draw.c
index 708e42a..d5b27e7 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -150,6 +150,8 @@ static void si_shader_vs(struct si_shader *shader)
unsigned num_sgprs, num_user_sgprs;
unsigned nparams, i, vgpr_comp_cnt;
uint64_t va;
+ unsigned window_space =
+
shader-selector-info.properties[TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION];
pm4 = shader-pm4 = CALLOC_STRUCT(si_pm4_state);
@@ -218,6 +220,15 @@ static void si_shader_vs(struct si_shader *shader)
S_00B12C_SO_BASE2_EN(!!shader-selector-so.stride[2]) |
S_00B12C_SO_BASE3_EN(!!shader-selector-so.stride[3]) |
S_00B12C_SO_EN(!!shader-selector-so.num_outputs));
+ if (window_space)
+ si_pm4_set_reg(pm4, R_028818_PA_CL_VTE_CNTL,
+ S_028818_VTX_XY_FMT(1) |
S_028818_VTX_Z_FMT(1));
+ else
+ si_pm4_set_reg(pm4, R_028818_PA_CL_VTE_CNTL,
+ S_028818_VTX_W0_FMT(1) |
+ S_028818_VPORT_X_SCALE_ENA(1) |
S_028818_VPORT_X_OFFSET_ENA(1) |
+ S_028818_VPORT_Y_SCALE_ENA(1) |
S_028818_VPORT_Y_OFFSET_ENA(1) |
+ S_028818_VPORT_Z_SCALE_ENA(1) |
S_028818_VPORT_Z_OFFSET_ENA(1));
}
static void si_shader_ps(struct si_shader *shader)
@@ -436,6 +447,8 @@ static bool si_update_draw_info_state(struct
si_context *sctx,
{
struct si_pm4_state *pm4 = CALLOC_STRUCT(si_pm4_state);
struct si_shader *vs = si_get_vs_state(sctx);
+ unsigned window_space =
+
vs-selector-info.properties[TGSI_PROPERTY_VS_WINDOW_SPACE_POSITION];
unsigned prim = si_conv_pipe_prim(info-mode);
unsigned gs_out_prim =
si_conv_prim_to_gs_out(sctx-gs_shader ?
@@ -496,7 +509,8 @@ static bool si_update_draw_info_state(struct
si_context *sctx,
si_pm4_set_reg(pm4, R_028810_PA_CL_CLIP_CNTL,
sctx-queued.named.rasterizer-pa_cl_clip_cntl |
(vs-clip_dist_write ? 0 :
- sctx-queued.named.rasterizer-clip_plane_enable
0x3F));
+ sctx-queued.named.rasterizer-clip_plane_enable
0x3F) |
+ S_028810_CLIP_DISABLE(window_space));
si_pm4_set_state(sctx, draw_info, pm4);
return true;
--
2.1.0
___
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
Re: [Mesa-dev] [PATCH] mesa: Fix _mesa_uint_array_min_max linker error.
On Fri, 2014-11-14 at 22:14 +0330, Siavash Eliasi wrote:
You are right. Any suggestions on how to fix this build failure?
Using this would fix it but the optimisation would be disabled on clang.
Not sure how many people are concerned about this, I don't use clang
myself.
[1]
http://lists.freedesktop.org/archives/mesa-dev/2014-November/070387.html
On 11/14/2014 10:10 PM, Ilia Mirkin wrote:
And disables the optimization unless you're building with a -march
that has sse4.1... thus defeating the purpose of doing it this way.
On Fri, Nov 14, 2014 at 1:23 PM, Siavash Eliasi siavashser...@gmail.com
wrote:
Fixes build process failure when providing -mno-sse4.1 CFLAGS:
vbo_exec_array.c:(.text+0x9bb): undefined reference to
`_mesa_uint_array_min_max'
How annoying. I seems the intel driver for one doesn't support building
like this anyway. I'll say it again, it seems bad to stop the majority
of user accessing optimisations because of an one odd build setup.
Similar bug:
https://bugs.freedesktop.org/show_bug.cgi?id=71547
---
src/mesa/vbo/vbo_exec_array.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/mesa/vbo/vbo_exec_array.c b/src/mesa/vbo/vbo_exec_array.c
index e623b36..6362dd4 100644
--- a/src/mesa/vbo/vbo_exec_array.c
+++ b/src/mesa/vbo/vbo_exec_array.c
@@ -121,12 +121,14 @@ vbo_get_minmax_index(struct gl_context *ctx,
}
}
else {
+#ifdef __SSE4_1__
#if defined(USE_SSE41)
if (cpu_has_sse4_1) {
_mesa_uint_array_min_max(ui_indices, min_ui, max_ui,
count);
}
else
#endif
+#endif
for (i = 0; i count; i++) {
if (ui_indices[i] max_ui) max_ui = ui_indices[i];
if (ui_indices[i] min_ui) min_ui = ui_indices[i];
--
2.1.3
___
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 mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 0/9] Gallium Nine
On 15 November 2014 03:25, Henri Verbeet hverb...@gmail.com wrote: On 14 November 2014 17:37, Ilia Mirkin imir...@alum.mit.edu wrote: Dave Airlie's virgl work is creating a gallium driver which actually uses OpenGL for hardware. I'm not sure how far he is, but I believe he has enough for GL3. This could be a way forward towards *only* using gallium (since otherwise you'd still have to have an OpenGL-based backend for the hw/platforms that don't have gallium drivers). However gallium will never support fixed-function hardware, so that may still not work for you. Fixed-function hardware is becoming less and less relevant, but on the other hand we try to avoid breaking things that currently work. But yes, that's certainly something that's interesting to see how it turns out. Another consideration is that while the Gallium interface is a better match than OpenGL for Direct3D in some places, I'm not necessarily convinced that that's something that couldn't be fixed with appropriate GL extensions. To give an example, it's possible that translating D3D bytecode to TGSI instead of GLSL ends up with better shader code for the hardware. Unfortunately that kind of analysis is completely missing as far as I'm aware, but if that were the case, it would probably be fixable by making some improvements to the GLSL compiler. If that's not possible for some reason we could consider adding an extension for authoring shaders in TGSI instead of GLSL, and so on. I guess the basic point is that replacing OpenGL is a pretty big hammer, that would need corresponding amounts of analysis and justification. While I don't have this justification, I always just assumed this was due to mismatches between how d3d wanted to do things and how OpenGL let you do things, so you ended up having to do some fairly heavy-handed things in OpenGL solely due to the silliness of the API. Well yes, but the issues tend to be things like those solved by ARB_clip_control, ARB_vertex_array_bgra, ARB_provoking_vertex, etc. Let's say that all such things could be identified and extensions created for, you'd still end up effectively managing 2 backends -- one that assumes that the various d3d-helper extensions are there, and one that doesn't. Yes, but that's much more limited in scope than replacing all of OpenGL. I strongly doubt that the performance increases are due to better d3d9 bytecode - TGSI conversion than - glsl - tgsi conversion -- most serious backends (r600, radeonsi, nouveau) have optimizing compilers that should take care of such issues. It was just an example, but at least in the past I've seen for example the translation for D3D cnd and cmp result in pretty sub-optimal code in r600g. In GLSL 1.30 and up mix() with a bool argument could perhaps make it easier for the driver to end up with something reasonable. But not knowing where the actual differences/advantages are is a large part of what makes it hard to discuss st/nine in concrete terms from a Wine perspective. It seems like a bad example, maybe someone could actually figure out why wine is slower, From my experience, its rarely been compiler optimisations that make a single massive difference, its probably something more architectural with having mismatches at other levels in the APIs and overheads of recompiling shaders. Dave. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3 1/9] tgsi/ureg: add ureg_UARL shortcut (v2)
For patches 1, 5, 7: Reviewed-by: Marek Olšák marek.ol...@amd.com BTW, I'd like to have standard Mesa coding style for Nine (indenting code blocks by 3 spaces). Marek On Sun, Nov 2, 2014 at 7:28 PM, David Heidelberg da...@ixit.cz wrote: v2: moved in in same order as in p_shader_tokens (thanks Brian) Signed-off-by: David Heidelberg da...@ixit.cz --- src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h | 1 + 1 file changed, 1 insertion(+) diff --git a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h index 7888be8..4ca4f24 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h +++ b/src/gallium/auxiliary/tgsi/tgsi_opcode_tmp.h @@ -201,6 +201,7 @@ OP13_SAMPLE(GATHER4) OP12(SVIEWINFO) OP13(SAMPLE_POS) OP12(SAMPLE_INFO) +OP11(UARL) OP13(UCMP) -- 2.1.3 ___ 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] [PATCH v2 00/16] Scalar VS for BDW+
On Thursday, November 13, 2014 04:28:06 PM Kristian Høgsberg wrote: Hi, Here's v2 of the patch series. It incorportes Matts review comments and adds a new patch to refactor the way we call fs_generator. The idea is to get rid of the MESA_SHADER_FS assertion in generate_assembly)() in a nicer way. Now we call generate_code() two times with different dispatch with instead, which returns the offset in the assembly where we put the generated code. Kristian This code isn't based on the latest master, and also does not compile. While that's easily fixable, I don't feel confident enough in this code to push it on the day of the branch. I'm really sorry for not reviewing it earlier - that's my bad. I would like to land it soon after the branch point, though. --Ken signature.asc Description: This is a digitally signed message part. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 16/16] i965: Generate vs code using scalar backend for BDW+
On Thursday, November 13, 2014 04:28:22 PM Kristian Høgsberg wrote:
With everything in place, we can now use the scalar backend compiler for
vertex shaders on BDW+. We make scalar vertex shaders the default on
BDW+ but add a new vec4vs debug option to force the vec4 backend.
No piglit regressions.
Performance impact is minimal, I see a ~1.5 improvement on the T-Rex
GLBenchmark case, but in general it's in the noise. Some of our
internal synthetic, vs bounded benchmarks show great improvement, 20%-40%
in some cases, but real-world cases are mostly unaffected.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_context.c | 13 +++
src/mesa/drivers/dri/i965/brw_context.h | 1 +
src/mesa/drivers/dri/i965/brw_shader.cpp | 17 +++--
src/mesa/drivers/dri/i965/brw_vec4.cpp | 60
+---
src/mesa/drivers/dri/i965/intel_debug.c | 1 +
src/mesa/drivers/dri/i965/intel_debug.h | 1 +
6 files changed, 78 insertions(+), 15 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index e1a994a..f56cfb2 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -557,6 +557,15 @@ brw_initialize_context_constants(struct brw_context *brw)
ctx-Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS =
true;
ctx-Const.ShaderCompilerOptions[MESA_SHADER_GEOMETRY].OptimizeForAOS =
true;
+ if (brw-scalar_vs) {
+ /* If we're using the scalar backend for vertex shaders, we need to
+ * configure these accordingly.
+ */
+
ctx-Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectOutput =
true;
+
ctx-Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectTemp =
true;
+ ctx-Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS =
false;
This is concerning. Any shaders that use variable indexing of temporary
or output arrays will now get giant IF-ladders, which is horribly inefficient.
It seems like a regression in terms of functionality.
I don't know how important indirect output support is for VS, or how hard
that would be. If we really support it in the 4x2 backend, I can't imagine
it'd be that hard in scalar one.
Supporting indirect access of temp arrays by spilling to scratch (like the
4x2 backend does) should be trivial, and would improve the fragment shader
backend considerably as well. I'd like to see that happen before this lands.
OptimizeForAOS begs the question...If we ever fall back to SIMD4x2, how do
we set different options? I think we should ignore that problem. The
EmitNoIndirect* flags can be fixed by adding support to the scalar backend.
The only things we lose from OptimizeForAOS are Matt's vectorizer pass
(which I think we should run regardless of this flag), and the matrix
flipper (which isn't very important).
+ }
+
/* ARB_viewport_array */
if (brw-gen = 7 ctx-API == API_OPENGL_CORE) {
ctx-Const.MaxViewports = GEN7_NUM_VIEWPORTS;
@@ -755,6 +764,10 @@ brwCreateContext(gl_api api,
brw_process_driconf_options(brw);
brw_process_intel_debug_variable(brw);
+
+ if (brw-gen = 8 !(INTEL_DEBUG DEBUG_VEC4VS))
+ brw-scalar_vs = true;
+
brw_initialize_context_constants(brw);
ctx-Const.ResetStrategy = notify_reset
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index 463f3d2..f198103 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -1067,6 +1067,7 @@ struct brw_context
bool has_pln;
bool no_simd8;
bool use_rep_send;
+ bool scalar_vs;
/**
* Some versions of Gen hardware don't do centroid interpolation correctly
diff --git a/src/mesa/drivers/dri/i965/brw_shader.cpp
b/src/mesa/drivers/dri/i965/brw_shader.cpp
index 3c78afd..26da729 100644
--- a/src/mesa/drivers/dri/i965/brw_shader.cpp
+++ b/src/mesa/drivers/dri/i965/brw_shader.cpp
@@ -71,6 +71,19 @@ brw_shader_precompile(struct gl_context *ctx, struct
gl_shader_program *prog)
return true;
}
+static inline bool
+is_scalar_shader_stage(struct brw_context *brw, int stage)
+{
+ switch (stage) {
+ case MESA_SHADER_FRAGMENT:
+ return true;
+ case MESA_SHADER_VERTEX:
+ return brw-scalar_vs;
+ default:
+ return false;
+ }
+}
+
static void
brw_lower_packing_builtins(struct brw_context *brw,
gl_shader_stage shader_type,
@@ -91,7 +104,7 @@ brw_lower_packing_builtins(struct brw_context *brw,
* lowering is needed. For SOA code, the Half2x16 ops must be
* scalarized.
*/
- if (shader_type == MESA_SHADER_FRAGMENT) {
+ if (is_scalar_shader_stage(brw, shader_type)) {
ops |= LOWER_PACK_HALF_2x16_TO_SPLIT
| LOWER_UNPACK_HALF_2x16_TO_SPLIT;
Re: [Mesa-dev] How difficult would it be to have debugging information for Jitted code show up?
Hello, This would be a tough task then. However, all I really want are symbol names. Having source level debugging would be really cool but not something I would actually use that much. Even just having a basic outline of the code would be nice. In fact, I'd imagine it'd be easiest and best if simply the fixed function code was labelled with a few symbol names that would let me understand the broad strokes of the code. Also for some reason I can't seem to view the assembly of the JITted code. Maybe I'm missing a special option for perf to record JITted code, or it just lacks the functionality or maybe something has to be done to notify profilers about it (similar to how Valgrind and such need to be notified about JITted code.) Thank you, Steven Stewart-Gallus ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] How difficult would it be to have debugging information for Jitted code show up?
However, all I really want are symbol names. You should have them when running inside perf. Also for some reason I can't seem to view the assembly of the JITted code. Did you follow the instructions on http://mesa3d.org/llvmpipe.html and use bin/perf-annotate-jit script ? Jose From: Steven Stewart-Gallus sstewartgallu...@mylangara.bc.ca Sent: 14 November 2014 23:50 To: Jose Fonseca Cc: Emil Velikov; ML mesa-dev Subject: Re: RE: [Mesa-dev] How difficult would it be to have debugging information for Jitted code show up? Hello, This would be a tough task then. However, all I really want are symbol names. Having source level debugging would be really cool but not something I would actually use that much. Even just having a basic outline of the code would be nice. In fact, I'd imagine it'd be easiest and best if simply the fixed function code was labelled with a few symbol names that would let me understand the broad strokes of the code. Also for some reason I can't seem to view the assembly of the JITted code. Maybe I'm missing a special option for perf to record JITted code, or it just lacks the functionality or maybe something has to be done to notify profilers about it (similar to how Valgrind and such need to be notified about JITted code.) Thank you, Steven Stewart-Gallus ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 14/16] i965: Add fs_visitor::run_vs() to generate scalar vertex shader code
On Thursday, November 13, 2014 04:28:20 PM Kristian Høgsberg wrote:
This patch uses the previous refactoring to add a new run_vs() method
that generates vertex shader code using the scalar visitor and
optimizer.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 99 -
src/mesa/drivers/dri/i965/brw_fs.h | 21 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 303
++-
3 files changed, 412 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 4dce0a2..8007977 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1828,6 +1828,56 @@ fs_visitor::assign_urb_setup()
urb_start + prog_data-num_varying_inputs * 2;
}
+void
+fs_visitor::assign_vs_urb_setup()
+{
+ brw_vs_prog_data *vs_prog_data = (brw_vs_prog_data *) prog_data;
+ int grf, count, slot, channel, attr;
+
+ assert(stage == MESA_SHADER_VERTEX);
+ count = _mesa_bitcount_64(vs_prog_data-inputs_read);
+ if (vs_prog_data-uses_vertexid || vs_prog_data-uses_instanceid)
+ count++;
+
+ /* Each attribute is 4 regs. */
+ this-first_non_payload_grf =
+ payload.num_regs + prog_data-curb_read_length + count * 4;
+
+ unsigned vue_entries =
+ MAX2(count, vs_prog_data-base.vue_map.num_slots);
+
+ vs_prog_data-base.urb_entry_size = ALIGN(vue_entries, 4) / 4;
+ vs_prog_data-base.urb_read_length = (count + 1) / 2;
+
+ assert(vs_prog_data-base.urb_read_length = 15);
+
+ /* Rewrite all ATTR file references to the hw grf that they land in. */
+ foreach_block_and_inst(block, fs_inst, inst, cfg) {
+ for (int i = 0; i inst-sources; i++) {
+ if (inst-src[i].file == ATTR) {
+
+if (inst-src[i].reg == VERT_ATTRIB_MAX) {
+ slot = count - 1;
+} else {
+ attr = inst-src[i].reg + inst-src[i].reg_offset / 4;
+ slot = _mesa_bitcount_64(vs_prog_data-inputs_read
+BITFIELD64_MASK(attr));
I'm having trouble understanding this code - can you explain?
Reading ir_set_program_inouts.cpp:98 I see that incoming vertex attributes
are always vec4 slots, except for matrices and arrays, which use multiple
vec4 slots.
I expected your ATTR registers to always be size 4, so reg_offset would have
valid values of 0..3. But I must be mistaken, since you're doing
reg_offset / 4, which would always be 0. Are ATTRs 4*N where N == the # of
matrix columns or array length?
Even still - I don't see how applying BITFIELD64_MASK to a potentially
non-power-of-two number and then doing a bitcount will give you a single
accurate slot value.
Adding a comment would also be nice to future maintainers.
This was the main spot where I got confused - otherwise most of the code
looks good to me.
+}
+
+channel = inst-src[i].reg_offset 3;
+
+grf = payload.num_regs +
+ prog_data-curb_read_length +
+ slot * 4 + channel;
+
+inst-src[i].file = HW_REG;
+inst-src[i].fixed_hw_reg =
+ retype(brw_vec8_grf(grf, 0), inst-src[i].type);
+ }
+ }
+ }
+}
+
/**
* Split large virtual GRFs into separate components if we can.
*
@@ -3405,6 +3455,13 @@ fs_visitor::setup_payload_gen6()
}
void
+fs_visitor::setup_vs_payload()
+{
+ /* R0: thread header, R1: urb handles */
+ payload.num_regs = 2;
+}
+
+void
fs_visitor::assign_binding_table_offsets()
{
assert(stage == MESA_SHADER_FRAGMENT);
@@ -3471,6 +3528,8 @@ fs_visitor::opt_drop_redundant_mov_to_flags()
void
fs_visitor::optimize()
{
+ const char *stage_name = stage == MESA_SHADER_VERTEX ? vs : fs;
+
calculate_cfg();
split_virtual_grfs();
@@ -3487,8 +3546,8 @@ fs_visitor::optimize()
\
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER) this_progress) { \
char filename[64]; \
- snprintf(filename, 64, fs%d-%04d-%02d-%02d- #pass, \
- dispatch_width, shader_prog ? shader_prog-Name : 0,
iteration, pass_num); \
+ snprintf(filename, 64, %s%d-%04d-%02d-%02d- #pass, \
+ stage_name, dispatch_width, shader_prog ?
shader_prog-Name : 0, iteration, pass_num); \
\
backend_visitor::dump_instructions(filename); \
} \
@@ -3498,8 +3557,8 @@ fs_visitor::optimize()
if (unlikely(INTEL_DEBUG DEBUG_OPTIMIZER)) {
char filename[64];
- snprintf(filename, 64, fs%d-%04d-00-start,
-
Re: [Mesa-dev] [PATCH v2 14/16] i965: Add fs_visitor::run_vs() to generate scalar vertex shader code
On Thursday, November 13, 2014 04:28:20 PM Kristian Høgsberg wrote:
This patch uses the previous refactoring to add a new run_vs() method
that generates vertex shader code using the scalar visitor and
optimizer.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
src/mesa/drivers/dri/i965/brw_fs.cpp | 99 -
src/mesa/drivers/dri/i965/brw_fs.h | 21 +-
src/mesa/drivers/dri/i965/brw_fs_visitor.cpp | 303
++-
3 files changed, 412 insertions(+), 11 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp
b/src/mesa/drivers/dri/i965/brw_fs.cpp
index 4dce0a2..8007977 100644
--- a/src/mesa/drivers/dri/i965/brw_fs.cpp
+++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
@@ -1828,6 +1828,56 @@ fs_visitor::assign_urb_setup()
urb_start + prog_data-num_varying_inputs * 2;
}
+void
+fs_visitor::assign_vs_urb_setup()
+{
+ brw_vs_prog_data *vs_prog_data = (brw_vs_prog_data *) prog_data;
+ int grf, count, slot, channel, attr;
+
+ assert(stage == MESA_SHADER_VERTEX);
+ count = _mesa_bitcount_64(vs_prog_data-inputs_read);
+ if (vs_prog_data-uses_vertexid || vs_prog_data-uses_instanceid)
+ count++;
+
+ /* Each attribute is 4 regs. */
+ this-first_non_payload_grf =
+ payload.num_regs + prog_data-curb_read_length + count * 4;
+
+ unsigned vue_entries =
+ MAX2(count, vs_prog_data-base.vue_map.num_slots);
+
+ vs_prog_data-base.urb_entry_size = ALIGN(vue_entries, 4) / 4;
+ vs_prog_data-base.urb_read_length = (count + 1) / 2;
+
+ assert(vs_prog_data-base.urb_read_length = 15);
What enforces this assertion? It obviously needs to be true, since
the Vertex URB Entry Read Length field in 3DSTATE_VS has a maximum
value of 15 in SIMD8 mode.
But this looks like the exact same calculation done in
vec4_vs_visitor::setup_attributes, and the limit there is [1, 63].
The documentation indicates that the API may allow more vertex attributes
than can practically be supported by pushing VUEs in as payload registers:
The EU limit of 128 GRFs imposes a maximum limit of 30 elements per vertex
pushed into the payload, though the practical limit may be lower. If input
vertices exceed the practical limit, software must decide between resorting
to pulling elements during thread execution or dropping back to SIMD4x2
dispatch.
I don't see any code in this series for falling back, nor for pulling VUEs
out of the URB (and avoiding overwriting them before they're loaded), so
I expect this would simply assert fail on a vertex shader with too many
inputs.
--Ken
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 10/16] i965: Rename brw_vec4_prog_data to brw_vue_prog_data
On Thursday, November 13, 2014 04:28:16 PM Kristian Høgsberg wrote:
With scalar vertex shader coming up, we're going to reuse brw_vec4_prog_data
in the scalar backend. There's nothing vec4 specific in the struct, it's
instead common state for stages that operate on VUEs. This patch renames
the struct to brw_vue_prog_data which is more descriptive and will look a lot
less awkward when we use it in the scalar backend.
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
[snip]
diff --git a/src/mesa/drivers/dri/i965/brw_vec4.cpp
b/src/mesa/drivers/dri/i965/brw_vec4.cpp
index df589b8..280db47 100644
--- a/src/mesa/drivers/dri/i965/brw_vec4.cpp
+++ b/src/mesa/drivers/dri/i965/brw_vec4.cpp
@@ -1911,9 +1911,9 @@ brw_vs_emit(struct brw_context *brw,
void
-brw_vec4_setup_prog_key_for_precompile(struct gl_context *ctx,
- struct brw_vec4_prog_key *key,
- GLuint id, struct gl_program *prog)
+brw_vue_setup_prog_key_for_precompile(struct gl_context *ctx,
+ struct brw_vue_prog_key *key,
+ GLuint id, struct gl_program *prog)
{
You've renamed this function without renaming any of its callers.
Applying this patch leads to an unloadable driver with missing symbols:
libGL: pci id for fd 4: 8086:0d26, driver i965
libGL: OpenDriver: trying /home/kwg/Projects/mesa/lib/tls/i965_dri.so
libGL: OpenDriver: trying /home/kwg/Projects/mesa/lib/i965_dri.so
libGL: dlopen /home/kwg/Projects/mesa/lib/i965_dri.so failed
(/home/kwg/Projects/mesa/lib/i965_dri.so: undefined symbol:
brw_vec4_setup_prog_key_for_precompile)
signature.asc
Description: This is a digitally signed message part.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
