[Mesa-dev] [PATCH 2/2] - drirc: whitelist glthread for Euro Truck Simulator 2
--- src/mesa/drivers/dri/common/drirc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/common/drirc b/src/mesa/drivers/dri/common/drirc index 1311db9..be731a0 100644 --- a/src/mesa/drivers/dri/common/drirc +++ b/src/mesa/drivers/dri/common/drirc @@ -178,6 +178,9 @@ TODO: document the other workarounds. + + + -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 1/2] - drirc: whitelist glthread for American Truck Simulator
--- src/mesa/drivers/dri/common/drirc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/mesa/drivers/dri/common/drirc b/src/mesa/drivers/dri/common/drirc index 69b735c..1311db9 100644 --- a/src/mesa/drivers/dri/common/drirc +++ b/src/mesa/drivers/dri/common/drirc @@ -175,6 +175,9 @@ TODO: document the other workarounds. + + + -- 2.5.0 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] meta: enable vertex attributes in the context of the newly created array object
Otherwise, the function would enable generic vertex attributes 0 and 1 of the array object it does not own. This was causing crashes in Euro Truck Simulator 2, since the incorrectly enabled generic attribute 0 in the foreign context got precedence before vertex position attribute at later time, leading to NULL pointer dereference. Signed-off-by: Petr Sebor p...@scssoft.com --- This version is really much better for the reasons both you and Ian mentioned. And... works for me! Thanks! Petr --- src/mesa/drivers/common/meta.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c index f818416..3be 100644 --- a/src/mesa/drivers/common/meta.c +++ b/src/mesa/drivers/common/meta.c @@ -1515,6 +1515,9 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx, sizeof(struct vertex), OFFSET(x)); _mesa_VertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE, sizeof(struct vertex), OFFSET(s)); + + _mesa_EnableVertexAttribArray(0); + _mesa_EnableVertexAttribArray(1); } /* Generate a relevant fragment shader program for the texture target */ @@ -1591,8 +1594,6 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx, _mesa_DeleteObjectARB(vs); _mesa_BindAttribLocation(ShaderProg, 0, position); _mesa_BindAttribLocation(ShaderProg, 1, texcoords); - _mesa_EnableVertexAttribArray(0); - _mesa_EnableVertexAttribArray(1); link_program_with_debug(ctx, ShaderProg); ralloc_free(mem_ctx); if (texture_2d) -- 1.8.3.2 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] meta: enable vertex attributes in the context of the newly created array object
Not having push access rights, I hope this fix gets merged soon. Hopefully a stable release candidate as well. Thanks, Petr On 12.11.2013 00:32, Brian Paul wrote: On 11/11/2013 04:19 PM, Petr Sebor wrote: Otherwise, the function would enable generic vertex attributes 0 and 1 of the array object it does not own. This was causing crashes in Euro Truck Simulator 2, since the incorrectly enabled generic attribute 0 in the foreign context got precedence before vertex position attribute at later time, leading to NULL pointer dereference. Signed-off-by: Petr Sebor p...@scssoft.com Reviewed-by: Brian Paul bri...@vmware.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] meta: rebind the array object to prevent corruption of current one in setup_glsl_blit_framebuffer
Without the rebind, the function enables generic vertex attributes 0 and 1 of
the
array object it does not own. This was causing crashes in Euro Truck Simulator
2,
since the enabled generic attribute 0 got precedence before vertex position
attribute
at later time, leading to NULL pointer dereference.
Signed-off-by: Petr Sebor p...@scssoft.com
---
src/mesa/drivers/common/meta.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/src/mesa/drivers/common/meta.c b/src/mesa/drivers/common/meta.c
index aa50dde..06e3e3c 100644
--- a/src/mesa/drivers/common/meta.c
+++ b/src/mesa/drivers/common/meta.c
@@ -1516,6 +1516,11 @@ setup_glsl_blit_framebuffer(struct gl_context *ctx,
_mesa_VertexAttribPointer(1, 2, GL_FLOAT, GL_FALSE,
sizeof(struct vertex), OFFSET(s));
}
+ else {
+ /* Rebind the existing ArrayObj so that _mesa_EnableVertexAttribArray */
+ /* calls do not corrupt the current one. */
+ _mesa_BindVertexArray(blit-ArrayObj);
+ }
/* Generate a relevant fragment shader program for the texture target */
if ((target == GL_TEXTURE_2D blit-ShaderProg != 0) ||
--
1.8.3.2
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] S2TC - yet another attempt to solve the S3TC issue
On 4.8.2011 12:19, Rudolf Polzer wrote: On Wed, Aug 03, 2011 at 12:47:47PM -0700, Ian Romanick wrote: On 08/03/2011 12:11 PM, Bryan Cain wrote: Pardon my ignorance, but why do hardware drivers need a decompressor? To quote the EXT_texture_compression_s3tc spec: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. This is the same issue that Linux distros have with ARB_texture_float being enabled in hardware drivers. The hardware may implement the functionality, and the hardware vendor may have some license for the patent, but that license may not cover making the functionality available in Mesa. That S3 has sued Apple is some indication that these licenses may have very narrow scope. Ian, I think it is really not the same issue. The S3TC patent is about the algorithm itself, not about copying blocks of memory. The quote from EXT_texture_compression_s3tc only underlines the fact that Direct3D stack (both runtime and driver) does not have to provide S3TC compression/decompression algorithm at all, whereas driver providing EXT_tc_s3tc typically has to be able to compress the textures in the software (and thus implement the patented stuff). Direct3D serves as a pass-through to the hardware, they don't have to mess with the patent at all while the hw vendor typically has the decompression part covered. Feeding precompressed data, however, is also none of Mesa's business - and also, Mesa ALREADY does this, so if it's illegal, that's a risk Mesa already is taking. However, Mesa doesn't know if it's feeding S3TC or S2TC data - it feeds a data block as is. So, if anyone needs IP rights then, it's the author of the game that comes with precompressed S3TC textures - and not the graphics driver! I had the similar argument several weeks ago. I have suggested that Mesa could use similar approach I have seen several years ago with GL drivers on windows - ie. drivers reporting DXTn formats in the available compressed format list through the ARB_texture_compression, whereas _not_ listing EXT_tc_s3tc in the extension string, effectively doing the same thing as the Direct3D, allowing a passthrough of such data. I can only guess that the vendor didn't have had the compression part covered nor wanted to pay for that part at the given time. It worked well. Regards, Petr -- Petr Sebor / SCS Software [ http://www.scssoft.com ] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 20.3.2011 1:40, Henri Verbeet wrote: On 20 March 2011 00:42, Petr Seborp...@scssoft.com wrote: And this is not an undocumented hack. ARB_texture_compression explicitly defines mechanisms to work with 'unknown' formats providing a safe passthrough. Thats what glCompressedTexImage actually is for. Sure, the CompressedTexImage* calls are in principle agnostic to the specific format. But without the s3tc extension there's nothing that defines e.g. GL_COMPRESSED_RGBA_S3TC_DXT5_EXT. So you can't use those tokens, unless you have another extension that defines them. There is a slight difference between unknown and 'unknown'. You would enumerate the 'unknown' formats first via glGetIntegerv(GL_NUM_COMPRESSED_TEXTURE_FORMATS, num_formats) glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, format_table) compare the values returned with the format values you have and if there is a match, you're done. Sure it is convenient to know GL_COMPRESSED_RGBA_S3TC_DXT5_EXT is 0x83f3. I don't want to pretend that S3TC extension doesn't exist. Of course, there is a negligible overlap with the EXT_tc_s3tc extension specification in the sense that is is convenient to know the value of the format tokens. I assume that by defining and using such tokens isn't illegal. To sum this up, ARB_tc offers a way to pass through precompressed data, yet the Mesa code blocks anything S3TC related unless the compressing library is not present. I was asking for relaxing this requirement, at least on hardware where we're sure to not enter the legal grounds (apparently at least NV). So take it or leave it. The world isn't going to collapse if this opportunity is ignored. Petr -- Petr Sebor / SCS Software [ http://www.scssoft.com ] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 20.3.2011 16:42, Jose Fonseca wrote: Petr, You don't believe that IHVs may have narrow licenses of the S3TC patent. How do you explain the statement: WARNING: Vendors able to support S3TC texture compression in Direct3D drivers do not necessarily have the right to use the same functionality in OpenGL. in http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_s3tc.txt ? This is just a piece of evidence. I heard this from several different people now. Jose, I have noticed that warning as well, but my interpretation is that since DirectX runtime does not itself implement compression algorithms at all (it only serves as the passthrough), the OpenGL simply has to. In my view, a vendor has to obtain a hardware license to be able to decompress data and optionally, if he cares about OpenGL - a software license for the drivers, to be able to compress them them on the fly. Otherwise the EXT_tc_s3tc is no go. This is (I believe) the difference that matters. Petr -- Petr Sebor / SCS Software [ http://www.scssoft.com ] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 20.3.2011 20:23, Mathias Gottschlag wrote: Argh, meant to reply to list. If this nvidia library has a s3tc patent license, cannot this be used as a starting point, as done with the current dxt library? Unmodified, as an external binary? Wouldn't that circumvent the whole issue as you do not need a license for the hardware as it already has to be licensed if it was sold somewhere (well, at least on nvidia hardware, that is how I understand that FAQ entry, the part about narrow licenses does not seem to apply here), and you now suddenly have a licensed software encoder as well? Mathias I think this is a good point. And since nvidia texture tools is MIT licensed, it could be very well packaged and become standard part of the distributions (At least Debian's DFSG rules are MIT compatible, haven't checked other distros). I'd say - great idea, but then, we'll have to believe we actually can use such data on the hardware that sure has to be licensed as well. I believe it is clear. The compression and decompression algorithms are both implemented in packages that got to be covered by a license. Petr ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 20.3.2011 22:21, Patrick Baggett wrote: Offhand, anyone know when these patents expire? Patrick If the following is right: http://en.wikipedia.org/wiki/Term_of_patent_in_the_United_States then given S3TC patent http://v3.espacenet.com/publicationDetails/biblio?CC=USNR=5956431KC=FT=E http://v3.espacenet.com/publicationDetails/biblio?CC=USNR=5956431KC=FT=E (filled on Oct 2. 1997) ... will expire on Oct 2. 2017 (+20 years from being filled) So it is going to be here for quite some time. Petr ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 18.3.2011 16:50, Henri Verbeet wrote: On 18 March 2011 14:19, Petr Seborp...@scssoft.com wrote: I know that at least our games would benefit from this feature immediately, but I guess Wine people might welcome this as well, where 'benefit' means - do not have to painfully install the external DXT library, which is very likely not needed at all. As far as Wine is concerned, not without a proper extension. At this stage having the external library or driconf option is good enough for Wine. In the end this is a legal problem rather than a technical problem though. Henri, * *with all respect, I encourage you to lookup the S3TC patent US 5956431 once more to see what is actually claimed. The patent relates to image processing systems that actually actively perform image compression or decompression. This is actually the reason why the Mesa uses external processing library to be free of this legally covered stuff. Of course, without the help of such external library, Mesa cannot claim to support GL_EXT_texture_compression_s3tc, because if it does, it has to implement the patented algorithm. The situation is different in this case. I am just saying - please, relax the enforcement of the existence of the external image processing library in the Mesa in the cases when hardware natively supports DXTn formats and the Mesa client provides DXTn precompressed data, merely allowing a binary passthrough via well documented and available interface defined in the abstract ARB_texture_compression extension, allowing exactly for such cases where the OpenGL implementation doesn't claim the availability of given compressed format processing, but allowing the data to be just passed through. In this situation, the DXTn (S3TC) related agorithms were all implemented and used outside of the Mesa body and as far as I can see, nothing of the patent applies here. In the past days, applications (games) relied on the existence of the GL_S3_s3tc or GL_EXT_texture_compression_s3tc extensions, because they expected the implementation to optionally compress the data for them to save video memory and bandwidth, without precompressing the data themselves. Nowadays the situation is quite different, whereas almost any modern game relies on the existence of the hardware s3tc and provides preauthored data in the form it wants the implementation to use it, without actually requesting on-the-fly image compression. But just because we are all 'used to' simply check for the existence of the GL_EXT_texture_compression_s3tc doesn't mean we really want to use it at all. Many of the current applications do not. Limited ARB_texture_compression is sufficient enough for all our needs. Regards, Petr -- Petr Sebor / SCS Software [ http://www.scssoft.com ] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 19.3.2011 16:33, Jose Fonseca wrote: In this situation, the DXTn (S3TC) related agorithms were all implemented and used outside of the Mesa body and as far as I can see, nothing of the patent applies here. Petr, You're assuming that the IHV licensed the S3TC patent for all uses of their hardware. Although NVIDIA appears to have done so (per http://code.google.com/p/nvidia-texture-tools/wiki/FAQ), other vendors may have not: the S3TC patent is often licensed to be used only on particular platforms. driver stacks, or use cases. Enabling S3TC decompression on hardware for which IHV does not have a license covering Linux OS and Mesa driver stack may lead to S3 suing somebody -- the developer, the user, the linux distribution, or the hardware vendor -- typically whoever has the deepest pocket. So although it _appears_(*) to be safe to enable S3TC decompression on NVIDIA GPUs, there is no reason to think that of AMD, or Intel GPUs. Jose (*) I am not a lawyer. Jose, you are probably better lawyer than I am. I haven't realized that such thing might happen - I mean - the need to have a license to use the hardware on specific operating system and more, on a particular stack. That's absolutely totally crazy. Even though I personally internally don't believe* this is the case, the truth is that I don't know. And I agree that knowing it is what really matters. However, at least a part of your message carries good news. It happened quite some time ago, but you're right that nVidia na S3 cross-licensed some of their technology, including S3TC. And according to the FAQ you have linked it seems it might be actually possible to realize the proposed approach at least on their hardware if nothing else. That might be a nice first step. (*) I _believe_ that the S3TC relates mainly to the hardware decoding. This is where it becomes useful when saving memory and bandwidth. The situation when the hardware vendor obtains such narrow license - say - this chip on that operating system and such 3D stack sounds pretty strange to me. But yes, it might be possible, but I somehow believe that AMD and Intel got the S3TC license under similar terms like NV did. Just my $0.02. Maybe the others (Intel, AMD) might (or might not) follow after it becomes more clear what is covered under their license? It would be great if someone of Intel, AMD reading this list could shed some light on this. However, even if Mesa for any reason decides not to implement the compressed format passthrough in well defined terms of ARB_texture_compression, it is not a tragedy. I just thought that I could point out that there might be a simple solution to have at least some S3TC support in the free GL stack. Where people would learn it is perfectly ok to ignore the implementation ability to compress/decompress data on the fly when they already have precompressed data and there is a simple passthrough available. And more, this is not a hack - it is well defined interface which you can already depend on at least with NV hardware on Windows (this is what I can see here right now) and it was already used as the only way on some particular drivers in the past (sorry, my memory prevents me to be more specific, I just know we just had to use it to get S3TC). Regards, Petr -- Petr Sebor / SCS Software [ http://www.scssoft.com ] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Naked DXTn support via ARB_texture_compression?
On 19.3.2011 16:06, Henri Verbeet wrote: On 19 March 2011 12:24, Petr Seborp...@scssoft.com wrote: But just because we are all 'used to' simply check for the existence of the GL_EXT_texture_compression_s3tc doesn't mean we really want to use it at all. Many of the current applications do not. Limited ARB_texture_compression is sufficient enough for all our needs. Sure. All I'm saying is that as far as Wine is concerned, we wouldn't use that kind of undocumented hack. There would have to be a proper GL extension offering compressed formats but not runtime compression / decompression. That doesn't necessarily mean you won't be able to convince other Mesa developers that this is a good idea, just that usefulness to Wine isn't one of the arguments. Henri, I apologize for touching Wine. It just immediately came to my mind knowing all D3D games that can be played under it (and care about S3TC) already come with precompressed data. I just thought this might be good thing for its users. Probably not. And this is not an undocumented hack. ARB_texture_compression explicitly defines mechanisms to work with 'unknown' formats providing a safe passthrough. Thats what glCompressedTexImage actually is for. Petr -- Petr Sebor / SCS Software [ http://www.scssoft.com ] ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Naked DXTn support via ARB_texture_compression?
Hi,
I have not been watching the situation around the DXTn compressed texture
formats and Mesa closely for quite some time, but after trying to run
our games
on Mesa (that is, the 7.11-dev, Gallium) instead of the proprietary binary
drivers, I was struck by the fact that there is still no native support for
handling compressed texture formats.
Well, this is an old story and I understand that there is a common (and
probably
valid) fear from the possibility of being legally attacked because of
using patented
algorithms, but maybe there is a simple and hopefully legal way, that
might alleviate
the problem and make the life of many people a lot easier.
Motivation: We already have the compressed texture data, created either
by a closed source
library (nvdxt) or some other tool that already had to tackle the legal
issues. And moreover,
I am not interested in using on-the-fly texture
compression/decompression features of Mesa
itself at all. I just want the texture data, represented by a binary
blob to end up somewhere
in the hardware and I assume that copying such data around is pretty legal.
Quite some time ago, while reading ARB_texture_compression spec, I have
hoticed that it is written
in a way that it explicitly allows the implementation to know about (and
advertise) compressed
texture formats, without actually providing compression/decompression
itself, yet - ofcourse,
with some limitations. Since then our codebase is equipped with the
following code:
(and as far as I remember, at least in windows, there actually were
drivers that didn't advertise
the S3TC extensions, yet listed the S3TC formats via the
ARB_texture_compression, so this idea
is nothing new)
.. snip ..
// Check if the driver features on-the-fly compression to S3TC,
// we can be sure it will HW accelerate these formats as well.
self.cap.texture_compression_dxt.set(is_gl_supported(GL_EXT_texture_compression_s3tc));
if (! self.cap.texture_compression_dxt) {
// If such extension does not exist, try the last resort service.
// Even though the driver does not support runtime compression, it
can accept
// (and probably HW accelerate) rendering in provided compressed
texture formats we're enumerating below.
GLint num_compressed_formats;
self.glGetIntegerv(GL_NUM_COMPRESSED_TEXTURE_FORMATS,
num_compressed_formats);
GLint *const compressed_formats(static_castGLint
*(alloca(sizeof(GLint) * num_compressed_formats)));
self.glGetIntegerv(GL_COMPRESSED_TEXTURE_FORMATS, compressed_formats);
bool texture_DXT1_support(false);
// We're ignoring DXT3, we don't use it.
bool texture_DXT5_support(false);
// Check for DXT1 and DXT5 formats only, we don't use DXT3
for (GLint idx = 0; idx num_compressed_formats; ++idx) {
if (compressed_formats[idx] == GL_COMPRESSED_RGB_S3TC_DXT1_EXT) {
texture_DXT1_support = true;
message(GL_MESSAGE Enumerated DXT1 compressed texture
format.);
}
else if (compressed_formats[idx] ==
GL_COMPRESSED_RGBA_S3TC_DXT5_EXT) {
texture_DXT5_support = true;
message(GL_MESSAGE Enumerated DXT5 compressed texture
format.);
}
}
self.cap.texture_compression_dxt.set(texture_DXT1_support ||
texture_DXT5_support);
}
.. snip ..
Sure, this imposes some limitations like ... for example, not being able
to use glCompressedTexSubImage
with full texture extents, but that is typically not a problem for many
games/applications.
So, having the Mesa to provide only the way to copy the compressed data
to the hardware
with the native compressed format support would really save the day, at
least for anyone
who just wants to use the feature of the hardware he/she owns, without
actually using the
patented algorithms.
I have been looking sparsely over the Mesa code, thinking first I might
just hack around the idea
a present it with the patch, but it would probably end up just like this
- a hack, that should
be better architected in by someone fluent with the Mesa source.
I know that at least our games would benefit from this feature immediately,
but I guess Wine people might welcome this as well, where 'benefit'
means - do not have to
painfully install the external DXT library, which is very likely not
needed at all.
What are your opinions? It it something that might be possible to do
within Mesa?
Kind regards,
Petr Sebor
--
Petr Sebor / SCS Software [ http://www.scssoft.com ]
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
