<imirkin>
i guess nouveau's nir adapter needs more help :)
<zmike>
yea this is gonna hit a lot of stuff that normal gl probably wouldn't
<imirkin>
ok, well, it "works", as in i hacked around enough bits. but ... super-fail.
mbrost has quit [Ping timeout: 480 seconds]
<imirkin>
holy shit that's a huge program
<zmike>
ye we Big Shader Club now
<imirkin>
6000 instructions
<zmike>
but you can run all of cts only needing to compile like 10 of them
<zmike>
probably less since it only does 2d
<imirkin>
on the bright side, it does look like the emitter successfully does u8/u16 writes.
<zmike>
\o/
<imirkin>
or at least the disasm and assembler agree on the encoding :)
<imirkin>
they could both be wrong!
<imirkin>
nah, seems right (based on nvdisasm, which is pretty reliable)
mbrost has joined #dri-devel
<imirkin>
but something somewhere goes wrong, coz all the pbo-getteximage stuff fails
<zmike>
you're doing piglit?
<imirkin>
just that one
<zmike>
hm
<imirkin>
i wanted to look at the cube map thing
<zmike>
that should all pass except the one case
<imirkin>
right
<imirkin>
but it all fails. so there's more wrong with nouveau's nir adapter, probably
<imirkin>
or RA, who knows
<imirkin>
it's a huge program
<zmike>
it's pretty beefy
<zmike>
you could try my ffffffffffffff branch and bisect a bit through there
<imirkin>
or you're doing something which happens to work on intel/amd, but not on nvidia
<zmike>
it starts out a lot smaller
<imirkin>
(like making assumptions about constbuf alignment, etc)
<zmike>
hm
<imirkin>
although that'd usually show up as errors, which i see none of
<zmike>
well it's just a 16byte vec4 ubo0
<zmike>
so
<zmike>
I gotta crash, but good luck!
mwalle has quit [Remote host closed the connection]
<zmike>
(you'll need it)
<imirkin>
zmike: lol, i think you overestimate my perseverance
<imirkin>
zmike: i do wonder why you need all that ... why not use an imageBuffer with the appropriate format, then you don't have to worry about all the manual packing...
<imirkin>
is it coz of formats not supported by images? you should be able to adjust the source/dest formats to "safe" ones for that
<imirkin>
wait, i thought we already had a pbo download path... is this only different in that it uses compute?
<airlied>
imirkin: yes it's a faster version supporting more formats using compute
jcline has joined #dri-devel
<soreau>
Is there any reason mesa-demos eglut wayland is still using deprecated wf-shell instead of xdgl shell stable?
<emersion>
iirc it uses waffle?
<emersion>
waffle is a bit late to the party, but a patch was merged at some point i think
dllud_ has joined #dri-devel
Duke`` has joined #dri-devel
dllud has quit [Ping timeout: 480 seconds]
itoral has joined #dri-devel
cphealy_ has joined #dri-devel
nchery has quit [Remote host closed the connection]
nchery has joined #dri-devel
nchery has quit []
cphealy has quit [Ping timeout: 480 seconds]
Kayden has quit [Remote host closed the connection]
Kayden has joined #dri-devel
mattrope has quit [Remote host closed the connection]
camus1 has joined #dri-devel
camus has quit [Ping timeout: 480 seconds]
jewins has quit [Remote host closed the connection]
lemonzest has joined #dri-devel
Duke`` has quit [Ping timeout: 480 seconds]
pnowack has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
mlankhorst has joined #dri-devel
frieder has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
alanc has quit [Remote host closed the connection]
alanc has joined #dri-devel
cbaylis has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
Hi-Angel has joined #dri-devel
mwalle has joined #dri-devel
sdutt_ has quit [Ping timeout: 480 seconds]
<MrCooper>
airlied: assuming that's the timeout for a single piglit test, bumping it seems fine, as long as the CI job still finishes in ~10 minutes (may also need to reorder the tests such that the longer ones run first)
<MrCooper>
imirkin_: add "fetch = +refs/merge-requests/*/head:refs/remotes/upstream/merge-requests/*" to the remote in .git/config, then you can reference MRs by "<remote>/merge-requests/<number>"
Net147 has quit [Quit: Quit]
Net147 has joined #dri-devel
<pq>
MrCooper, does that pull *all* MRs (open, and closed too?) on 'git rmeote update'?
pochu has joined #dri-devel
<MrCooper>
only open ones AFAICT, e.g. my Mesa repo has nothing older than 9989
<MrCooper>
err, wrong sorting
<MrCooper>
anyway, not all of them are there
<pq>
Ok. I prefer fetching only the specific one at a time, and only when I want it, since I tend to diff between fetches to see what changed since I reviewed last.
<pq>
that would require me to know *when* I reviewed last :-p
<pq>
and figuring that out from gitlab comments is... not easy
<pq>
I have trouble remembering if thing happened last week or last year, I just remember stuff happening somewhere, somewhen. :-)
rasterman has joined #dri-devel
<pq>
I have a script git-fetch-mr I give a MR number as argument, and it saves the old revision of the branch as *-old and fetches the new revision. Then it's easy to see only relevant stuff in gitk. Sometimes I also need to rebase the old revision to see a good diff.
<MrCooper>
AFAIK git range-diff is for that, I haven't tried it though
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
tzimmermann has joined #dri-devel
lynxeye has joined #dri-devel
Lucretia has joined #dri-devel
tursulin has joined #dri-devel
pcercuei has joined #dri-devel
javierm has joined #dri-devel
pochu has quit [Ping timeout: 480 seconds]
<danvet>
MrCooper, range-diff is absolutely awesome, but the interface is bonkers
<danvet>
I even filed a upstream gitlab ticket asking them to please include range diff output
<danvet>
I use range-diff to check my rebases pretty regularly
<MrCooper>
"awesome, interface bonkers" fits right in with git in general :)
<MrCooper>
cool, hopefully it won't take another 3 years
<danvet>
I don't think gitlab cares about rebase-heavy process all that much
<danvet>
there's a bunch open requests related to this
<danvet>
it's a bit unfortunate :-/
<MrCooper>
indeed
camus1 has joined #dri-devel
camus has quit [Remote host closed the connection]
vivijim has joined #dri-devel
nadrian has joined #dri-devel
thellstrom has joined #dri-devel
pochu has joined #dri-devel
flacks_ has quit [Quit: Quitter]
flacks has joined #dri-devel
<karolherbst>
imirkin: I wanted to take care of the conversion bits in order to get the CL convert ops implemented anyway
<karolherbst>
just didn't find time for it yet :)
<danvet>
lynxeye, any take from you on the sched series from me for dependency handling?
<danvet>
atm very lukewarm recipient feels like ...
<danvet>
bbrezillon, ^^ for panfrost
<danvet>
robclark, ^^ maybe you too since I guess once msm lands I get to rebase on top of that too and I better know whether I should do that before I do it :-)
pochu has quit [Quit: leaving]
bcarvalho has quit [Remote host closed the connection]
<lynxeye>
danvet: In general I'm all for it, the less code I have to hand-roll in etnaviv, the better. However, I want to give it another review and a proper test drive before giving the thumbs up. Also I don't really like the "await" color of the shed, would prefer to see add_dependency or something like that. ;)
<danvet>
lynxeye, I'm happy to repaint, just thus far it's only been könig
<danvet>
and yes this definitely needs careful review and testing
<danvet>
I think melissawen has given it a spin on v3d, need more for sure
<danvet>
lynxeye, can you pls reply to könig's bikeshed with a +1 and the exact function names you want?
<danvet>
I don't want sand off the paint job twice :-)
<danvet>
mripard, maybe ask airlied for an ack on your doc patch and then land it?
<danvet>
Lyude, [PATCH 0/4] Unregister mst connectors when hotplug <- they didn't cc: you on all the patches in the series, but I think they all need your reivew
<danvet>
hwentlan, ^^
Company has joined #dri-devel
<melissawen>
danvet, yes, reviewed and tested on v3d, so v4 lgtm
Peste_Bubonica has joined #dri-devel
Peste_Bubonica has quit [Quit: Leaving]
itoral has quit [Remote host closed the connection]
<ishitatsuyuki>
this guy says that Mesa spawns a thread per queue (for Vulkan?)... is this true? Is this guy confusing it with glthread?
<daniels>
for some particular presentation modes on X11, you have to
<ishitatsuyuki>
oh, i kinda remember that. it's for presenting and dealing with events right?
<ishitatsuyuki>
which means that "a thread per queue to actually perform the submission" as the guy said is probably a misconception...
<zmike>
imirkin: because I can't do swizzles with image buffers, and I also can't support a ton of formats that route, which was the motivation behind doing it
ppascher has quit [Quit: Gateway shutdown]
<zmike>
pepp: looks like you can't throw your code away just yet!
ppascher has joined #dri-devel
bcarvalho has quit [Remote host closed the connection]
<karolherbst>
danvet: did the drm-fixes stuff land in v2?
<imirkin_>
zmike: btw, why do you do like 4x u8 stores rather than 1x u32? or is that an opt "for later"?
<zmike>
some stuff is just because it was easier to write that way
<imirkin_>
fair enough
<HdkR>
`// XXX: Optimize later` Twenty years later, it still lives ;)
lemonzest has joined #dri-devel
<alyssa>
HdkR: Clearly it isn't later yet
<imirkin_>
HdkR: yeah, this is now. later is later.
<imirkin_>
<insert link to spaceballs video here>
muhomor has joined #dri-devel
<HdkR>
I'm always looking forward to later rather than the now
jewins has quit [Quit: jewins]
cphealy_ has quit []
cphealy has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
<hwentlan>
danvet, i see Lyude CCd on every patch of the series
sdutt has quit []
sdutt has joined #dri-devel
shashanks has joined #dri-devel
<danvet>
hwentlan, huh strange
<hwentlan>
hmm, but the dri-devel archives only show the cover letter. not sure what happened there
<hwentlan>
but you're right. the headers on patchwork don't show Lyude in CC. weird
<jekstrand>
cwabbott: For the subgroups patch for Zink.... Is there something you want changed? An explicit override bit that we just assert perhaps? Maybe a max_subgroup_size option and we assert that total_bits >= max_subgroup_size?
mattrope has joined #dri-devel
<cwabbott>
jekstrand: it does make me a little nervous, but I guess we can do with a comment
<jekstrand>
cwabbott: Yeah, GL on freedreno is going to be tricky thanks to that no matter what we do, I'm afraid. :-/
<cwabbott>
it's definitely possible, you just have to detect when ballots are in use and restrict the subgroup size to 64
<jekstrand>
Yup
<jekstrand>
Sadly, subgroup_size_control doesn't let you set a new maximum, just force a size.
<jekstrand>
So that's tricky for Zink
<alyssa>
cwabbott: Adreno lets you configure subgroup sizes >64?
<jekstrand>
alyssa: Yeah, it's crazy
<cwabbott>
yeah, FS and CS can use a subgroup size of 128 or 64
<cwabbott>
everything else is just 64
<alyssa>
I guess Valhall lets you configure 2/4/8/16 logically, but it's always 16 internally.
<jekstrand>
cwabbott: Can you always configure it? If so, then subgroup_size_control should do it
<cwabbott>
jekstrand: you can, although sometimes we have to fallback to 64
<alyssa>
regalloc related?
<cwabbott>
yup
<alyssa>
lovely :p
<cwabbott>
we already do the trick of pretending the upper 64 threads aren't active
<jekstrand>
cwabbott: Do you sometimes want to fall back or sometimes have to fall back?
<cwabbott>
have to
<jekstrand>
Ugh... That makes implementing subgroup_size_control tricky then
<cwabbott>
I think you can just fake 128
<cwabbott>
that's what we do already
<jekstrand>
How do you fake it?
<cwabbott>
as in, it's "128" but if they ask the upper 64 threads aren't active on entry
<jekstrand>
Yeah, that's not valid with subgroup_size_control either
<jekstrand>
You have to support the FULL_SUBGROUPS bit
camus has joined #dri-devel
<cwabbott>
oh, i guess we'd just have to spill in that case
<cwabbott>
bad user! *whack*
<jekstrand>
Yeah, that's what we do if someone forces SIMD32.
<jekstrand>
They asked for it, they get to keep the pieces.
<jekstrand>
As long as you CAN support 128, even if perf sucks, that's good enough.
<pq>
I have a feeling that changing "max bpc" connector property would need a modeset, but it's not documented and I'm lucky in that in my case there just happens to be a modeset at that point mostly by luck.
<cwabbott>
it's kinda similar with subgroups with a barrier
<cwabbott>
also, fun story, qcom also has a branch stack that is shared between waves in a core, just like the shared register file, except that it *can't* be spilled
<MrCooper>
danvet hwentlan: maybe Lyude has that option enabled in her mailman subscription settings which causes her to be removed from Cc in the e-mails sent by mailman to list subscribers
<alyssa>
cwabbott: what no why
<jekstrand>
cwabbott: Added a comment. Please look.
camus1 has quit [Ping timeout: 480 seconds]
<cwabbott>
so if you have a compute shader with a very large workgroup size, a barrier, and deeply nested control flow, their driver will just hang
<alyssa>
uh-oh
<alyssa>
does ir3 at least give an error message ?
<cwabbott>
shhhhhhhh
<alyssa>
o:)
<alyssa>
cwabbott: unrelated, I now have the path mesa/src/panfrost/bifrost/valhall in my tree. the irony is real.
<jekstrand>
cwabbott: Why isn't bifrost under midgard?
<alyssa>
jekstrand: An excellent question ;-P
<alyssa>
I was about to say midgard is vec4 and bifrost/valhall are scalarish, but that didn't stop intel :-p
<hwentlan>
MrCooper, i didn't even know this was an option but that would explain it
<alyssa>
jekstrand: If it was a serious question - Midgard and Bifrost are ~unrelated, except for being designed by the same people. Would need completely different instruction selection, register allocation, scheduling, packing, ... basically every part of the compilers are radically different.
<alyssa>
On the other hand, Valhall and Bifrost are both in the same family ... they look very different from the outside but most instructions are isomorphic.
<alyssa>
So they can share instruction selection (+ pre-RA scheduling) + regalloc, and just have different back-backends for post-RA scheduling and packing
<MrCooper>
hwentlan: yeah, it's a mailman trap
<jekstrand>
alyssa: Sounds like our hardware
<jekstrand>
alyssa: We've got roughly the same structure but the actual HW encoding radically changes at BDW and TGL.
<jekstrand>
(gens 8 and 12)
<alyssa>
gen8 for vec4->scalar and gen12 for scoreboarding?
<jekstrand>
No, gen4 has scalar
<jekstrand>
I don't really know why they did the big rewrite at gen8. Not much really changed in terms of capabilities.
<alyssa>
rip
<jekstrand>
gen12 was definitely for scoreboarding, though.
<jekstrand>
We lost vec4 at ICL (gen11)
<jekstrand>
We did get gen8 VS/GS/TES support at BDW, though. Maybe they were doing a big HW rework?
<HdkR>
Everyone loves scoreboarding right? :D
<jekstrand>
It sure seems popular
iive has joined #dri-devel
<imirkin_>
jekstrand: i guess fp64 was tied to vec4? :)
<imirkin_>
had to make some room...
<jekstrand>
No, not really. We had fp64 on IVB (gen7)
<jekstrand>
It was horribly broken in vec4 but it was there
<imirkin_>
but not on ICL which is also when vec4 went away...
<jekstrand>
I don't think those are related.
<imirkin_>
;)
<jekstrand>
They might be but I think it's more just the HW people trying to put our EUs on a diet
<imirkin_>
yes, sounds much more likely in practice :)
<jekstrand>
I really wish they would have left us at least a little bit of 64-bit.....
<imirkin_>
i hope you have like int <-> fp64 and fp32 <-> fp64?
Duke`` has joined #dri-devel
<jekstrand>
And this is why they tell us not to get our hopes up.....
orbea1 has joined #dri-devel
<HdkR>
This is when you politely tell people to buy an HPC card if you want FP64 right? :D
<imirkin_>
DG-1! :)
<jekstrand>
imirkin_: DG-1 doesn't have fp64
<imirkin_>
i assumed as much :)
orbea has quit [Ping timeout: 480 seconds]
<alyssa>
DG-64
<imirkin_>
DG-1 can only handle 1-bit floats. DG-64 can do 64-bit? :)
<alyssa>
Correct
<alyssa>
jekstrand: intel marketing should hire me ;-p
<jenatali>
Just use an N64
<imirkin_>
or upgrade to a GeForce 256. that has 256 ... things ...
<alyssa>
fp256
<imirkin_>
from wikipedia: `The "256" in its name stems from the "256-bit QuadPipe Rendering Engine", a term describing the four 64-bit pixel pipelines of the NV10 chip` :)
orbea1 has quit []
orbea has joined #dri-devel
jewins has joined #dri-devel
<Lyude>
danvet: yeah I saw - going to get to it in the next day or two
<Lyude>
just want to make sure I actually set aside the time to test it this time :)
yoslin has quit [Quit: WeeChat 3.2]
<glennk>
imirkin_, so parhelia must be a winner then with 512?
Peste_Bubonica has quit [Remote host closed the connection]
Terman has quit [Remote host closed the connection]
<emersion>
oh well
<daniels>
the correct approach to eglut is to delete it and never look back
<soreau>
heh
<daniels>
I'm serious
<daniels>
it's not actually fixable as a toolkit, and even if it were, it's vastly inferior to things like waffle, and all the tools are inferior too
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
gouchi has joined #dri-devel
gouchi has quit [Remote host closed the connection]
rsalvaterra_ has joined #dri-devel
gouchi has joined #dri-devel
rsalvaterra has quit [Ping timeout: 480 seconds]
<mareko>
imirkin_: what's the pixel rate of GF 256? What is the 64-bit pixel pipeline? Does it mean 2 pixels per clock?
<imirkin_>
mareko: further from wikipedia: "In single-textured games NV10 could put out 4 pixels per cycle, while a two-textured scenario would limit this to 2 multitextured pixels per cycle, as the chip still had only one TMU per pipeline"
<mareko>
our smallest and slowest APU can do 8 pixels per cycle
<lynxeye>
hey, it was the first GPU (according to Nvidia's arbitrary definition)
<imirkin_>
first one with hwtnl
<mareko>
what's the hwtnl rate? 1 vertex and 1 primitive in 4 cycles?
nchery has joined #dri-devel
sdutt has quit []
sdutt has joined #dri-devel
rsalvaterra_ has quit []
rsalvaterra has joined #dri-devel
<imirkin_>
mareko: no clue
<imirkin_>
mareko: it does say that with fast CPU's, hwtnl was slower :)
<imirkin_>
also no UCP's
agx has quit [Quit: leaving]
alyssa has left #dri-devel [#dri-devel]
unerlige1 has joined #dri-devel
unerlige has left #dri-devel [#dri-devel]
ppascher has quit [Quit: Gateway shutdown]
ppascher has joined #dri-devel
valentind has quit []
valentind has joined #dri-devel
frieder has quit [Read error: Connection reset by peer]
<zmike>
anholt_: when running vk cts with deqp-runner, do you just point it at vk-default.txt?
<anholt_>
zmike: yeah, you can see the mustpasses we use in .gitlab-ci/container/build-deqp.sh
<zmike>
🤔
<zmike>
maybe my deqp-runner version is too old
<zmike>
I ran it using a ci job as a reference, and it definitely ran something, but it doesn't seem to have failed any tests, which is not what I wanted
<anholt_>
VK-GL-CTS master has changed the format of the files
<bl4ckb0ne>
anybody here has a gl format to string func in their pocket?
<mareko>
_mesa_enum_to_string or something like that
<bl4ckb0ne>
enum to string it is
<bl4ckb0ne>
thanks
<bl4ckb0ne>
damn shame gl doesnt have something like that built in for clients
<zmike>
anholt_: is there a way to get it to generate a failure csv without providing a baseline?
tzimmermann has quit [Quit: Leaving]
<anholt_>
if you get failures, you should get a failure csv. if that's not the answer, I'm not sure what your question is.
<zmike>
hm okay, so then I guess I didn't get failures after all
<zmike>
did I accidentally make lavapipe conformant?
mbrost has joined #dri-devel
unerlige1 has left #dri-devel [#dri-devel]
unerlige has joined #dri-devel
unerlige has quit []
unerlige has joined #dri-devel
<jekstrand>
zmike: If you can get a solid conformance run, you should submit it
<zmike>
I didn't, I just don't understand how computers work
<jekstrand>
Oh, good. All is still right with the world, then. :P
<Sachiel>
they don't. We just conditioned ourselves to believe they do
* jekstrand
never believes "accidental" test fixes. :)
alyssa has joined #dri-devel
<alyssa>
CC BY-SA docs in mesa are a no-no I guess?
gouchi has quit [Remote host closed the connection]
gouchi has joined #dri-devel
<danvet>
seanpaul, perfect timing, there's someone who's working to integrate dyndbg into drm dbg output
<danvet>
maybe you can cross-review and get both things landed?
<danvet>
both features need to make sure we're handling all debug output consistent, so there I think you have 100% overlap
<danvet>
and hopefully a wiling reviewer :-)
xp4ns3 has quit [Quit: Konversation terminated!]
<danvet>
hwentlan, oh thanks for digging into this, looks like there's indeed something funny going on
Kayden has quit [Read error: Connection reset by peer]
Kayden has joined #dri-devel
<sravn>
danvet: what is the link to see if someone has commit rights? I have lost it...
<jenatali>
alyssa: Re !12003, you could probably just add it to the Windows CI command line if you wanted to try it out without having to set anything up yourself
<danvet>
seanpaul, ^^ your most treasured service, ever :-)
<alyssa>
jenatali: as a general rule I try to pretend non-*nix operating systems don't exist
<alyssa>
Panfrost should build under WSL that's good enough right? ;-p
agd5f has joined #dri-devel
<jenatali>
Hah, sure
<alyssa>
jenatali: in this case I just needed to build enough to run compiler unit tests
<alyssa>
this arose while getting increasingly frustrated bisecting on a machine that's now 3 generations out of date
ngcortes has joined #dri-devel
<HdkR>
alyssa: I can definitely recommend using a VM in case you get frustrated with that other OS as well. That's what my CI is running in :P
<jenatali>
Oh I totally get it, and I'm not suggesting it has value or you should do it, just to your comment in the MR description, if you wanted to see if it works you could do it
<alyssa>
HdkR: I hear someone's workin on porting linux natively..
camus1 has joined #dri-devel
<HdkR>
I hear
<sravn>
danvet: thanks!
<alyssa>
martian, was it? marty, maybe?
<airlied>
alyssa: seems like it's more porting OSX to Linux to get display hw working :-P
camus has quit [Ping timeout: 480 seconds]
rasterman has quit [Quit: Gettin' stinky!]
<airlied>
imirkin_: I made ajax appear for the glx bug, my work is done :-P
<imirkin_>
airlied: thanks :)
<imirkin_>
seems like he's also solved it
camus has joined #dri-devel
camus1 has quit [Ping timeout: 480 seconds]
shashanks has quit [Remote host closed the connection]
shashanks has joined #dri-devel
tarceri has quit [Remote host closed the connection]
tarceri has joined #dri-devel
ngcortes has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
mlankhorst has quit [Ping timeout: 480 seconds]
lynxeye has quit [Quit: Leaving.]
rasterman has joined #dri-devel
gouchi has quit [Remote host closed the connection]
<jekstrand>
Of course the textureSize() piglit tests for cube arrays test an array with a single cube....
<karolherbst>
:D
<karolherbst>
well, just add the same cube twice to the array :)
ngcortes has joined #dri-devel
<jekstrand>
I'm seeing division by 6 in the AMD drivers being implemented as multiplication by 0x2AAAAAAB. Does that work for all integers?
<imirkin_>
sounds like a standard div-by-const optimization...
<imirkin_>
i'm not too sensitive about that sort of thing, esp for the hack-patches i write, but at least maybe mention that you found it on some random site? wtvr
<karolherbst>
imirkin_: uff... why are games doing this
<karolherbst>
or wine
<imirkin_>
it's a GL shader in the games
<imirkin_>
game*
<karolherbst>
ehh :/
<imirkin_>
and i guess ATI shipped an unregistered ext for a while, and some games started using it? dunno
<imirkin_>
and then it became de-facto required to support it
<karolherbst>
let me try to use my archeology skills
<imirkin_>
i've never seen a spec for it
<imirkin_>
ARB_shader_texture_lod does say, "This extension interacts with ATI_shader_texture_lod"
<karolherbst>
so the extension name is GL_ATI_shader_texture_lod?
<imirkin_>
it clearly existed at some point
<karolherbst>
the GL wiki references it as well
<karolherbst>
wait...
<karolherbst>
I will find it :)
<imirkin_>
anyways, if you can get an approximate definition of what it's supposed to do, that worksforme
<imirkin_>
it looks like ARB_shader_texture_lod is based on it
pH5 has quit [Read error: Connection reset by peer]
pH5 has joined #dri-devel
heat has joined #dri-devel
karolherbst has quit [Read error: Connection reset by peer]
<idr>
Huh.
karolherbst has joined #dri-devel
<idr>
imirkin_: I can't find anything in my internal Khronos docs either.
<karolherbst>
:(
<idr>
At least some of the differences can be inferred from the issues section of ARB_shader_texture_lod.
<karolherbst>
idr: did you check the email archives?
<idr>
I did not. I just checked files on my disk.
<karolherbst>
mhh
<imirkin_>
idr: the ARB_* ext does claim to be a functional superset of the ATI one...
<karolherbst>
when did GL_ATI_shader_texture_lod appear?
<imirkin_>
however the game wants textureBias in vertex shaders
<idr>
???
<Kayden>
that's...never been a thing
<alyssa>
what does that even mean
<idr>
Ah...
<Kayden>
well, textureBias in vertex shaders would just be textureLod, since the implicit LOD would probably be 0, if anything?
<Kayden>
but there is no implicit LOD, so...
<idr>
The ATI version adds textureGrad* as just texture*.
<imirkin_>
i'd have to look at the trace again
<idr>
See issues 3 and 5.
<idr>
So... maybe that textureBias is actually textureGradBias?
* idr
tries to remember what all the functions are...
<karolherbst>
reading the emails from 2008...
<Kayden>
there isn't a GradBias in the core specs
<imirkin_>
karolherbst: the initial ARB_shader_texture_lod spec was from 2006
<karolherbst>
ufff
<imirkin_>
so probably around then for ATI as well
<karolherbst>
2006 are the oldest emails in the archive
<idr>
Hrm...
<karolherbst>
ahh
<imirkin_>
i think nv4x / r500-ish could do something in that department
<karolherbst>
there is a search :)
<karolherbst>
Results for shader_texture_lod 1 to 15 of 2486 results.
<karolherbst>
okay...
<dottedmag>
I understand DRM_IOCTL_{GET,AUTH}_MAGIC are obsolete, but I'm curious how it was used. Who obtained the value and passed to whom to do what? What did AUTH_MAGIC allow to do that wasn't possible without calling it?
<karolherbst>
let's add ATI
<karolherbst>
imirkin_: Results for ATI_shader_texture_lod 1 to 15 of 58 results. :)
<imirkin_>
yeah, so nv40 added TXL in vertex shaders
<karolherbst>
hopefully it's not only garbage
<imirkin_>
bbl
<imirkin_>
there's a trace in the bug i referenced
<imirkin_>
which should show you what the shader is
<karolherbst>
mhhh
<karolherbst>
annoying
<karolherbst>
soo.. I don't find anything :/
<karolherbst>
at least inside khronos
<karolherbst>
glew references it though
<karolherbst>
but nothing substantial
<karolherbst>
imirkin_: but ARB_shader_texture_lod claims to be a superset of ATI_shader_texture_lod :/
kabel has quit [Ping timeout: 480 seconds]
ngcortes has quit [Remote host closed the connection]
kabel has joined #dri-devel
<karolherbst>
imirkin_: yeah.. so it seems like that ext really doesn't exist anymore :)
pcercuei has quit [Quit: dodo]
alatiera has quit [Quit: Ping timeout (120 seconds)]
<idr>
I couldn't find anything in the old ARB / Khronos file shares either.
<anholt_>
dottedmag: X DRI client gets a magic value, passes it to the server and asks for the client with that magic to be authed so that the client can do direct rendering. all the ioctls that might access the GPU required auth, and this kept other users from snooping on an X server's rendering.
kabel has quit [Ping timeout: 480 seconds]
kabel has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
tarceri has quit [Read error: Connection reset by peer]
tarceri has joined #dri-devel
<airlied>
hmm sroland bypassed the marge by clicking the merge when finished
iive has quit []
<zmike>
what an executive
<Sachiel>
I assume there's no way to disable that button for a project?
jernej_ has quit []
jernej has joined #dri-devel
jernej has quit []
jernej has joined #dri-devel
craftyguy has quit [Remote host closed the connection]