[Bug 8447] ctx-Const.MaxTextureImageUnits = 8
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=8447 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||NOTABUG --- Additional Comments From [EMAIL PROTECTED] 2006-10-07 01:12 --- My search was to narrow, didn't think of /etc/driconf, my bad. Sorry for wasting your time, keep up the good work! (guess who is feeling very stupid right now) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6412] mach64 vertex buffer cleanup
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=6412 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2006-10-07 01:37 --- This bug has served well in understanding mach64 vertex setup but I don't think it is clean enough to apply. Possible outcomes of this bug report: * mach64 has to be compiled with -fno-strict-aliasing to run ok. The culprit for this is mach64FastRenderClippedPoly() in mach64_tris.c:1580. Either drop the optimized version of that function or see patch for an alternative. * The non-native vertex buffer does not currently work and I don't know how well it serves as a source of documentation. It could propably be dropped. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7861] mach64 with render acceleration should restore texture state
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=7861 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #6535 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-10-07 01:49 --- Created an attachment (id=7276) -- (https://bugs.freedesktop.org/attachment.cgi?id=7276action=view) trivial patch with comment -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 7260] mach64 texture memory mng cleanup
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=7260 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #6018 is|0 |1 obsolete|| --- Additional Comments From [EMAIL PROTECTED] 2006-10-07 01:59 --- Created an attachment (id=7277) -- (https://bugs.freedesktop.org/attachment.cgi?id=7277action=view) use dri/common/texmem.c - try 4 rebase to head. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8541] New: Strange effect?
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=8541 Summary: Strange effect? Product: Mesa Version: 6.5 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] I'm not sure how to word it correctly, so it seems to be that the rendered screen seems to be offset incorrectly, and some shadow effect or artifact. I have tried looking for a similiar bugs, but havn't found any. I have some photos at http://www.sannes.org/misc/mesa-problem/ (especially the 527 one you can see the shadowing effect quite clearly), I see more or less the same thing with quake2-icculus, qudos and enemy territory. I have gentoo installed with 64bit and all the applications runs in 64bit mode. mesa-6.5.1-r1 xf86-video-ati-6.6.3 xorg-x11-7.1 and kernel modules from git I get the same when running with export LIBGL_ALWAYS_INDIRECT=1 before starting the games. Graphics card: 05:00.0 VGA compatible controller: ATI Technologies Inc R423 UK [Radeon X800SE (PCIE)] 05:00.1 Display controller: ATI Technologies Inc Radeon R423 UK (PCIE) [X800 SE] (Secondary) I hope this isn't a duplicate bug, and if it is it is probably because I don't know what to search for in this case. I can probably provide alot more information if you just tell me what you want :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 8541] Strange effect?
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=8541 --- Additional Comments From [EMAIL PROTECTED] 2006-10-07 03:57 --- Also, it is only in fullscreen mode that this happens. (works fine in windowed mode). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Keith Whitwell wrote:
Rune Petersen wrote:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
programs, instead of using _mesa_add_state_reference you could try
_mesa_add_named_parameter. Otherwise, you could always construct 0.5
in the shader itself, since you always have the constants 0 and 1
available thanks to the powerful swizzling capabilities, though
surprsingly it seems somewhat complicated. Either use 2 instructions
(ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
these, but I guess the approximated EXP should do (2^-1).
This math in this patch appear sound. the doom3-demo issue appear
unrelated to fragment.position.
This version makes use of existing instructions to calculate
result.position.
split into 2 parts:
- select_vertex_shader changes
- The actual fragment.position changes
This patch assumes that:
- That the temp used to calculate result.position is safe to use (true
for std. use).
- That fragment.position.x y wont be used (mostly true, except for
exotic programs.)
In order to fix this, I'll need to know the window size, but how?
Surely it's right there in radeon-dri.drawable ?
Sure it's is, I just managed to miss it, I'm still new at this =)
It is pretty solid now. position x y are correct. And no regressions
After some extensive testing, I found that a doom3-demo vertex shader
and the select_vertex_shader code uncovered a bug in the vertex shader.
We can't output result.* unless the fragment shader expects the input.
The fix is to change the unused outputs to an unused temp.
Rune Petersen
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_context.h r300-dev2/r300_context.h
--- r300-dev/r300_context.h 2006-09-19 18:52:45.0 +0200
+++ r300-dev2/r300_context.h2006-10-06 22:00:40.0 +0200
@@ -623,6 +623,8 @@
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
+ int wpos_idx;
+ const __DRIdrawablePrivate * dPriv;
int inputs[VERT_ATTRIB_MAX];
int outputs[VERT_RESULT_MAX];
int native;
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_fragprog.c r300-dev2/r300_fragprog.c
--- r300-dev/r300_fragprog.c2006-09-17 13:49:38.0 +0200
+++ r300-dev2/r300_fragprog.c 2006-10-05 18:59:57.0 +0200
@@ -1400,6 +1400,13 @@
}
InputsRead = ~FRAG_BITS_TEX_ANY;
+ /* fragment position treated as a texcoord */
+ if (InputsRead FRAG_BIT_WPOS) {
+ cs-inputs[FRAG_ATTRIB_WPOS].refcount = 0;
+ cs-inputs[FRAG_ATTRIB_WPOS].reg = get_hw_temp(rp);
+ }
+ InputsRead = ~FRAG_BIT_WPOS;
+
/* Then primary colour */
if (InputsRead FRAG_BIT_COL0) {
cs-inputs[FRAG_ATTRIB_COL0].refcount = 0;
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_state.c r300-dev2/r300_state.c
--- r300-dev/r300_state.c 2006-09-17 13:49:36.0 +0200
+++ r300-dev2/r300_state.c 2006-10-04 22:58:14.0 +0200
@@ -1305,6 +1305,20 @@
r300-hw.rr.cmd[R300_RR_ROUTE_1] = 0;
+ if (InputsRead FRAG_BIT_WPOS){
+ for (i = 0; i ctx-Const.MaxTextureUnits; i++)
+ if (!(InputsRead (FRAG_BIT_TEX0 i)))
+ break;
+
+ if(i == ctx-Const.MaxTextureUnits){
+ fprintf(stderr, \tno free texcoord found...\n);
+ exit(0);
+ }
+
+ InputsRead |= (FRAG_BIT_TEX0 i);
+ InputsRead = ~FRAG_BIT_WPOS;
+ }
+
for (i=0;ictx-Const.MaxTextureUnits;i++) {
r300-hw.ri.cmd[R300_RI_INTERP_0+i] = 0
| R300_RS_INTERP_USED
diff -Naur -x '*.o' -x '*.so' -x Entries -x depend -x depend.bak
r300-dev/r300_vertexprog.c r300-dev2/r300_vertexprog.c
--- r300-dev/r300_vertexprog.c 2006-10-07 14:10:14.0 +0200
+++ r300-dev2/r300_vertexprog.c 2006-10-07 14:10:23.0 +0200
@@ -955,17 +955,160 @@
assert(vpi-Opcode == OPCODE_END);
}
+static void insert_wpos(struct r300_vertex_program *vp,
+ struct gl_program *prog,
+ GLint pos)
+{
+ struct prog_instruction *vpi;
+ struct prog_instruction *vpi_insert;
+ GLuint temp_index;
+ GLfloat window_values[4];
+ GLuint const_window_index;
+ int i = 0;
+
+ vpi = malloc((prog-NumInstructions + 5) * sizeof(struct
prog_instruction));
+ memcpy(vpi, prog-Instructions, (pos+1) * sizeof(struct
prog_instruction));
+
+ vpi_insert = vpi[pos];
+
+
[Bug 8541] Strange effect?
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=8541 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2006-10-07 05:53 --- Do you have enabled page flip in your xorg conf ? If so please disable it and retry. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] partly working fragment.position patch
Rune Petersen wrote:
Keith Whitwell wrote:
Rune Petersen wrote:
Rune Petersen wrote:
Roland Scheidegger wrote:
Rune Petersen wrote:
I hit a problem constructing this:
- In order to do range mapping in the vertex shader (if I so choose)
I will need a constant (0.5), but how to add it?
I think this might work similar to what is used for position invariant
programs, instead of using _mesa_add_state_reference you could try
_mesa_add_named_parameter. Otherwise, you could always construct 0.5
in the shader itself, since you always have the constants 0 and 1
available thanks to the powerful swizzling capabilities, though
surprsingly it seems somewhat complicated. Either use 2 instructions
(ADD 1+1, RCP). Or try EX2/EXP though I'm not sure about performance of
these, but I guess the approximated EXP should do (2^-1).
This math in this patch appear sound. the doom3-demo issue appear
unrelated to fragment.position.
This version makes use of existing instructions to calculate
result.position.
split into 2 parts:
- select_vertex_shader changes
- The actual fragment.position changes
This patch assumes that:
- That the temp used to calculate result.position is safe to use (true
for std. use).
- That fragment.position.x y wont be used (mostly true, except for
exotic programs.)
In order to fix this, I'll need to know the window size, but how?
Surely it's right there in radeon-dri.drawable ?
Sure it's is, I just managed to miss it, I'm still new at this =)
It is pretty solid now. position x y are correct. And no regressions
After some extensive testing, I found that a doom3-demo vertex shader
and the select_vertex_shader code uncovered a bug in the vertex shader.
We can't output result.* unless the fragment shader expects the input.
The fix is to change the unused outputs to an unused temp.
Of cause I manage to attach the right patch
Rune Petersen
? depend
? server
Index: r300_context.h
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_context.h,v
retrieving revision 1.104
diff -u -r1.104 r300_context.h
--- r300_context.h 12 Sep 2006 18:34:43 - 1.104
+++ r300_context.h 7 Oct 2006 12:55:47 -
@@ -592,7 +592,8 @@
extern int hw_tcl_on;
-#define CURRENT_VERTEX_SHADER(ctx) (ctx-VertexProgram._Current)
+//#define CURRENT_VERTEX_SHADER(ctx) (ctx-VertexProgram._Current)
+#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)-selected_vp)
/* Should but doesnt work */
//#define CURRENT_VERTEX_SHADER(ctx) (R300_CONTEXT(ctx)-curr_vp)
@@ -607,12 +608,18 @@
/* r300_vertex_shader_state and r300_vertex_program should probably be merged
together someday.
* Keeping them them seperate for now should ensure fixed pipeline keeps
functioning properly.
*/
+
+struct r300_vertex_program_key {
+ GLuint InputsRead;
+ GLuint OutputsWritten;
+};
+
struct r300_vertex_program {
- struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_program *next;
+ struct r300_vertex_program_key key;
int translated;
struct r300_vertex_shader_fragment program;
- struct r300_vertex_shader_fragment params;
int pos_end;
int num_temporaries; /* Number of temp vars used by program */
@@ -623,6 +630,12 @@
int use_ref_count;
};
+struct r300_vertex_program_cont {
+ struct gl_vertex_program mesa_program; /* Must be first */
+ struct r300_vertex_shader_fragment params;
+ struct r300_vertex_program *progs;
+};
+
#define PFS_MAX_ALU_INST 64
#define PFS_MAX_TEX_INST 64
#define PFS_MAX_TEX_INDIRECT 4
@@ -797,6 +810,7 @@
struct r300_cmdbuf cmdbuf;
struct r300_state state;
struct gl_vertex_program *curr_vp;
+ struct r300_vertex_program *selected_vp;
/* Vertex buffers
*/
@@ -854,9 +868,9 @@
extern int r300_get_num_verts(r300ContextPtr rmesa, int num_verts, int prim);
-void r300_translate_vertex_shader(struct r300_vertex_program *vp);
+extern void r300_select_vertex_shader(r300ContextPtr r300);
extern void r300InitShaderFuncs(struct dd_function_table *functions);
-extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program *vp, float *dst);
+extern int r300VertexProgUpdateParams(GLcontext *ctx, struct
r300_vertex_program_cont *vp, float *dst);
extern int r300Fallback(GLcontext *ctx);
extern void radeon_vb_to_rvb(r300ContextPtr rmesa, struct radeon_vertex_buffer
*rvb, struct vertex_buffer *vb);
Index: r300_maos.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/r300/r300_maos.c,v
retrieving revision 1.39
diff -u -r1.39 r300_maos.c
--- r300_maos.c 14 Sep 2006 16:17:06 - 1.39
+++ r300_maos.c 7 Oct 2006 12:55:47 -
@@ -407,8 +407,8 @@
if (hw_tcl_on) {
struct
[Bug 8541] Strange effect?
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=8541 --- Additional Comments From [EMAIL PROTECTED] 2006-10-07 08:57 --- Created an attachment (id=7278) -- (https://bugs.freedesktop.org/attachment.cgi?id=7278action=view) my xorg.conf file Tried to disable it (with off) then disabled all options in my xorg.conf (which I had enabled) for the driver by uncommenting it, still same strange offset.. I'm attaching my xorg.conf, maybe it could shed some light on things? :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 driver support for Hypermemory cards?
Hello, in the next weeks I'm going to buy a new motherboard and video card. Since pretty much every motherboard for AMD processors now has only PCI express slots, and since I'd prefer to use an open source driver, I opted for a Radeon X??? card. I searched with google and in the X mailing lists for the current status of the free source r300 driver, but I couldn't find any clear statement about the Hypermemory feature; most pages or posts were outdated or vague. So the main question is: does the r300 open source dri driver support the Radeon desktop PCIe video cards (i.e. X300SE or X550) with Hypermemory, that is the feature that allows the card to use both the on-board vram and the system ram as video memory? And, secondly, do AIGLX or XGL work on such cards? Thank you in advance, GhePeU - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300 driver support for Hypermemory cards?
GhePeU wrote: I searched with google and in the X mailing lists for the current status of the free source r300 driver, but I couldn't find any clear statement about the Hypermemory feature; most pages or posts were outdated or vague. So the main question is: does the r300 open source dri driver support the Radeon desktop PCIe video cards (i.e. X300SE or X550) with Hypermemory, that is the feature that allows the card to use both the on-board vram and the system ram as video memory? AFAIK Hypermemory is a pure marketing gimmick, the chip used on these cards is no different than the normal cards, they just have less onboard ram (and only a 64bit memory bus). So I'd suspect it should work just fine BUT the driver will only use the onboard ram, and 32MB is probably not quite enough if you need more than 2d (not to mention it'd be slower than the normal 128bit cards), though I think there are X300SE or X550 out there with 64 or 128MB onboard ram. So a X550 HM 512MB (with 128MB onboard) will work exactly as good or bad as a X550SE 128MB, since, well, it's the exact same card with a different name... (someone correct me if I'm wrong and there might be problems with for instance different default setups of apertures which could lead to problems but I don't think so). And, secondly, do AIGLX or XGL work on such cards? Dunno exactly, but the basic support should be the same as any other r300-based card. Though the 64bit cards definitely are no speed demons, no amount of marketing buzzwords will help unfortunately in that area, but I'm not sure if that would be visible for aiglx or xgl. Low amounts of video memory will probably make a difference, though. Personally, I'd never really recommend any radeon card with only a 64bit memory bus (save the good old simple radeon 7000...), marketing-enhanced or not, but since these are obviously sold quite often I must be alone with that opinion... IMHO, you're paying almost as much as the full 128bit cards for basically half the performance. Roland - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
