I have an application that has been running for 2-3 days no worries
with vblank_mode=0, but of course chews CPU and tears the screen, I
recently started running it with vblank_mode=2 or 3 and it hangs
in the glXSwapBuffers after a few hours, it looks like it is repeatedly
calling the
Hi,
In radeonUpdateWindow and radeonUpdateViewportOffset functions in
radeon_state.c `tx' and `ty' values are calculated differently. In
UpdateWindow SUBPIXEL_X|Y values are added and in UpdateViewportOffset
it's not and compared to values which might have been calculated in
former function. The
Jacek Rosik wrote:
Hi,
In radeonUpdateWindow and radeonUpdateViewportOffset functions in
radeon_state.c `tx' and `ty' values are calculated differently. In
UpdateWindow SUBPIXEL_X|Y values are added and in UpdateViewportOffset
it's not and compared to values which might have been calculated in
Bugs item #1104449, was opened at 2005-01-18 13:15
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=100387aid=1104449group_id=387
Category: None
Group: Rendering Error
Status: Open
Priority:
Hi list!
http://www.opengl.org/documentation/extensions/EXT_framebuffer_object.txt
Has finally been posted.. hopefully it will be implemented in Mesa soon :)
-- Pasi Kärkkäinen
^
. .
On Tue, 18 Jan 2005 15:43:23 +0100, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Michel Dänzer wrote:
I've uploaded a new version here:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx8.diff
Michel Dnzer wrote:
I've uploaded a new version here:
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_ddx8.diff
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_dri8.diff
http://homepage.hispeed.ch/rscheidegger/dri_experimental/radeon_tiling_drm8.diff
Alex Deucher wrote:
Actually DRIAdjustframe() and friends in dri.c may still be the
problem. it does some wrapping of the adjustframe() functions and
calls them, perhaps incorrectly for mergedfb. I could be wrong though
I haven't really traced all that is going on there. Something is
causing
Pasi Kärkkäinen wrote:
Hi list!
http://www.opengl.org/documentation/extensions/EXT_framebuffer_object.txt
Has finally been posted.. hopefully it will be implemented in Mesa soon :)
Don't hold your breath. It'll take quite a bit of work.
I think the design of GL_EXT_framebuffer_object took longer
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2316
Summary: Symbol noXFree86DRIExtension
Product: DRI
Version:
On Tue, 18 Jan 2005 16:31:48 +0100, Roland Scheidegger
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
Actually DRIAdjustframe() and friends in dri.c may still be the
problem. it does some wrapping of the adjustframe() functions and
calls them, perhaps incorrectly for mergedfb. I could be
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2316
--- Additional Comments From [EMAIL PROTECTED] 2005-01-18 08:57 ---
it sounds
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2316
--- Additional Comments From [EMAIL PROTECTED] 2005-01-18 08:43 ---
Sounds like
On Sunday, January 16, 2005 2:24 pm, Stephane Marchesin wrote:
Jesse Barnes wrote:
I figured other projects might have similar problems, thanks for checking
dri.
Please note that I didn't actually check the dri. I just happened to get
an MCA from time to time at mesa solo startup and your
Roland Scheidegger wrote:
The DRM could update the register in the vblank interrupt handler?
That sounds right (didn't know there was such a handler, but there it
is...). I can't see how to do that though. Looks complicated :-(.
Hmm, played around with waiting on vblank a bit. Tried both
Pasi Kärkkäinen wrote:
http://www.opengl.org/documentation/extensions/EXT_framebuffer_object.txt
Has finally been posted.. hopefully it will be implemented in Mesa soon :)
The superbuffers working group worked on that extension for just over 2
years, and we're glad to be done! :)
Getting this
Pawel Salek wrote:
Hello,
I thought I would share my impression of running DOOM3 (250SEK on
sale!) using DRI drivers (free!).
SUMMARY: - hardware TCL broken. - some lighting problems with
software TCL. - few lockups (save frequently!). - average 10 FPS on
AMD XP1800+, Radeon 8500LE, 640x480.
Hello,
I thought I would share my impression of running DOOM3 (250SEK on
sale!) using DRI drivers (free!).
SUMMARY:
- hardware TCL broken.
- some lighting problems with software TCL.
- few lockups (save frequently!).
- average 10 FPS on AMD XP1800+, Radeon 8500LE, 640x480.
FOLLOWUP:
My goal was
On Tue, 2005-01-18 at 08:28 +, Dave Airlie wrote:
I have an application that has been running for 2-3 days no worries
with vblank_mode=0, but of course chews CPU and tears the screen, I
recently started running it with vblank_mode=2 or 3 and it hangs
in the glXSwapBuffers after a
Michel Dnzer wrote:
On Tue, 2005-01-18 at 16:31 +0100, Roland Scheidegger wrote:
Alex Deucher wrote:
Actually DRIAdjustframe() and friends in dri.c may still be the
problem. it does some wrapping of the adjustframe() functions and
calls them, perhaps incorrectly for mergedfb. I could be wrong
Have you ruled out simple logic bugs causing a spurious failure?
well I'm doing a code review of the code over the next while also, I do
wonder is thers some amount of interrupts that I'm failing after or if
there is maybe some small race in the interrupt handling.., so
consistency tests are
This is not a driver bug. Doom3 with r_renderer arb simply does look
that awful. At least I've tried it with some other OS, and it looked
exactly the same. AFAIK noone has the required documentation to
implement the ati fragment shader extensions, which are required to
enable other
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://bugs.freedesktop.org/show_bug.cgi?id=2316
--- Additional Comments From [EMAIL PROTECTED] 2005-01-18 16:38 ---
do you
On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
Speaking of mergedfb and page flipping: Is it really necessary to add
a new private SAREA field and a corresponding setparam? Isn't it
possible to set the generic SAREA fields as the DRM expects them, to
Hi all,
On error a lot of DRI drivers do an exit and just leave, this
means you have to setup a break on exit to debug these cases which can be
a bit of a pain if you forget.. I wonder how to people feel about
changing these exits to aborts so the app gets a signal and then can be
On Tue, 2005-01-18 at 16:31 +0100, Roland Scheidegger wrote:
Alex Deucher wrote:
Actually DRIAdjustframe() and friends in dri.c may still be the
problem. it does some wrapping of the adjustframe() functions and
calls them, perhaps incorrectly for mergedfb. I could be wrong though
I
Michel Dnzer wrote:
On Tue, 2005-01-18 at 15:43 +0100, Roland Scheidegger wrote:
Michel Dnzer wrote:
Speaking of mergedfb and page flipping: Is it really necessary to
add a new private SAREA field and a corresponding setparam?
Isn't it possible to set the generic SAREA fields as the DRM
expects
savage driver team,
when i run glxgears a window appears but nothing is
displayed. the shell from which glxgears was run displays the usual frames per
second and no other information. i checked glxinfo and dri is enabled. also
found nothing unusual in the X log file. i have two options set
On Tue, 2005-01-18 at 20:43 +0100, Roland Scheidegger wrote:
The DRM could update the register in the vblank interrupt handler?
[...]
How would you do that in-kernel? There is vblank interrupt related stuff
(radeon_driver_vblank_wait for instance), but that only is called when a
user has
29 matches
Mail list logo
