Hi,
this patch here https://patchwork.freedesktop.org/patch/179202/ was
already reverted from master because it breaks a few games, most notably
KOTOR (which is already broken enough). It should be removed from the
next version of Mesa 17.2.
Nothing personal against the author of course.
___
Hello everyone,
you may remember that a few months ago I was trying to fix KOTOR to work
with Mesa to use the Gallium llvmpipe software renderer.
Well, it's been a while and I'm happy to see that things are a bit
better with Mesa 17.2. The game still crashes, but we're closer to
fixing it.
5.09.2017 18:50, Federico Dossena wrote:
Hello everyone,
you may remember that a few months ago I was trying to fix KOTOR to
work with Mesa to use the Gallium llvmpipe software renderer.
Well, it's been a while and I'm happy to see that things are a bit
better with Mesa 17.2. The game
nt feature that nobody
cares about anymore.
I think Miklos made KOTOR work on radeonsi or r600.
Marek
On Mon, Sep 25, 2017 at 6:50 PM, Federico Dossena wrote:
Hello everyone,
you may remember that a few months ago I was trying to fix KOTOR to work
with Mesa to use the Gallium llvmpipe software
Sorry if I insist on this again, but can someone who knows the internals
of Mesa better than me please tell me which files implement pbuffers in
gallium llvmpipe? Specifically, the parts that are involved in creating
a pbuffer, its texture, framebuffer, and (I think) copying the screen to it.
I
ably do
a lot of people a huge favor if you could modify apitrace in a way
that allows it to play WGL traces natively under Linux (e.g. by
translating the WGL functions into GLX ones).
Cheers,
Nicolai
On 27.09.2017 11:21, Federico Dossena wrote:
Hi, did you get my previous email with the trace
y of kotor.
Il 2017-03-27 00:08, Jose Fonseca ha scritto:
On 25/03/17 05:50, Federico Dossena wrote:
Hmm, that didn't work. Turning off GL_ATI_fragment_shader makes the game
glitch (see attached screenshot), forces framebuffer effects and soft
shadows to off, and makes the game look wo
tateful objects,
they are not interchangeable.
Jose
On 27/03/17 12:12, Federico Dossena wrote:
Oh nice, that's interesting.
I'm 99% sure it's something related to pbuffers, I read around that they
were very problematic back in the day. If I had to guess, I'd say our
problem mi
Hi,
I'm using Mesa (specifically Gallium on LLVMPipe) to run an old game
called Star Trek Voyager Elite Force.
I'd like to report a bug introduced with version 18.0.0 and still
present in Mesa master that completely breaks the shadows in this game.
I don't know how Mesa works internally so
As most of you are probably aware of, id2 and id3 games store GL
extensions in a buffer that's too small for modern systems. This usually
leads to a crash when MESA_EXTENSION_MAX_YEAR is not set, but what the
creator of this commit didn't know is that some id3 games (the more
"recent" ones) don
I agree with Timothy, it's a simple solution and it doesn't break anything.
On 2018-09-21 01:42, Timothy Arceri wrote:
On 20/9/18 11:09 pm, Ian Romanick wrote:
On 09/19/2018 11:36 PM, Federico Dossena wrote:
As most of you are probably aware of, id2 and id3 games store GL
exten
Do you know of other applications that are affected by the order or
extensions? This is the first time I encounter this problem.
On 2018-09-21 13:56, Ian Romanick wrote:
On 09/20/2018 04:42 PM, Timothy Arceri wrote:
On 20/9/18 11:09 pm, Ian Romanick wrote:
On 09/19/2018 11:36 PM, Federico
Any updates on this? I see the code is still in master
On 2018-09-21 17:34, Emil Velikov wrote:
On 21 September 2018 at 00:42, Timothy Arceri wrote:
On 20/9/18 11:09 pm, Ian Romanick wrote:
On 09/19/2018 11:36 PM, Federico Dossena wrote:
As most of you are probably aware of, id2 and id3
ring
array.
Seemingly I did not consider that as the documentation (both Mesa and
Nvidia) mention about program crashes ... which are worked around by
setting the env. variable.
This commit reinstates the workaround and enhances the documentation.
Cc: Federico Dossena
Cc: Timothy Arceri
Cc: M
In the last week I've been trying to bring an "old" game back to life,
Star Wars Knights of the old republic (KOTOR, for short). It's from 2003
and uses OpenGL 1.4.
I have used Mesa, libtxc_dxtn and some trickery to decompress the
textures to boost performance, and right now I have it up and r
mall DLL, while mesa is like 18mbytes. It doesn't look like
mesa's dll at all to me... Is there any way I can tell for sure?
Il 2017-03-13 12:59, Emil Velikov ha scritto:
[Adding back mesa-dev, since it seems like you've dropped it by accident]
On 13 March 2017 at 11:42, Feder
il), which for some
reason is a null pointer.
Il 2017-03-13 14:39, Jose Fonseca ha scritto:
On 13/03/17 11:09, Emil Velikov wrote:
On 11 March 2017 at 11:51, Federico Dossena
wrote:
In the last week I've been trying to bring an "old" game back to
life, Star
Wars Knights
:40, Jan Vesely ha scritto:
On Mon, 2017-03-13 at 11:40 +0200, Grazvydas Ignotas wrote:
On Sat, Mar 11, 2017 at 1:51 PM, Federico Dossena wrote:
This issue is not new: a guy named Miklós Máté, here in the Mesa mailing
list somehow managed to fix it in Mesa 11, but his patches do not seem to
work
aster. I'm attaching it
below so you can try it. I should commit it master. In any case, let
me know if it helps.
-Brian
On 03/13/2017 10:55 AM, Federico Dossena wrote:
Hi Jose, thanks for replying, I've seen your name inside many files in
mesa ;)
I have tried mesa master (previou
ed the mesa-dev cc)
Il 2017-03-14 03:44, Brian Paul ha scritto:
Looks like my KOTOR patch never made it to master. I'm attaching it
below so you can try it. I should commit it master. In any case, let
me know if it helps.
-Brian
On 03/13/2017 10:55 AM, Federico Dossena wrote:
Hi Jose,
to invoke wglMakeCurrent from
wglMakeContextCurrentARB, ignoring exttra arg.
Jose
On 15/03/17 14:31, Federico Dossena wrote:
Where can I find that implementation?
Also, is there an alternative to that function? As in a snippet of code
that does the same thing and can be used to create a &
keContextCurrentARB (not
wglBindTexImageARB, I was wrong in my previous mail), which for some
reason is a null pointer.
Il 2017-03-13 14:39, Jose Fonseca ha scritto:
On 13/03/17 11:09, Emil Velikov wrote:
On 11 March 2017 at 11:51, Federico Dossena
wrote:
In the last week I've
ot near my Windows development environment. Let me know
what you find.
-Brian
On Mar 15, 2017, at 12:26 PM, Federico Dossena wrote:
That's good, can't wait to see your implementation.
I have tried to simply return wglMakeCurrent(hReadDC,hglrc); but then I get a
crash in gluBuil
I'm sorry to bother you in the dev list but it seems to be the only one
with activity so it seems like the best place to ask.
I maintain some Mesa builds for Windows. These are builds of libgl-gdi
with llvmpipe, for both x86 and x86_64; in other words, they're
opengl32.dll files that users can
you'll need to point it to LLVM. In my
experience, adding "--cmake-prefix-path" to the Meson command line should work
well.
-Jesse
-Original Message-
From: mesa-dev On Behalf Of Federico
Dossena
Sent: Saturday, November 7, 2020 4:14 AM
To: mesa-dev@lists.freedeskt
25 matches
Mail list logo
